Пятничное чтиво от DevOps FM

Сегодня поговорим об инфраструктурных мелочах с большими последствиями.

👀Что могло пойти не так, но с версией Kubernetes 1.35 будет работать корректно
• Под уверенно занял порт на хосте, а потом мы выяснили, что все процессы внутри работали как root. Хорошо, что теперь это можно настроить.
• Для распределённой задачи требуется 10 рабочих подов, а запустилось только 5. Что с этим делает Kubernetes 1.35?
• Образ на узле, ресурсов хватает, но под не стартует – kubelet проверяет наличие imagePullSecrets.
• Кластер не поднялся после обновления узлов. При чём тут cgroup v1 и релиз 1.35? Читайте в статье.

👀5 ошибок DevOps стартапа (версия 2025)
• DevOps как набор инструментов
Контуры процессов, технический стек внедрены, а совместной ответственности и быстрой обратной связи всё ещё нет.
• Команды работают разрозненно
Разработка, эксплуатация и безопасность живут в своих мирах – потом долго ищут виноватых и чинят одно и то же.
• Гонка за скоростью без прозрачности.
Релизы частые, но без мониторинга и логов проблемы находят пользователи, а не команда.
• Ручные операции там, где давно нужна автоматизация.
Деплой «по инструкции», инфраструктура «на память», подборка ошибок – человеческих и повторяющихся.
• Безопасность на «потом»
Сканирование, политики и контроль доступа подключают после инцидента, когда уже поздно.
Подробности читайте здесь.

👀Побойтесь DevOps-а…
Компания искала DevOps-инженера, чтобы навести порядок в инфраструктуре, и наняла специалиста с полными правами на продовые серверы. Прошло время и сотрудничество прекратили: доступы отозвали, пароли сменили, учётки заблокировали. Спустя пять дней прод внезапно упал: сервисы недоступны, логи выглядели «разорванными», массовая утечка данных. В ходе внутреннего расследования выяснили – до увольнения был создан скрытый пользователь с правами root, через VPN добавлена отложенная cron-задача на уничтожение системы, а после срабатывания последовал шантаж с требованием выкупа. Как всё закончилось? Читайте здесь.

🚀Приятного чтения! Пусть все инциденты сегодня будут только на Habr.

#пятничноечтиво #kubernetes #devops #security

🎙️Слушаем пятничную подборку подкастов в DevOps FM!

⏺Flox, Nix, and Reproducible Software Systems от Software Engineering Daily. В новом выпуске затронули проблему воспроизводимости и безопасности в современной разработке ПО и обсудили, как подход Nix к управлению пакетами и зависимостями повышает воспроизводимость и безопасность, а также роль Flox в проектах. Болл предложил варианты деплоя без классических больших Docker-образов, поднял вопросы мультиархитектурных разрешений зависимостей (разрешение «closures» и групп пакетов) и их ограничения на практике. Узнать детали – здесь.

⏺We Broke Our EKS Cluster Autoscaler with the AL2023 Migration от Kube FM. Барт Фарелл разбирает инцидент, который возник при миграции EKS на Amazon Linux 2023. Почему после обновления AMI автоскейлер потерял AWS-права в кластере, как корректно внедрить IRSA (IAM Roles for Service Accounts), проверить зависимость конкретных подов от IAM-ролей нодов и очистить устаревшие IAM-разрешения, чтобы сократить атаки после миграции – слушайте тут.

⏺ Engineering Around Extreme S3 Scale with R. Tyler Croy от Last week in AWS. Р. Тайлер Крой, инженер Scribd, рассуждает с Кори Куинном о проблеме хранения миллиардов объектов в облачном объектном хранилище S3 и. Как организовать работу, когда простые задачи обходятся компании в 100 000 долларов. В подкасте услышите тезисы о распределении бюджета на инфраструктуру в облаке, опыт Scribd, накопленный за 18 лет на рынке. Крой настаивает – стандартные решения больше не работают при большом потоке вводных данных, нужно генерировать новые. Подробности – здесь.

Приятного прослушивания и пятниц без инцидентов🛡

#подкаст #devops #kubernetes #eks

Релизы и безопасность

Срединедельный DevOps! Поговорим о том, как Cozystack 0.41 добавляет MongoDB и улучшает стабильность Kubernetes, а MX Linux 25.1 возвращает поддержку dual-init-a.

