Генерируйте SBOM на этапе сборки: сканирование готового образа даст декларацию вместо фактов

86% организаций в отчёте Omdia 2026 называют генерацию SBOM сложной. Причина в том, что разрозненные сканеры дают несогласованный результат, и приходится сводить его вручную.

Для DevOps проблема в том, что если SBOM собран после сборки, он фиксирует задекларированные версии, а не фактически установленные. Пропущенные транзитивные зависимости или устаревший слой базового образа превращают аудит на compliance в формальность.

Выход — генерация на этапе сборки: генератор видит разрешённое дерево зависимостей, файлы пакетного менеджера и полный контекст сборки. Сканирование готового образа такой видимости не даёт. Для воспроизводимости фиксируйте генератор по неизменяемой ссылке и выбирайте базовые образы с предсобранным SBOM. Детали в обзоре Docker.

Агенты перешли от 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 и кто контролирует их жизненный цикл.

Kubernetes 2026: что стоит внедрить

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

Теперь ресурсы пода можно менять на ходу: с версии 1.35 процессор и память настраиваются без перезапуска, что сильно упрощает настройку под нагрузку. Изменился и способ выделения оборудования — под может просто описать, какой GPU нужен, а планировщик сам подберёт подходящий, что особенно удобно для AI-задач. Вспомогательные контейнеры получили понятный жизненный цикл, так что обходные решения для service mesh и агентов Vault больше не нужны.

В релизе 1.36 усилили безопасность: root внутри контейнера теперь сопоставляется с обычным пользователем на узле, а правила изменения объектов можно задавать прямо в кластере, без отдельного сервиса.

И о чём стоит помнить перед обновлением: Ingress NGINX закрыт с марта 2026 — присмотритесь к Gateway API; поле externalIPs в Service устарело и будет удалено в версии 1.43; на смену Endpoints API приходит EndpointSlices.

Бэкапы есть почти у всех. А вот быстро поднять систему после падения умеют немногие. Данные могут быть целы, но если восстановление инфраструктуры занимает часы, бизнес всё равно простаивает. Копия хранит информацию, а вот вернуть сервис в работу она сама по себе не может, это отдельная задача.

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

И главное: у плана восстановления есть срок годности. Если его не прогоняли полгода, в реальной аварии он может повести себя не так, как записано на бумаге. А когда вы в последний раз проверяли свой план восстановления?

Вышел 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 остаётся.