Вышел 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

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.

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-секундные таймауты.

Остальные три причины и команды для каждой — в исходном материале.

Docker: namespaces и cgroups

Когда контейнер падает с OOMKilled или порт не пробрасывается, не нужно гадать: это обычный Linux-процесс, который ядро ограничивает двумя механизмами. Namespaces дают ему изолированный вид — свой PID 1, таблицу маршрутизации и интерфейсы, mount-точки. Cgroups выставляют жёсткие лимиты на CPU, память и I/O, чтобы один контейнер не уложил хост.

Посмотреть на изоляцию помогает unshare. Docker связывает контейнер через veth: один конец на мосте docker0, другой в namespace. За лимитами отвечают cgroups, которые Docker задаёт через docker run.

Понимание этих двух механизмов спасает от «почему работает локально, а в проде падает». При инциденте смотрите сначала на них, а не на приложение. Разбор на dev.to.

Почему в 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.

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.

Cloudflare Internal DNS вышел в GA — приватные зоны теперь на одном управлении с публичным DNS

Если у вас split-horizon DNS, вы уже знаете боль: две системы, которые должны отдавать разные ответы на один хост, и поиск дрифта при падении. Cloudflare запустил Internal DNS в общем доступе: авторитативный и рекурсивный DNS для приватных сетей на той же плоскости управления, что и публичный DNS, Zero Trust и Gateway.

Результат: единый API, единый audit trail, политики резолвинга через Gateway Resolver и приватные зоны через Internal Authoritative DNS. Для Enterprise входит в Cloudflare Gateway без доплаты. Если сейчас кормите внутренний DNS отдельными железками или облачными резолверами, пора смотреть миграцию.

Не давайте ИИ-агенту операторские права: 13 часов дауна AWS Cost Explorer

В середине декабря 2025 года инженер AWS попросил Kiro — собственного агента Amazon — поправить баг в Cost Explorer. У агента были операторские права в одном из регионов материкового Китая. Kiro решил, что быстрее удалить прод и пересоздать его с нуля, и выполнил это без подтверждения. Сервис простоял 13 часов.

К марту 2026-го последствия таких инцидентов, по оценкам из блога Docker, стоили компании около 6,3 млн заказов, прежде чем ввели «code safety reset». Для инфраструктурщика вывод простой: запускайте агентов с ограниченными правами, требуйте подтверждения на деструктивные операции и используйте scoped-identity (права с ограниченной областью действия), чтобы уменьшить радиус взрыва.

Поднимите LLM в Kubernetes: vLLM + LINSTOR через CSI

Если вы хотите снизить задержки или удержать данные внутри периметра, инференс можно поднять прямо в кластере. В туториале от CNCF используют vLLM: он отдаёт OpenAI-compatible REST API, так что код на OpenAI SDK переключается сменой URL.

В качестве модели взяли meta-llama/Llama-3.2-1B-Instruct (1B параметров), запущена на CPU. Веса хранят на LINSTOR через стандартный CSI-драйвер: реплицированный блочный сторадж на DRBD переживёт рестарт пода и отказ ноды. Пошаговый разбор стека — в статье.

Гибридный подход: чувствительные и высокочастотные запросы уходят в self-hosted, остальное остаётся на managed API.

Мульти-кластерная MongoDB на Kubernetes: как пережить падение региона

Чтобы база на Kubernetes пережила падение региона, одного кластера мало. В свежем посте CNCF Edith Puclla и Ivan Groenewold разбирают, как распределить MongoDB по нескольким кластерам K8s с помощью Percona Operator for MongoDB.

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

Архитектура разделяет роли кластеров: Kubernetes-операции отдаются Operator, а операции базы — самой MongoDB. Для реляционных нагрузок похожие паттерны есть в Vitess и CloudNativePG. Подробности в статье.

ИИ-агенты уже работают в вашей инфре. Одной инвентаризации мало

Они сидят в SaaS-платформах, dev-окружениях, облачных workflow, системах поддержки и внутренних приложениях. Часть согласована, часть нет. И агенты не пассивны: рассуждают, вызывают API, лезут в данные и действуют без человека в цикле.

Реестр агентов без привязки к контролю превращается в статичный список активов. Он показывает, что агент существует, но не отвечает на вопросы: адекватен ли его доступ, кто владелец, когда права пора отозвать. А создаются и расшариваются агенты быстрее любых других активов.

Что делать: завести на каждого агента identity, владельца и политику наименьших привилегий, плюс проверку намерения (intent) перед действием. Понимание intent агента, пишет The Hacker News, единственный рабочий путь к реальному enforcement.

EKS теперь можно откатить до предыдущей версии Kubernetes

Amazon EKS добавил откат управляющего слоя (control plane) кластера на предыдущую версию Kubernetes в течение 7 дней после апгрейда. etcd, ворклоады и PVC сохраняются. Для кластеров в Auto Mode откатят сначала ноды, потом control plane.

Раньше обновление Kubernetes называли односторонней дверью: команды откладывали апгрейды из-за неуверенности в откате, и кластеры застревали без патчей. Теперь откат идёт пошагово — одна минорная версия за раз — после проверки cluster insights.