⏺Cozystack v0.41.0: MongoDB
Вышел релиз версии Cozystack. В v0.41.0 добавили поддержку системы управления БД MongoDB. Она располагается наряду с PostgreSQL, MySQL и Redis. К ключевым особенностям относим интеграцию с хранилищем бэкэндов Cozystack, настраиваемые CPU, встроенный экспорт метрик для мониторинга. Чтобы развернуть MongoDB через Cozystack дашборд используйте первый и второй workflow. Также, в новой версии представлены улучшения в работы хранилища, патчи для piraeus-server, рефакторинг проверки RWX на уровне года, повышение стабильности работы Kubernetes за счет увеличения значений resourcesPreset apiServer по умолчанию до large и увеличения порог startup-probe для kube-apiserver. Подробнее о релизе – тут.

⏺Опасайтесь VoidLink
На портале Checkpoint Research опубликовали отчёт о мультифункциональном вредоносном ПО китайского происхождения. VoidLink включает 37 плагинов, среди которых есть модули для устранения следов, выхода из контейнеров, сбора SSH-ключей, токенов и API-ключей. Фреймворк ориентирован на cloud- и container-first-среды и способен стабильно работать в Kubernetes и Docker, адаптируя поведение под окружение. Используются LD_PRELOAD, загружаемые модули ядра (LKM) и eBPF. Подробнее - здесь.

⏺Бесконечность не предел: MX Linux 25.1 «Infinity»
Релиз MX Linux 25.1, Debian-based дистрибутива. Все сборки поставляются с ядром Linux 6.12 (Debian-ветка), за исключением Xfce-AHS, где используется ядро 6.18 с патчами liquorix. В AHS-сборках также обновлён Mesa до версии 25.3.3. Включены все обновления Debian до Debian 13.3 и все актуальные обновления из репозиториев MX. В релизе анонсировали возвращение поддержки dual-init (systemd + sysvinit) в едином ISO-образе, что сокращает количество сборок, systemd теперь обновляется через Debian, а не через отдельный MX-пакет, что упрощает поддержку. Для желающих установить – инструкция тут.

#devops #cozystack #mxlinux #kubernetes #platformengineering

Новые Ops-ы: как мы дошли с Dev-а до Fin-a

В эту пятницу закрываем следующие таски: зачиллиться на дежурке (отдыхающим, просьба не завидовать 👨‍💻), не завалить прод и окунуться в историю. Если не задумывались, как от DevOps-а за 18 лет мы дошли до FinOps, зачем нам DevSec и ML – давайте разбираться вместе.

⏺DevOps умер, да здравствует DevOps!
Традиционно, считаем, что DevOps начал свой путь с модели Agile. Но мало кто упоминает пре-DevOps эру Waterfall (1970-1990-е), тёмное время для инженеров. Команды работали изолированно, Dev лишь «передавал» продукт Ops на запуск. Длинные циклы, редкие релизы, а ошибки дорого обнаруживать и ещё дороже исправлять. К счастью, в начале нулевых Agile сократил цикл от идеи до кода и дал возможность быстро тестировать гипотезы. Что было дальше, знаем: этапы роста первого (и основного) Ops-а – тут. Кстати, если вы думаете, что DevOps умирает, прочтите заметку о текущем «здоровье» – здесь.

Когда скорость разработки пришла в норму, появилась новая проблема – безопасность в CI/CD.

⏺Зачем нужна безопасность? Роль Sec-а в DevOps
Если DevOps-инженеры сосредоточены на том, как быстрее вывести приложение на рынок, этап тестирования безопасности, закономерно, уходит в конец рабочего цикла. В десятых годах 21-го века по мере совершенствования инструментов и развития процессов стало ясно – ни один отдел ИБ не успевает проверить все релизы. На помощь пришла методология DevSecOps которая устраняет уязвимости, обнаруженные в быстро меняющихся средах DevOps. В уходящем году мы успели поговорить о мифах DevSecOps, но главный вопрос открыт – что ждет DevSec сегодня? Всё об использовании инструментов 2026 читайте – тут, и там.

Как мы радовались первым чат-ботам и грезили о светлом будущем в мире ИИ. Стоило немного разобраться в его влиянии на воркфлоу и изменения цикла разработки.

⏺MLops – новый этап развития в поставке ПО
Казалось бы, процесс разработки отлажен, безопасность обеспечили, так еще и автоматизированные помощники появились. Около 8-ми лет назад компании радовались новой реальности и внедряли практики машинного обучения в рабочие процессы. Результат довольно предсказуем – около 85% проектов в области AI и ML так и не дошли до продакшена. В 2026 команды сталкиваются с техническими проблемами и сбоями в CI/CD пайплайнах и обновленной инфраструктуре (вектора DBs). Подробнее о развитии MLops – тут, а ТОП-10 инструментов ML в Ops 2026 года – здесь.

