💻 Kubernetes 1.35: Новый уровень эффективности с перезапуском подов на месте

🚀 В версии Kubernetes 1.35 представлена новая стабильная функция — In-Place Restart всех контейнеров в поде. Это позволяет перезапустить все контейнеры внутри существующего пода без его удаления и повторного создания.

💬 Что это и зачем нужно?

Раньше для перезапуска приложения часто использовали kubectl delete pod или модифицировали под через kubectl rollout restart для Deployment. Это приводило к полному пересозданию пода: смене IP, повторному прохождению стадий планирования и инициализации, что не всегда эффективно.

In-Place Restart даёт точечный контроль: вы можете принудительно перезапустить контейнеры внутри пода, сохранив его идентичность (имя, IP-адрес, привязку к ноде).

💬 Основные сценарии использования

— Обновление конфигурации приложения без пересоздания пода
Например, если ConfigMap или Secret, подключенные как volume, были обновлены, новый In-Place Restart позволит применить изменения к уже работающему поду.

— Перезапуск "зависшего" приложения
Если контейнеры в поде работают, но приложение внутри них перестало отвечать (например, из-за утечки памяти или deadlock), можно инициировать их перезапуск без прерывания сетевого соединения к поду.

— Горячее обновление зависимостей внутри контейнера
Для некоторых сценариев (например, перезагрузка внутренних процессов или динамических библиотек) теперь не нужно уничтожать весь под.

💬 Как это работает

Механизм реализован через новое поле restartAllContainers в PodSpec. При его установке в true kubelet на ноде перезапускает все контейнеры в поде (кроме тех, что имеют политику перезапуска Never).

💬 Ограничения и особенности

— Перезапуск не влияет на volumes: данные сохраняются.
— IP-адрес пода и его привязка к ноде остаются неизменными.
— Под должен быть в состоянии Running для успешного перезапуска.
— Если перезапуск не удаётся (например, новый образ недоступен), под может перейти в состояние Error.

In-Place Pod Restart в Kubernetes 1.35 даёт более тонкий и эффективный инструмент управления жизненным циклом контейнеров. Это особенно полезно для stateful-приложений, чувствительных к смене IP, и для оперативного реагирования на проблемы без полного пересоздания инфраструктуры пода.

➡️ Подробнее в официальном блоге Kubernetes

#заметкиИнженера

⭐️ Reloader
— Kubernetes-контроллер, который автоматически запускает rolling upgrade подов при изменении связанных с ними ConfigMap или Secrets.

🟡 Основной функционал:
— Автоматический мониторинг изменений в Secrets, ConfigMaps и CSI-монтируемых секретах.
— Инициирование rolling update для Deployment, StatefulSet, DaemonSet, ArgoRollout и других workload.
— Гибкое управление через аннотации: можно настроить перезапуск для всех или конкретных конфигураций.
— Поддержка оповещений (webhook) о перезапусках.

🟡 Ключевые особенности:
— Простая интеграция: Достаточно добавить аннотацию reloader.stakater.com/auto: "true" к вашему Deployment.
— Гибкие стратегии: Поддерживает как глобальный автоперезапуск, так и точечный — только для указанных ресурсов.
— Расширенная поддержка: Работает с секретами из внешних хранилищ через Secrets Store CSI Driver (например, HashiCorp Vault, AWS Secrets Manager).

Reloader решает классическую проблему Kubernetes, когда обновлённые конфиги и секреты не применяются к уже работающим подам. Это критически важно для безопасности (чтобы сразу применить новые ключи) и для CI/CD-процессов, где конфигурация меняется часто.

👉 Git
#полезное

🟡 Netplan — современный инструмент для конфигурации сети в Linux, использующий декларативные YAML-файлы.

Разработан компанией Canonical и впервые появился в Ubuntu 17.10. Призван заменить устаревшие скрипты в /etc/network/interfaces и конфиги NetworkManager, обеспечивая единый, предсказуемый и статический способ настройки.

📎 В 2024 году Netplan достиг зрелости с выпуском стабильной версии 1.0, что закрепляет его как надёжный инструмент для продакшн сред.

👀 Назначение и преимущества:

— Унификация: Единый формат конфигов для настройки сети через systemd-networkd или NetworkManager в фоновом режиме.
— Простота: Читаемый YAML вместо Bash-скриптов.
— Предсказуемость: Конфигурация применяется атомарно, что снижает риск "полурабочего" состояния сети.
— Облачные образы: Начиная с Debian 12 "Bookworm", Netplan является инструментом по умолчанию для облачных образов Debian (официальная документация). Также он стандартен в Ubuntu Server и облачных средах.

