DevOps для ДевоПсов

Ловите короткий практический видеокурс от Фланта про Kubernetes. Он идёт всего час, и посмотреть его можно за вечер, что не делает его менее ёмким. За 10 коротких видео вы поднимете локальный кластер на Minikube и по шагам дойдёте до рабочего приложения. Вы разберётесь с Pod и Deployment, сборкой образа и деплоем через werf, Service и labels, Ingress для доступа извне, Helm-чартами и не только. Отдельный плюс — это репозиторий с примерами кода, так что не обязательно повторять за ведущим на слух. :) Курс подойдёт не только разработчикам, но и в принципе всем, кто хочет потрогать k8s руками. Можно смело рекомендовать тем, кто не знает, с чего начать.

Pod завис в Pending? Вот по какой цепочке kube-scheduler решает, куда его посадить kube-scheduler не выбирает ноду случайно. Сначала Pod попадает в ActiveQueue и сортируется по приоритету — PriorityClass здесь решает, кто пойдёт первым. Потом идёт фильтрация: какие ноды вообще подходят по ресурсам, taint’ам и affinity. Оставшиеся кандидаты проходят scoring, где учитываются запрошенные ресурсы, topology spread и affinity. Если Pod не запланировался, смотрите kubectl describe pod: в Events увидите, на каком шаге отсеялись ноды и почему. Иногда причина в resource requests, иногда в taints или anti-affinity. Разбор на devops.dev проходит путь от очереди до binding и preemption.

Почему в Kubernetes падает DNS: чиним CoreDNS Если поды внезапно перестали резолвить имена, ломается всё, что работает по именам: базы, API, межсервисное взаимодействие. Первым делом запускаем дебаг-под и проверяем nslookup kubernetes.default и внешний домен. Если не работает — смотрим статус и логи CoreDNS. Часто причина в плагине forward: неправильные upstream-серверы, таймауты или перегрузка. Проверьте конфигурацию через kubectl get configmap coredns -n kube-system -o yaml, поправьте upstream, добавьте health_check и кэш, перезапустите деплоймент. При высокой нагрузке отмасштабируйте реплики или включите NodeLocal DNSCache. Разбор диагностики и примеры Corefile.

Накануне митапа мы публиковали пост о том, что в DKP CE стал доступен полноценный веб-интерфейс. О том, что стоит за этим веб-интерфейсом, на митапе рассказал Евгений Шевченко, технический директор веб-интерфейсов Deckhouse Kubernetes Platform (DKP). В основе Deckhouse UI есть несколько принципов: — единый UI для всех задач: администрирование и работа с нагрузкой в одном интерфейсе; — выбор между UI и CLI на любом уровне работы с платформой; — понятный и доступный интерфейс. Покрытие пользовательских сценариев в UI сейчас достигает 95% от возможностей CLI, и продолжает расти. Во время доклада разбирали конкретные фичи, кейсы и сложности, с которыми столкнулась команда. Запись доклада будет опубликована в @deckhouse_news.

Docker: namespaces и cgroups Когда контейнер падает с OOMKilled или порт не пробрасывается, не нужно гадать: это обычный Linux-процесс, который ядро ограничивает двумя механизмами. Namespaces дают ему изолированный вид — свой PID 1, таблицу маршрутизации и интерфейсы, mount-точки. Cgroups выставляют жёсткие лимиты на CPU, память и I/O, чтобы один контейнер не уложил хост. Посмотреть на изоляцию помогает unshare. Docker связывает контейнер через veth: один конец на мосте docker0, другой в namespace. За лимитами отвечают cgroups, которые Docker задаёт через docker run. Понимание этих двух механизмов спасает от «почему работает локально, а в проде падает». При инциденте смотрите сначала на них, а не на приложение. Разбор на dev.to.

Записи с митапа DUC будут доступны позже, а пока команда Deckhouse делится с вами материалами с DeckhouseConf 2026! Все материалы уже в открытом доступе, вот некоторые из них: 🔘Deckhouse — больше чем Kubernetes. Как изменились продукты Deckhouse за год и куда движется платформа; 🔘Путь к SDN: чего не хватает в классической сети Kubernetes? Какие сценарии не вписываются в стандартную сетевую модель Kubernetes, и как SDN помогает обойти ограничения; 🔘Делаем нормальные виртуалки в Kubernetes. Как виртуальные машины работают внутри пода, обеспечение их отказоустойчивости, методы живой миграции между гипервизорами и переноса дисков между хранилищами; 🔘Партизанский кластер DKP CE как прототип для закрытого контура. На конференции разбирали и другие важные, интересные темы. Все доклады вы найдёте в плейлисте на YouTube.

DNS в Kubernetes ломается пятью способами. Вот чек-лист, чтобы найти нужный за три минуты Если под в k8s не достаёт базу, а Service и Endpoints в порядке, подозревайте DNS. Разбор на Kubenatives описывает путь запроса: приложение читает /etc/resolv.conf и идёт на ClusterIP CoreDNS, обычно 10.96.0.10. Сначала проверьте поды CoreDNS через kubectl get pods с селектором k8s-app=kube-dns. Если они живы, смотрите ndots:5 и поисковые домены в /etc/resolv.conf — именно эта комбинация часто порождает лишние запросы и 5-секундные таймауты. Остальные три причины и команды для каждой — в исходном материале.