Наконец, проблемы решены, можем расслабиться… подумало сообщество, но «слишком хорошо» превратилось в «плохо».

⏺Что такое FinOps-культура и как она полезна команде?
Когда инфраструктура требовала масштабирования, её просто наращивали, и это почти не требовало объяснений. Теперь ресурсы растут соразмерно стоимости, и каждое техническое решение внезапно требует пояснений и обоснований. Оптимизация расходов – не дополнительная опция или задача под звездочкой, а новая реальность. FinOps Foundation отмечает, что компании, которые используют FinOps-практики, экономят 20–30% затрат в облаке и одновременно повышают вовлечённость команд. Team-lead инфраструктурного отдела, DevOps-инженер Nixys Пётр Рукин совместно с Практиками FinOps обозначили, кто должен заниматься внедрением культуры, как это осуществить и что с этого получают инженеры – на Habr.

А вы готовы к следующему Ops? Какие практики, по вашему мнению, станут обязательными в будущем?

#devops #devsecops #mlops #finops

Чем запомнился январь? Релизы Jenkins, Cluster API в Kubernetes и альтернативы Ingress-nginx

Всем DevOps! В эту среду сосредоточимся на изменения в политике безопасности Jenkins, новые сценарии обновлений в Cluster API и обсуждение альтернатив Ingress-nginx.

⏺Jenkins – изменения в политике безопасности, RPM-пакетировании для Red Hat и openSUSE
В релизе Jenkins 2.528.3 добавили поддержку Java 25 для контроллера и агентов, а также образы Windows Server 2022 для контейнеров. Для LTS RPM и DEB репозиториев введён новый GPG-ключ, который администраторам нужно принять при обновлении. Серьёзные изменения версии 2.528.3 коснулись управления Content Security Policy через интерфейс и API для плагинов. Пакеты Jenkins для Red Hat и openSUSE объединены в единый RPM-репозиторий с новым адресом: https://pkg.jenkins.io/rpm-stable/ . Для прошлых LTS-версий Jenkins (2.528.3 и раньше) сохранён отдельный архивный репозиторий: https://pkg.jenkins.io/redhat-stable-legacy/ .Больше о релизе – тут.

⏺Cluster API v1.12 – обновления «на месте» и «в цепочке»
В блоге Kubernetes вышла статья о новой версии Cluster API, инструменте для декларативного управления жизненным циклом кластеров. Подобно тому, как в Kubernetes можно использовать StatefulSets или Deployments для управления группой pod-ов, в Cluster API можно использовать MachineDeployments для управления группой nod-ов. В релизе представлены обновления in-place через update-extensions, теперь изменения применяются к существующим нодам без пересоздания, и chained upgrades для обновления несколько минорных версий без ручного вмешательства. Смотрите на GitHub – подробности о релизе, преимущества обновлений.

⏺Архив Ingress-nginx: какие альтернативы?
В уходящем году команда проекта Ingress-nginx сообщила о прекращении поддержки в марте 2026, подробнее писали тут. В блоге CNCF опубликовали статью о преимуществах и недостатках перехода на другой контроллер входящего трафика (Cilium Ingress, Traefik, HAProxy Ingress), или внедрения Kubernetes Gateway API. На примере Cilium Ingress первый вариант был признан самым быстрым: вы вносите минимальные изменения в манифесты приложений, CI/CD и работаете со встроенной функцией мониторинга. По версии CNCF переход на Gateway API от Cilium – самый оптимальный. Как мигрировать на Cillium Ingress – тут, а подробнее о переходе на Gateway API – здесь.

#devops #kubernetes #cloudnative #opensource

Ingress NGINX: замены нет или миграция возможна?

👤На Reddit-е обсудили прекращение поддержки Ingress NGINX, работу кластеров, которые не получают обновления безопасности, а пользователи поделились своим негодованием и возможностями миграции. Статья CNCF по альтернативам – чуть выше, а полный тред – здесь.

Реакцию пользователей на новость можно уместить в один комментарий:

Kubrador
kubectl apply -f divorce.yaml
ах да, классическая смерть open source: «пожалуйста помогите нам» в течение 4-х лет –> «ладно, с нас хватит» –> «стоп, почему никто не помогает 🙁 » в то время, как 50% кластеров k8s внезапно понимают, что они живут в доме, построенном на фундаменте надежд и молитв.

⏺Теперь перейдем к решениям, инженеры разделились на два лагеря: первый не обновляется, т.к. не видит смысла в «лишней» работе:

32b1b46b6befce6ab149
Да ну конечно, люди используют Ingress NGINX. Я тоже не обновляюсь.
На данный момент никакого аналога с прежним функционалом нет и миграция займет много времени.
Полностью переехать на Gateway API нельзя, многие public чарты всё ещё используют Ingress. Лично я не нашёл такого аналога, чтобы точь-в-точь (если он вообще есть, потому что даже у nginx-ingress немного другие аннотации), поэтому пользуюсь тем, что есть.

Плюс, не вижу смысла, нельзя мигрировать без прерывания трафика.

Rahomka
Всё равно на проблему вообще, мы не обновляемся

⏺Второй – использует Gateway API и дает рекомендации по альтернативам:

mirrax
Вопрос к тем, кто не обновляется, в чем проблема? Что вы такого делаете, что прям зависит от аннотаций NGINX? Вы не сможете разобраться со всем этим у другого провайдера или использовать Gateway?

EpicDan
Вы же не обязаны использовать встроенные Ingress'ы в public чартах, можно для каждого приложения добавить HTTPRoute через Gateway API, работает нормально.

pilchardus_
Мне кажется, больше 50% k8s кластеров на NGINX, лол. Лично я переезжаю на Traefik на этой неделе.

me1337
Я переехал на F5 NGINX Ingress – без проблем, всё завелось.

FluidIdea
Лично мне нравятся Envoy Gateway (EG) или kgateway, по бенчмаркам хороши. Traefik – не единственный вариант.

edeltoaster
Я уже полностью переехал на Gateway API и Envoy Gateway. Плюс собрал свой кастомный образ с расширением Go-native от Coraza. Управление входящим трафиком стало заметно лучше, пока доволен.

👀Из интересного, Кэт Косгров (K8s Steering Committee) и Табита Сэйбл (SIG Security) в подкасте предположили, что не все инженеры в курсе, поддерживаются ли их кластеры Ingress NGINX, на что пользователи справедливо отметили:

Kabrandon
Не так легко узнать, работаете ли вы с Ingress NGINX? Может, вы не мейнтейнер? Если работаете с кластерами напрямую, вы по-любому знаете, на каком ingress контролере. Сомневаюсь, что вы работаете в таком случае.

Uncommon_senze
Легко понять, используете ли вы его, он не развертывается и не настраивается сам. Но да, проблема большая.

💬Что думаете об альтернативах, уже перешли на Gateway API? Делитесь опытом в комментариях.

#devops #reddit #k8s #ingress-nginx

Slash-команды в GitHub Copilot CLI

👩‍💻 Всем DevOps! Сегодня рассмотрим slash-команды, которые помогают быстрее работать с кодом и управлять контекстом прямо в терминале. Так, вы экономите время на тестировании, исправлении багов и переключении между задачами. Обзор команд – ниже.

👀Чем полезен инструмент?
GitHub Copilot CLI доступен в режиме public preview с сентября 2025 года. Инструмент пригодится при работе вне IDE: с серверами через SSH, контейнерами, CI/CD-пайплайнами, репозиториями. GitHub Copilot CLI нужен для взаимодействия внутри GitHub без переключения контекста. Подробнее – тут. Slash-команды обеспечивают быструю установку MCP-сервера, выбор ИИ-модели под текущий запрос. По сути, мы говорим о фиксированных промтах, инструкциях, которые вводим через префикс и / в CLI.

Подборка:
⏺Команды управления сессией:
/clear – очистить контекст текущей сессии. Используется при смене задач, репозиториев или если накопленный контекст начинает влиять на подсказки.
/exit, /quit – завершить сессии, выход из CLI
/session, /usage – посмотреть информацию о сессии и статистика использования. Полезны для аудита активности, мониторинга действий Copilot
⏺Работа с директориями и файлами:
/add-dir <directory> – добавить директорию для доступа Copilot. Ограничивает область видимости и повышает безопасность.
/list-dirs – показать список директорий, доступных Copilot.
/cwd [directory] – показать или сменить рабочую директорию.
⏺Настройки и конфигурация
/model [model] – выбрать модель Copilot для CLI.
/theme [show|set|list] – управлять темой терминала, единый стиль для команды.
/reset-allowed-tools – сбросить разрешения на использование инструментов. Полезна для аудита.
⏺Внешние сервисы
/agent – выбрать Copilot-агента для отдельных задач.
/delegate <prompt> – делегировать задачи агенту с pull-request-ом.
/share [file|gist] – экспортировать сессии в Markdown или GitHub Gist для документации или передачи коллегам.
/login, /logout – войти/выйти из CLI, управлять доступом, сменить пользователя
/mcp [show|add|edit|…] – управлять конфигурацией MCP-серверов, обновить CI/CD прокси-конфигурации и enterprise настройки.
/user [show|list|switch] – управлять пользователями GitHub в терминале.
/help – список всех команд.
/feedback — сообщить об ошибках команде GitHub.