👀 Основные команды

# Генерация конфигурации для выбранного бэкенда (networkd или NetworkManager)
sudo netplan generate

# Применение новой конфигурации (без перезагрузки)
sudo netplan apply

# Отладка: вывод текущей конфигурации в виде YAML
sudo netplan get all

👀 Пример конфигурации (/etc/netplan/01-netcfg.yaml)

network:
  version: 2
  renderer: NetworkManager 
  ethernets:
    enp3s0: 
      dhcp4: false
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 77.88.8.8 
          - 77.88.8.1

Где:
— version: 2 — актуальная версия схемы Netplan.
— renderer — выбирает движок (networkd или NetworkManager).
— ethernets — раздел для проводных интерфейсов.
— addresses — статический IP с маской.
— routes — маршрут по умолчанию (default).
— nameservers — DNS-серверы.

Netplan — это современный, декларативный подход к настройке сети, который становится стандартом в Linux-дистрибутивах, особенно в серверных и облачных сценариях. Его стабильность подтверждается выходом версии 1.0

#линуксятина

📚 Ubuntu: Библия Linux 11-е издание

👏 Обновлённое руководство по Ubuntu: от первых шагов и настройки рабочего окружения до администрирования серверов, безопасности и развёртывания в облаке/контейнерах.

🔎 Рассматривается:

— установка и настройка Ubuntu Desktop и Ubuntu Server (включая типовые сценарии развёртывания);
— базовые навыки «power user»: терминал/оболочка, файловая система, права, процессы, простые shell-скрипты;
— администрирование системы: учётные записи, диски и файловые системы, LVM, базовые админ-инструменты;
— серверная часть: SSH и удалённый доступ, сеть, systemd, печать (CUPS), веб-сервер (Apache), FTP (vsftpd), Samba, NFS;
— диагностика и устранение проблем (boot/сеть/пакеты/режим восстановления);
— безопасность: базовые практики, AppArmor, криптография, PAM, сетевые сервисы и firewall-аудит;
— облака и контейнеры: виртуализация, контейнеры, cloud-init/LXD, развёртывания в облаке, Ansible, Kubernetes (включая EKS);
— практический акцент: задания и вопросы в конце глав;
— отдельные примеры «прикладных» задач, включая работу с популярными IoT-устройствами.

Полезно тем, кто осваивает Ubuntu с нуля, переходит с Windows на Linux, а также инженерам и администраторам, которым нужен один источник по пользовательской части, серверным ролям и базовой безопасности Ubuntu.

Авторы:
Дэвид Клинтон, Кристофер Негус
Издательство:
Уайли, 2025 г

#книги

🏓 ИТ-ландшафт России в 2026

Изменения затрагивают не отдельные решения, а правила управления ИТ — как выбирают технологии, как разделяют контуры, как защищают данные и как организуют выпуск изменений в действующие системы, особенно в компаниях с КИИ и ПДн.

👁 Вот что сильнее всего влияет на работу ИТ-команд и процессы:

💬 Технологическая независимость и переход на российский стек

Компании всё чаще стандартизируют стек целиком: ОС, виртуализация, БД, инструменты разработки, мониторинг, средства резервного копирования (СРК), средства защиты. На значимых объектах КИИ и у госзаказчиков действует запрет на иностранное ПО, поэтому выбор решений становится жёстче.

Как влияет: больше архитектурных решений и пилотов; обязательное тестирование совместимости; плановые миграции; усиление управления поставщиками и поддержкой.

💬 КИИ и требования к киберустойчивости

Требования закреплены в регулировании: учёт активов, меры защиты, контроль изменений, готовность к инцидентам и проверкам; в 2025–2026 регуляторы уточняют и обновляют нормы и инициативы по КИИ.

Как влияет: появляются отдельные контуры и регламенты для значимых систем; растёт объём обязательной документации; регулярные учения и проверки; усложняется согласование и внедрение изменений.

💬 Персональные данные

Многие продолжают приводить потоки данных в соответствие обновлённой норме о локализации (первичная запись и хранение в РФ), а также выстраивают юридически корректную трансграничную передачу там, где она нужна.

Как влияет: пересборка архитектуры хранения и интеграций; замена части внешних сервисов; усиление контроля доступов и журналирования; больше согласований с юристами и ИБ.