Cilium стал дефолтным CNI в EKS: что делать с eBPF В 2026 году eBPF окончательно перешёл из категории «попробовать в лабе» в инфраструктурный стандарт: AWS выбрала Cilium дефолтным CNI для EKS, проект вышел из инкубационной стадии CNCF, а ядро 6.x стабилизировало основные возможности. Cilium на eBPF обгоняет iptables по throughput на 30–40% и умеет L7-политики, пишет автор. Что делать сейчас. На новых кластерах оцените Cilium вместо flannel/calico+iptables. На нодах проверьте ядро — uname -r не ниже 5.8, иначе часть функций недоступна, а CentOS 7/RHEL 7 не поддерживаются. Для безопасности разверните Tetragon: он ловит аномалии на уровне ядра и убивает процесс раньше, чем среагирует userspace.

Когда что-то ломается на проде, инженеры идут спросить совета у того, кто уже сталкивался с этим и знает решение. Из таких обращений постепенно и складывается сообщество. Чтобы этот вклад стал заметным и системным, команда Deckhouse запустила программу признания контрибьюторов Deckhouse User Community, подробные критерии найдёте на GitHub. Контрибуция здесь не только код, но и ответ в чате, разбор логов, кейс, доклад, правка в документацию, проработанное предложение по улучшению. Регулярный вклад даёт статус официального контрибьютора, за который можно получить признание в сообществе, возможность прокачать личный бренд, повлиять на продукт и вполне материальные бенефиты. Начинать с чего-то большого не обязательно. Достаточно сделать что-то полезное и помочь команде это заметить — тогда разрозненная практика и превратится в общую инженерную память. Подробнее о программе можно узнать здесь.

Вышел Podman 6.0. Можно сказать, что это cleanup-релиз — в нём отказались от нескольких устаревших слоёв: cgroups v1, iptables, CNI, slirp4netns и BoltDB. Теперь обязательны cgroups v2, nftables, Netavark, Pasta и SQLite. Заодно закрыли уязвимость CVE-2026-57231 (вредоносный образ мог получать переменные окружения хоста) и включили изоляцию сети по умолчанию. Если вдруг забыли или не сталкивались, расскажу о нём. Podman — open-source утилита для управления OCI-образами, контейнерами и подами. По сути, он очень похож на Docker, прекрасно с ним совместим, но работает без демона и не обязательно от root, при этом дружит с Kubernetes. В общем, стоит взглянуть — инструмент интересный! @devo_pes

Бэкапы есть почти у всех. А вот быстро поднять систему после падения умеют немногие. Данные могут быть целы, но если восстановление инфраструктуры занимает часы, бизнес всё равно простаивает. Копия хранит информацию, а вот вернуть сервис в работу она сама по себе не может, это отдельная задача. В новой статье на Tproger смотрим, как выстроить аварийное восстановление (DRaaS — Disaster Recovery as a Service) заранее, а не собирать его на ходу в момент сбоя. Внутри: чем DRaaS отличается от обычного резервного копирования, что стоит за метриками RTO и RPO (за сколько нужно поднять сервис и какой объём данных допустимо потерять), и как пошагово настроить репликацию VMware — от сетей до переключения и обратного возврата. И главное: у плана восстановления есть срок годности. Если его не прогоняли полгода, в реальной аварии он может повести себя не так, как записано на бумаге. А когда вы в последний раз проверяли свой план восстановления?

Обратный отсчёт пошёл — до митапа остались сутки. Если вы получили подтверждение на Deckhouse User Community meetup/5, то этот пост для вас! Встречаемся в Москве, 8-го июля. Локация в этот раз новая, People Loft по адресу: 1-я улица Энтузиастов, д. 12. Ближайшая станция метро или D3 — «Авиамоторная». Участников ждут с 18:15, доклады начнутся в 19:00. Берите с собой паспорт или водительское удостоверение, они понадобятся для получения бейджа. Увидимся там!

Kubernetes 2026: что стоит внедрить За год немало функций дошло до стабильной версии, и часть привычных подходов пора обновить. Теперь ресурсы пода можно менять на ходу: с версии 1.35 процессор и память настраиваются без перезапуска, что сильно упрощает настройку под нагрузку. Изменился и способ выделения оборудования — под может просто описать, какой GPU нужен, а планировщик сам подберёт подходящий, что особенно удобно для AI-задач. Вспомогательные контейнеры получили понятный жизненный цикл, так что обходные решения для service mesh и агентов Vault больше не нужны. В релизе 1.36 усилили безопасность: root внутри контейнера теперь сопоставляется с обычным пользователем на узле, а правила изменения объектов можно задавать прямо в кластере, без отдельного сервиса. И о чём стоит помнить перед обновлением: Ingress NGINX закрыт с марта 2026 — присмотритесь к Gateway API; поле externalIPs в Service устарело и будет удалено в версии 1.43; на смену Endpoints API приходит EndpointSlices.