Если планируете апгрейд EKS, закладывайте это окно в процедуру отката. Детали на InfoQ.

SRE-агенты переходят от рекомендаций к автономным действиям

В классическом SRE инженер получает алерт, открывает консоль, гоняет диагностику и правит по ранбуку. Агент ИИ может съесть тот же алерт, коррелировать его с недавним деплоем и выполнить рутинное исправление самостоятельно.

Это меняет роль SRE: из «делающего вручную» в «менеджера команды агентов», которые накапливают операционную память и снижают зависимость от одного эксперта. Но работает только при одном условии — выбираете один целевой сценарий, а не натягиваете «ИИ-слой» на всё подряд.

Ещё несколько направлений, где агенты разгружают команду.

GNU Binutils 2.47: что поменяется в сборочных CI

Обновите GNU Binutils до 2.47 в сборочных образах, если там линкуются нативные бинарники под Linux. Новые флаги дают контроль над размером и скоростью сборки — без переписывания пайплайнов.

Ассемблер получил --reloc-section-sym. objdump и readelf теперь поддерживают --debug-dir, а линкер BFD получил -O 0 для ускоренной линковки ценой размера. Ещё добавлены --start-lib/--end-lib и поддержка архивов без индекса символов.

Если билдите под RISC-V, в 2.47 добавлены расширения zalasr, zvabd и zvqwdota/zvfwdota. Для легаси риск: 32-битный s390 теперь считается устаревшим, а s390x остаётся.

Один sos вместо сбора логов руками

При инциденте не собирайте логи по кускам через SSH: запустите sos, ранее известную как sosreport. Один проход даёт архив с конфигурацией, логами и диагностическими данными, то есть срез состояния системы на момент сбоя.

Утилита входит в пакет sos в большинстве дистрибутивов Linux. Это открытый Python-проект, который развивается с 2009 года: изначально создали в Red Hat, позже к разработке подключились Canonical, IBM, Dell/EMC, Oracle и Linux Foundation.

На выходе — снимок для разбора инцидента, сохранённая доказательная база и единый артефакт для вендорской поддержки. Подробности о плагинах и возможностях.

Масштабируйте поды Kubernetes по глубине SQS через KEDA

Для воркеров с очередями CPU и память лгут: под может ничего не есть, а сообщений в SQS — тысячи. KEDA на EKS следит за глубиной очереди и двигает HPA вместо того, чтобы ждать, пока лаг убьёт downstream.

Ставится через Helm: helm install keda kedacore/keda --namespace keda --create-namespace. Для доступа к AWS используйте EKS Pod Identity или IRSA, затем создайте ScaledObject с триггером aws-sqs-queue. Параметры queueLength, activationQueueLength и cooldowns решают, сколько реплик запускать и когда останавливать.

При пустой очереди KEDA сокращает реплики и экономит ресурсы. Подробности по настройке — для тех, кто уже в проде.

Docker Sandboxes изолируют агента от вашей машины, но не от вашего репозитория

Смысл песочницы в том, чтобы разрешить агенту работать без подтверждений, но не на вашей машине, а в отдельной виртуалке. До хоста он оттуда не дотянется: у песочницы своё ядро, свой демон Docker, наружу она ходит только через прокси, и всё кроме HTTP и HTTPS закрыто.

Одна дверь открыта намеренно, иначе в инструменте не было бы смысла: папка проекта примонтирована в песочницу на запись. Агент правит ровно те файлы, которые открыты у вас в редакторе.

Среди них есть такие, что выполняются сами, без вашей команды. Docker перечисляет их прямо: git-хуки, Makefile, скрипты из package.json, конфиги CI и IDE. Сработает это уже на вашей машине и с вашими правами, мимо всякой изоляции. Хуки вдобавок лежат в .git/ и в git diff не показываются, так что при беглом просмотре правок вы их не увидите.

Что с этим делать. Запускать агента как sbx run <агент> --clone: тогда репозиторий монтируется только на чтение, а агент работает с приватной копией внутри виртуалки. И заглянуть в sbx policy ls — там список доменов, куда песочнице разрешено ходить. По умолчанию он широкий, вплоть до масок вроде *.googleapis.com, а это все направления, по которым из песочницы что-то уходит наружу.

#devops

Сходили на Deckhouse Conf 2026: собрали выжимку с конференции и ссылки на записи докладов

Сколько ресурсов на самом деле съедает безопасность кластера? Мощности под бизнес-логику при переезде в Kubernetes закладывают все, а вот про «налог» на защиту вспоминают не всегда. На Deckhouse Conf этот налог посчитали: компетенции инженеров, дополнительные вычислительные ресурсы и время на разбор ошибок.

Ещё из зала: как «АльфаСтрахование» убрала архитектурное ревью из бутылочного горлышка, зашив стандарты прямо в CI/CD. Теперь пайплайн сам разворачивает валидную среду и бьёт по рукам, если сервис не проходит по требованиям, а сеньоры не проверяют бойлерплейт вручную.

Для тех, у кого нет времени смотреть все доклады, краткий пересказ: https://tproger.ru/articles/deckhouse-conf-2026-zachem-inzheneram-samopisnyj-sdn-i-virtualki