💬 Безопасность встраивается в разработку и выпуск изменений

Проверки и требования по ИБ начинают работать как часть процесса разработки и релизов, чтобы находить риски до выхода в промышленную среду.

Как влияет: добавляются security-gates в CI/CD; растёт роль управления уязвимостями и зависимостями; меняется определение готовности задачи и релиза.

💬 Национальный режим в закупках и требования к реестрам

В закупках для госсектора и организаций под 44-ФЗ/223-ФЗ усиливается влияние национального режима и критериев отечественных решений, включая привязку к реестрам.

Как влияет: меняются критерии выбора продуктов; увеличивается срок закупочного цикла; требуется больше обоснований и сравнения аналогов; растёт нагрузка на ИТ и закупки.

💬 Коммуникации с клиентами и сотрудниками: ограничения на иностранные мессенджеры

Для ряда организаций действует запрет на использование иностранных мессенджеров при взаимодействии с гражданами и клиентами.

Как влияет: переход на разрешённые каналы; пересмотр клиентских сценариев поддержки; обновление политик и обучение сотрудников; контроль того, какие данные уходят в коммуникации.

💬 Управление данными

Логика нацпроекта “Экономика данных” усиливает практику управления данными как ресурсом: качество, доступность, безопасность, измеримые показатели.

Как влияет: появляются владельцы данных и правила доступа; развиваются каталоги данных и витрины; больше требований к интеграциям и качеству.

💬 ИИ в прикладных процессах и его управление

Инструменты на основе генеративного ИИ всё больше входят в офисные и инженерные процессы, параллельно обсуждаются подходы к регулированию и требованиям к применению ИИ.

Как влияет: нужны правила, где ИИ можно использовать и с какими данными; требования к контролю качества результатов; пересмотр политики по данным и коммерческой тайне; новые роли и навыки в командах.

🎙️ За неделю

✉️ Импортный корпоративный софт всё ещё у 72% российских компаний.
Многие компании продолжают использовать зарубежные системы: российские альтернативы не всегда сопоставимы по функциональности, а стоимость отечественного ПО остаётся высокой.

✉️ РКН нашёл нарушения по ТСПУ у 33 операторов связи.
Часть дел уже в судах со штрафами, остальные — на рассмотрении; при повторных нарушениях штрафы выше.

✉️ Microsoft выпустила январские обновления безопасности: исправили 114 проблем, включая CVE-2026-20805 в Windows, которую уже используют в реальных атаках. Уязвимость внесли в список CISA KEV. Для компаний с парком Windows, VDI и терминальными серверами патчинг стоит поставить в приоритет. Такие уязвимости часто помогают злоумышленникам закрепиться и продвинуться дальше по сети.

✉️ DDoS-атаки в РФ за 2025 год выросли в 1,8 раз
Чаще всего атаковали телеком (34%), финсектор (21%) и ритейл (16%); всплески нередко приходились на распродажи и праздничные дни.

✉️ Прогноз по киберугрозам для телекома:целевые длительные атаки, атаки через цепочку поставок и DDoS никуда не денутся. Параллельно растут риски: ИИ-автоматизация увеличивает вероятность ошибок конфигурации, постквантовая криптография может дать проблемы совместимости и производительности, а интеграция 5G со спутниками добавит новые точки стыковки и усилит зависимость от партнёров.

📦 Как Kubernetes хранит состояние в etcd

Где лежат данные кластера, как API Server отслеживает изменения и почему etcd запускают кластером.

🟡 API Server
— читает/пишет объекты Kubernetes в хранилище etcd; ставит watch на нужные префиксы; получает уведомления об изменениях.

🟡 etcd
— распределённое key-value хранилище, где сохраняется состояние кластера.

🟡 Key space /registry/...
— данные разложены по типам ресурсов: pods, services, namespaces, secrets, configmaps, events, serviceaccounts и др.; API Server может следить за изменениями по разделам.

🟡 etcd Cluster + RAFT
— несколько узлов синхронизируются по RAFT, чтобы сохранять консистентность и переживать отказы.

🟡 Quorum и fault tolerance
— кворум: (n/2)+1 узлов должны быть доступны;
— допустимые потери: (n-1)/2;
— минимум 3 узла etcd, чтобы выдержать падение одного.

#полезное

🎮 Server Survival — браузерный симулятор, где нужно собрать архитектуру из типовых компонентов и удержать систему в рабочем состоянии при росте RPS и всплесках трафика, укладываясь в бюджет.