Продолжим о Deckhouse Kubernetes Platform (DKP). Недавно в Community Edition стал доступен полный веб-интерфейс! Начиная с версии 1.46 модуля console интерфейс в DKP CE стал полноценным: теперь можно управлять узлами, модулями, доступом, сертификатами, виртуализацией и мониторингом через веб-интерфейс без ограничений. Больше подробностей об этом обновлении читайте на Хабре.

Развернуть Kubernetes-кластер относительно просто. Настоящая жизнь начинается потом: обновления, мониторинг, логи, сеть, безопасность, автоскейлинг. И на всё это довольно быстро уходит время целой команды, а не одного человека. Deckhouse Kubernetes Platform как раз о том, чтобы этой рутины было меньше. Это Kubernetes, который уже собран и упакован вместе с нужными модулями — мониторингом, логами, ingress, сетевыми политиками, веб-интерфейсом и другими функциями. Платформа разворачивается практически где угодно, сама следит за состоянием кластера и обновляет его, а не просто отдаёт вам набор деталей, которые нужно собирать и чинить вручную. У платформы несколько редакций: Community Edition (CE) — бесплатная и полностью открытая, распространяется под лицензией Apache 2.0. В ней достаточно функциональности, чтобы поднять рабочий кластер и разобраться, как устроена платформа. Дальше идут коммерческие редакции с более широким набором функций, поддержкой от вендора и статусом отечественного ПО в реестре, включая Certified Security Edition, сертифицированную ФСТЭК России. Вокруг платформы сложилось инженерное сообщество, которое помогает разобраться с нюансами. Обсуждения на русском идут в чате @deckhouse_ru, а анонсы релизов и материалы для инженеров публикуются в канале @deckhouse_news.

Агенты перешли от Stateless API к сессиям — проверьте их изоляцию AWS, Microsoft, Google и Anthropic строят runtime вокруг session-aware execution. AWS изолирует сессию в microVM, Google — код в dedicated sandbox, Microsoft Foundry использует per-session isolation, Anthropic разделяет агента на session, harness и sandbox. Для DevOps это меняет модель угроз: агент теперь долгоживущий, stateful и выполняет код от имени пользователя. При слабой изоляции одна сессия увидит state другой, утечёт за пределы хоста или скомпрометирует данные. Авторы материала называют такой runtime control plane для состояния, идентичности, изоляции и жизненного цикла. Что делать: проверьте, как сессии ваших агентов отделены друг от друга и от хоста, где лежит state и кто контролирует их жизненный цикл.

Вы бы доверили управление кластером ИИ-агенту? Эдгар Сипки, основатель EasyP && Sipki Tech, однажды не просто кивнул в ответ, а дал агенту возможность настраивать кластер и работать в K8s. Правда, потом агент слегка уронил прод, но это уже нюансы. Своим кейсом Эдгар поделится на DUC meetup /5. Митап состоится 8 июля, в Москве. Регистрируйтесь заранее, мест осталось совсем немного!

Генерируйте SBOM на этапе сборки: сканирование готового образа даст декларацию вместо фактов 86% организаций в отчёте Omdia 2026 называют генерацию SBOM сложной. Причина в том, что разрозненные сканеры дают несогласованный результат, и приходится сводить его вручную. Для DevOps проблема в том, что если SBOM собран после сборки, он фиксирует задекларированные версии, а не фактически установленные. Пропущенные транзитивные зависимости или устаревший слой базового образа превращают аудит на compliance в формальность. Выход — генерация на этапе сборки: генератор видит разрешённое дерево зависимостей, файлы пакетного менеджера и полный контекст сборки. Сканирование готового образа такой видимости не даёт. Для воспроизводимости фиксируйте генератор по неизменяемой ссылке и выбирайте базовые образы с предсобранным SBOM. Детали в обзоре Docker.

От ноутбука до кластера Говорят, у мужчины должны быть «Жигули» «четвёрка» в гараже. У инженера Фланта Василия Олейникова вместо них — домашняя инфраструктура. Как так вышло, что из одного ноутбука Toshiba вырос геораспределённый кластер на несколько квартир, Василий расскажет на юбилейном Deckhouse User Community meetup /5. Митап пройдёт 8 июля в People Loft. Встреча гостей с 18:15, доклады стартуют в 19:05. ➡️ Регистрация

Kubernetes-кластер на несколько квартир, ИИ-агент, который уронил продакшен, и программа для контрибьюторов — всё это на митапе Deckhouse User Community 8 июля в Москве. В программе три доклада: — история домашней геораспределённой инфраструктуры длиной в 13 лет — от ноутбука до кластера, охватывающего несколько квартир; — рассказ об ИИ-агенте, который управляет инфрой (и однажды уронил прод); — питч о веб-интерфейсе Deckhouse Kubernetes Platform. Отдельная тема митапа — участие в жизни сообщества. На встрече объявят о запуске программы поддержки контрибьюторов Deckhouse User Community. Митап пройдёт только офлайн, места ограничены. Регистрация — по ссылке, ждём вас!