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

Docker Sandboxes изолируют агента от вашей машины, но не от вашего репозитория Смысл песочницы в том, чтобы разрешить агенту работать без подтверждений, но не на вашей машине, а в отдельной виртуалке. До хоста он оттуда не дотянется: у песочницы своё ядро, свой демон Docker, наружу она ходит только через прокси, и всё кроме HTTP и HTTPS закрыто. Одна дверь открыта намеренно, иначе в инструменте не было бы смысла: папка проекта примонтирована в песочницу на запись. Агент правит ровно те файлы, которые открыты у вас в редакторе. Среди них есть такие, что выполняются сами, без вашей команды. Docker перечисляет их прямо: git-хуки, Makefile, скрипты из package.json, конфиги CI и IDE. Сработает это уже на вашей машине и с вашими правами, мимо всякой изоляции. Хуки вдобавок лежат в .git/ и в git diff не показываются, так что при беглом просмотре правок вы их не увидите. Что с этим делать. Запускать агента как sbx run <агент> --clone: тогда репозиторий монтируется только на чтение, а агент работает с приватной копией внутри виртуалки. И заглянуть в sbx policy ls — там список доменов, куда песочнице разрешено ходить. По умолчанию он широкий, вплоть до масок вроде *.googleapis.com, а это все направления, по которым из песочницы что-то уходит наружу. #devops

Масштабируйте поды 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 сокращает реплики и экономит ресурсы. Подробности по настройке — для тех, кто уже в проде.

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

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 остаётся.

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

EKS теперь можно откатить до предыдущей версии Kubernetes Amazon EKS добавил откат управляющего слоя (control plane) кластера на предыдущую версию Kubernetes в течение 7 дней после апгрейда. etcd, ворклоады и PVC сохраняются. Для кластеров в Auto Mode откатят сначала ноды, потом control plane. Раньше обновление Kubernetes называли односторонней дверью: команды откладывали апгрейды из-за неуверенности в откате, и кластеры застревали без патчей. Теперь откат идёт пошагово — одна минорная версия за раз — после проверки cluster insights. Если планируете апгрейд EKS, закладывайте это окно в процедуру отката. Детали на InfoQ.

ИИ-агенты уже работают в вашей инфре. Одной инвентаризации мало Они сидят в SaaS-платформах, dev-окружениях, облачных workflow, системах поддержки и внутренних приложениях. Часть согласована, часть нет. И агенты не пассивны: рассуждают, вызывают API, лезут в данные и действуют без человека в цикле. Реестр агентов без привязки к контролю превращается в статичный список активов. Он показывает, что агент существует, но не отвечает на вопросы: адекватен ли его доступ, кто владелец, когда права пора отозвать. А создаются и расшариваются агенты быстрее любых других активов. Что делать: завести на каждого агента identity, владельца и политику наименьших привилегий, плюс проверку намерения (intent) перед действием. Понимание intent агента, пишет The Hacker News, единственный рабочий путь к реальному enforcement.

Всем привет! Месяц Фланта в канале подошёл к концу, канал продолжит работать в обычном режиме ⚡️ Для тех, кто пропустил: 1. Deckhouse Kubernetes Platform; 2. Программа признания контрибьюторов Deckhouse User Community; 3. Записи с DeckhouseConf 2026; 4. Курс по Kubernetes от Фланта; 5. Вакансии Фланта.

Channel photo updated

Мульти-кластерная MongoDB на Kubernetes: как пережить падение региона Чтобы база на Kubernetes пережила падение региона, одного кластера мало. В свежем посте CNCF Edith Puclla и Ivan Groenewold разбирают, как распределить MongoDB по нескольким кластерам K8s с помощью Percona Operator for MongoDB. Три сценария, зачем это нужно: аварийное восстановление, когда второй кластер уже хранит копию и может выбрать новый Primary; живая миграция между площадками без остановки базы; обслуживание одного кластера, пока второй продолжает принимать записи. Архитектура разделяет роли кластеров: Kubernetes-операции отдаются Operator, а операции базы — самой MongoDB. Для реляционных нагрузок похожие паттерны есть в Vitess и CloudNativePG. Подробности в статье.

Поднимите 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.

Не давайте ИИ-агенту операторские права: 13 часов дауна AWS Cost Explorer В середине декабря 2025 года инженер AWS попросил Kiro — собственного агента Amazon — поправить баг в Cost Explorer. У агента были операторские права в одном из регионов материкового Китая. Kiro решил, что быстрее удалить прод и пересоздать его с нуля, и выполнил это без подтверждения. Сервис простоял 13 часов. К марту 2026-го последствия таких инцидентов, по оценкам из блога Docker, стоили компании около 6,3 млн заказов, прежде чем ввели «code safety reset». Для инфраструктурщика вывод простой: запускайте агентов с ограниченными правами, требуйте подтверждения на деструктивные операции и используйте scoped-identity (права с ограниченной областью действия), чтобы уменьшить радиус взрыва.

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 отдельными железками или облачными резолверами, пора смотреть миграцию.

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.

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

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.

Вышел 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 — от сетей до переключения и обратного возврата. И главное: у плана восстановления есть срок годности. Если его не прогоняли полгода, в реальной аварии он может повести себя не так, как записано на бумаге. А когда вы в последний раз проверяли свой план восстановления?