🎮 Основной функционал:

⏺ Типы запросов и маршрутизация: STATIC/UPLOAD → Storage; READ/WRITE/SEARCH → SQL DB; MALICIOUS блокируется Firewall.

⏺ Конструктор схемы: размещение узлов, связь/разрыв связей (link/unlink), удаление компонентов с частичным возвратом средств.

⏺ Компоненты: Firewall, Queue, Load Balancer, Compute, SQL DB, Cache, Storage, CDN; для части доступны tier/апгрейды.

⏺ Эксплуатация и режимы: ремонт/auto-repair; Survival и Sandbox.

👍 Полезно DevOps/SRE/Backend-инженерам: можно быстро увидеть, где формируются узкие места, и как на них влияют балансировка, очередь, кэш и апгрейды компонентов. Также это удобный формат для командного обучения: за короткое время можно собрать несколько вариантов под заданный профиль трафика и сравнить результат по ошибкам, репутации и бюджету.

#полезное

⚙️ Инструменты для централизованного логирования

✅ ELK Stack (Elastic Stack) — Классический и мощный стек от Elastic. Включает Elasticsearch (хранилище и поиск), Logstash (обработка и обогащение данных) и Kibana (визуализация и анализ). Универсальное решение для полнотекстового поиска и сложной аналитики.

✅ Grafana Loki — Легковесное и экономичное решение от Grafana Labs. Хранит только метаданные и сжатые логи, а сами логи остаются в объектном хранилище. Идеально интегрируется с Grafana и Prometheus для единой observability-панели.

✅ Fluentd — Универсальный сборщик данных с открытым исходным кодом. Помогает унифицировать сбор и доставку логов в различные хранилища (от Elasticsearch до облачных сервисов). Имеет богатую экосистему плагинов.

✅ Graylog — Готовое коробочное решение для управления логами с удобным веб-интерфейсом. Включает прием, обработку, хранение и анализ логов. Особенно силён в сценариях, связанных с безопасностью и compliance.

#полезное