📎Подробнее о каждой команде – здесь и в GitHub Docs.

#devops #github

🔧Чиним кластеры: игра по освоению Kubernetes

В эту пятницу отправляемся в приключение! На GitHub вышел K8sQuest для тех, кто устал читать доки и хочет разобраться, как дебажить в проде на практике. В игре представлены 5 миров и 50 уровней, где предстоит разбираться с реальными проблемами внутри кластера:
⏺Мир 1: CrashLoopBackOff, ImagePullBackOff, pending поды, метки, порты
⏺Мир 2: Deployments, HPA, пробы работспособности и готовности, откаты
⏺Мир 3: Сервисы, DNS, Ingress, Сетевые политики
⏺Мир 4: PVs, PVCs, StatefulSet-ы, ConfigMap-ы, Секреты

На 50-м уровне воцарится хаос: море ошибок, шторм неопределённости :) Будет интересно новичкам и опытным инженерам.

🚀Делитесь в комментариях, до какого уровня дошли! Желаем хороших выходных, а дежурным – спокойных смен.

#devops #k8s #пятница

Что меняется с Docker v29.1 и Docker Compose (v2.40) на GitHub-runner'ах?

Бодрый DevOps! 🖖Понедельник начинаем с анонса. GitHub анонсировал обновления Docker и Docker Compose на hosted-runner'ах, rollout стартует уже сегодня, 9 февраля.
Речь идёт о Docker Engine v29.1, Docker Compose v2.40.3. Обновление на runner-ах коснётся всех Windows и Ubuntu образов, кроме ubuntu-slim.

В ветке v29 были внесены изменения в Docker Engine API, вынесены Deprecated фичи и опции CLI. В заметках релизов указали – обязательно убрать %PROGRAMDATA%\Docker\cli-plugins из листа для CLI-плагинов на Windows, переместить на %ProgramFiles%\Docker\cli-plugins. При использовании GitHub Actions изменения могут затронуть текущие workflow’ы. Мы рекомендуем протестировать сборки на версии v29 до начала обновления runner’ов. Апдейт нацелен на повышение безопасности.

Что сделать уже сейчас:
⏺Протестировать локально с Docker Engine v29.1 и Compose v2.40.3
Проверить сборки, пуш образы, docker-buildx, сети, volume-mounts.
⏺Просмотреть свои workflow
Какие deprecated фичи и CLI-опции используются
⏺Закреплять версии (pin) в критичных конвейерах или запускать тесты на self-hosted раннерах/локально перед 9 февраля.
⏺Отсматривать изменения GitHub Actions runner images в репозитории actions/runner-images
⏺Следить за подробностями и возможными изменениями окружений.

👀Подробнее об обновлениях читайте в:
•Docs Docker
•Репозитории

#devops #release #docker

Как CPU weight влияет на Kubernetes: переход на cgroup v2

👩‍💻 Итамар Холдер из Red Hat разбирает новую формулу перехода CPU shares из cgroup v1 в CPU weight для cgroup v2. Ранее при простом пересчёте контейнеры с 1 CPU получали слишком низкий приоритет по сравнению с процессами вне Kubernetes, а мелкие CPU-запросы невозможно было точно распределять внутри под-cgroups. Новая формула восстанавливает приоритет по умолчанию.

⌨️Внедрение и практика
• Изменение реализовано на уровне OCI-рантаймов (runc ≥1.3.2, crun ≥1.23), а не в Kubernetes. Внедрение новой формулы зависит от того, какой OCI-рантайм используется в вашем кластере.
runc поддерживает новую формулу с версии 1.3.2
crun – с версии 1.23
• Перед применением тестируйте значения CPU weight в staging.
• Обратите внимание на инструменты мониторинга и кастомные системы управления ресурсами – прежние формулы могут дать неверные прогнозы и метрики.
Новая формула CPU weight нужна для расстановки приоритетов контейнеров, управления CPU-запросами и для предсказуемости распределение ресурсов, что особенно важно в работе с высокими нагрузками.

❕Что почитать дальше:
Kubernetes GitHub Issue #131216 – подробный технический разбор с примерами и обсуждением выбора формулы.
KEP-2254: cgroup v2 – исходник cgroup v2 в Kubernetes.
Документация по cgroup в Kubernetes – актуальные рекомендации по управлению ресурсами.

#devops #kubernetes #containers