GitLab CI Components —переиспользуемые, параметризуемые блоки конфигурации CI/CD, которые позволяют применять принцип DRY (Don't Repeat Yourself) в пайплайнах GitLab.

📎 Компоненты были представлены в GitLab 16.0 как экспериментальная функция, а в версии 17.0 стали общедоступными. Механика похожа на модули в Terraform или пакеты в языках программирования.

✅ Зачем это нужно?

— Избежать дублирования кода: Устранить копирование одинаковых jobs и steps в разные .gitlab-ci.yml файлы.
— Стандартизировать процессы: Создать единые, проверенные шаблоны для часто выполняемых задач (сборка, тестирование, деплой).
— Упростить поддержку: Обновить логику в одном месте (компоненте), и изменения применятся во всех проектах, которые его используют.
— Создавать библиотеки шагов: Делиться готовыми решениями внутри команды или сообщества.

✅ Ключевые принципы:

🔵Компонент — это файл .yml с определением одной или нескольких джоб, который хранится в отдельном репозитории GitLab.

🔵Include — Подключение компонента в .gitlab-ci.yml с помощью директивы include: component.

🔵Параметры — Компоненты принимают входные параметры (inputs), что делает их гибкими и адаптируемыми.

✅ Практический пример:

Простой компонент для линтера (.gitlab/ci/components/linter.yml в отдельном репозитории)

# Определение компонента
spec:
  inputs:
    stage:
      default: test
    image:
      default: "node:20-alpine"

"lint-$[[ inputs.linter ]]": # Динамическое имя джобы
  stage: $[[ inputs.stage ]]
  image: $[[ inputs.image ]]
  script:
    - run-lint --linter $[[ inputs.linter ]]

Использование компонента в проекте:

# .gitlab-ci.yml вашего приложения
include:
  # Указываем полный путь к компоненту
  - component: gitlab.example.com/org/ci-catalog/linter@main
    inputs:
      linter: "eslint"

GitLab CI Components — это эволюция подхода к CI/CD как к коду. Они позволяют заменить рутинное копирование десятков строк конфигурации в каждом проекте на подключение готового компонента. В результате CI/CD-конфигурация превращается из монолитного скрипта в набор декларативных, версионируемых и легко тестируемых модулей.

➡️ Подробнее в документации Gitlab

#заметкиИнженера

🔃 Renovate — инструмент для автоматического обновления зависимостей в проектах.

Он мониторит репозитории, находит устаревшие пакеты, библиотеки или образы контейнеров и автоматически создает Pull/Merge Requests с обновлениями.

⚙️ Основной функционал:
— Автоматическое сканирование репозитория на наличие зависимостей (npm, Docker, Maven, Helm, Terraform, Go и более 20 других менеджеров пакетов).
— Проверка доступных обновлений в реестрах пакетов (npmjs, Docker Hub, Maven Central и др.).
— Создание отдельного PR для каждого обновления с информацией о версиях, changelog и проверками совместимости.
— Группировка нескольких обновлений в одном PR (например, все патчи для библиотеки).
— Автоматическое разрешение конфликтов и пересоздание PR при появлении новых версий.
— Интеграция с GitHub, GitLab, Bitbucket и Azure DevOps.

👀 Ключевые особенности:
— Автономный бот: Работает как GitHub App, GitLab App или в self-hosted режиме.
— Политики обновлений: Можно настроить автоматический мерж для minor/patch версий, require статусы проверок, расписание (например, только по будням).
— Безопасность: Встроенная проверка уязвимостей (CVE) через интеграцию с Snyk, OSV.
— Широкий охват: Поддерживает не только языки программирования, но и инфраструктурные инструменты (Terraform, Ansible, Helm, Dockerfile).

Renovate избавляет разработчиков от рутины ручного отслеживания версий зависимостей, обеспечивая своевременные и безопасные обновления.

👉 Git
#полезное

🖥 Shell в Linux: Интерфейс между пользователем и системой

Командная оболочка (shell) — это программа-интерпретатор, которая принимает команды от пользователя (введённые в текстовом терминале) и передаёт их операционной системе на выполнение. Это основной способ взаимодействия с Linux для администрирования, автоматизации и разработки.

🟢 Основные виды современных шеллов:

✅ Bash (Bourne Again Shell)
Стандартный и наиболее распространённый шелл, установленный по умолчанию почти во всех дистрибутивах.
Особенности: Полная обратная совместимость с классическим Bourne shell (sh), мощное скриптование, автодополнение через Tab, история команд.

✅ Zsh (Z Shell)
Продвинутая оболочка, набравшая огромную популярность благодаря проекту Oh My Zsh.
Особенности: Улучшенное автодополнение (в т.ч. путей и опций), использование разных тем, встроенная коррекция опечаток, модульная архитектура, расширенная подстановка файлов (globbing) , лучшая поддержка Unicode.

✅ Fish (Friendly Interactive Shell)
Шелл, ориентированный на интерактивность и удобство использования прямо «из коробки».
Особенности: Автодополнение на основе истории и мануалов, подсветка синтаксиса прямо в командной строке, удобная конфигурация (fish_config), интуитивно понятный скриптовый язык. Из минусов — неполная совместимость с Bash-синтаксисом.

🟢 Как узнать текущий shell пользователя?

# Показать текущую активную оболочку
echo $SHELL

🟢 Смена оболочки по умолчанию для пользователя

Изменить шелл можно с помощью команды chsh (change shell).

# Сменить оболочку текущего пользователя на zsh 
sudo chsh -s /bin/zsh

# Выйти и зайти в систему заново, чтобы изменения вступили в силу
exit

Выбор оболочки — это баланс между мощью и совместимостью (Bash), кастомизацией и сообществом (Zsh) или удобством и простотой (Fish). Для большинства системных задач и скриптов Bash остаётся де-факто стандартом, а для персональной рабочей станции многие выбирают Zsh или Fish за улучшенный пользовательский опыт.

#линуксятина

📚 Командная строка Linux (2-е издание)

Практичное введение в Linux через командную строку: от базовой работы в оболочке до автоматизации на shell-скриптах.

Фундаментальная основа, которая надолго остаётся применимой в работе с правами, bash и текстовыми утилитами.

🔍 Рассматривается:

— основы работы в shell: команды, навигация, файлы/каталоги, права, процессы, перенаправления;
— окружение и настройка: переменные, профили;
— ключевые утилиты для повседневных задач: поиск, архивация, работа с текстом, регулярные выражения, обработка потоков;
— сеть и базовые системные действия на уровне пользователя;
— введение в написание shell-скриптов: структура, условия/циклы, параметры, функции, обработка строк и ошибок;
— подход «учусь, делая»: много практических примеров и команд, которые реально встречаются в работе.

Автор:
Уильям Шоттс
Издательство:
No Starch Press, 2019г.

#книги