Мульти-кластерная 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

Кластер лёг целиком, а его копия в соседнем регионе трафик не подхватила

Знакомый момент любой мультирегиональной установки: идентичная копия сервиса живёт двумя регионами дальше, но ничто не связывает их в одну сущность. Фейловер превращается в ранбук: восстановить, перенаправить DNS и ждать простоя, за отсутствие которого вы вроде бы уже заплатили.

Мультикластерное расширение Linkerd закрывает разрыв: несколько кластеров отдают сервис как единый балансируемый эндпоинт. В официальных инструкциях пропущено главное: реальная платформа почти никогда не выбирает один режим. Федерация, зеркалирование и gateway живут на одном наборе связей, а режим задаётся для каждого сервиса лейблом.

Разбор собирает все три режима на трёх кластерах GKE, с полносвязной топологией связей и хаос-тестом, который выносит кластер целиком. Скрипты лежат в отдельном репозитории.

Четыре паттерна Docker Compose, каждый ценой вечера отладки

Полдюжины сервисов на одном VPS: база, шлюз API, пара воркеров, Redis. Compose тут очевидный выбор, вот только первые конфиги обычно собираются методом тыка.

Показателен первый паттерн, про хелсчеки. Слишком агрессивный вариант с interval: 5s и start_period: 5s перезапускает контейнер раньше, чем тот успевает подняться, и вместо диагностики вы получаете бесконечный цикл рестартов.

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

Образ с Go-сервисом влезает в 15 МБ, если не собирать его на scratch

Go компилируется в один статически слинкованный бинарник без рантайма и системных зависимостей, поэтому образ это ваш бинарник плюс пара килобайт метаданных. Там, где Node с трудом влезает в 150 МБ, Go садится ниже 15 МБ без всяких усилий.

Ключевые флаги: CGO_ENABLED=0 даёт по-настоящему статический бинарник с чистой Go-реализацией сети и DNS, -ldflags="-s -w" убирает отладочные символы и режет примерно 30% размера, а копирование go.mod и go.sum до исходников оставляет слой зависимостей в кеше между сборками.

Вывод про базовый образ неочевидный. FROM scratch работает ровно до того момента, когда понадобятся HTTPS и часовые пояса: там нет ни CA-сертификатов, ни tzdata. Distroless static везёт и то и другое плюс пользователя nonroot примерно в 2 МБ. Разбор с Dockerfile.

Когда Helm-чарта уже мало: пишем свой Kubernetes Operator

В Kubernetes есть контроллеры для встроенных ресурсов: деплойментов, сервисов, нод. Оператор растягивает тот же паттерн на ресурсы, о которых кластер ничего не знает, и позволяет управлять кастомными и внешними системами так же декларативно, как всем остальным.

Первый вопрос, на который стоит ответить до кода: чем оператор отличается от контроллера и CRD и почему в вашем случае не хватит чарта, CronJob или скрипта. Руководство начинается ровно с него, а не с генерации проекта.

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

Дежурный инженер не должен работать движком корреляции

В Atlassian сотни связанных микросервисов в нескольких регионах, и любой инцидент рождает столько телеметрии, что причину по-прежнему находят вручную.

Типичный путь выглядит так. Дежурного разбудил алерт, он открыл дашборд метрик, увидел аномалию в ошибках или задержках, ушёл в логи искать исключения в том же временном окне, потом в трейсы смотреть отдельные запросы. Дальше он глазами сводит три разных представления, строит гипотезу и идёт назад по графу зависимостей проверять её.

Процесс последовательный и дорогой по вниманию: он держится на том, что человек заранее знает, какие дашборды открывать и какие сервисы стоят выше по потоку. Сеньор делает это за минуты, остальные заметно дольше, а на пользовательском инциденте важна каждая. Чем это заменили в Atlassian, показано в их разборе.

Хроника вторжения: как ИИ-агент четверо суток ходил по инфраструктуре

Hugging Face выложила технический разбор июльского инцидента 2026 года: два вектора первичного доступа, как агент закрепился и двигался вбок, и примеры команд, которые реально выполнялись. Живые учётные данные и внутренние имена хостов вымараны, техники описаны как наблюдались.

Отдельная деталь: расследование вели с помощью GLM 5.2, модели с открытыми весами. В посте есть интерактивный проигрыш кампании длиной 4,5 суток по шагам: цепочка через границы доверия, активность по фазам и записанные команды.

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

Поставил CDN-кеш перед статикой, и сайт стал медленнее

Не тонко медленнее: независимый краулер до изменения отмечал 38 медленных страниц, после — 75. Автор откатил всё в тот же день.

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

Прогоните эту формулу, прежде чем ставить CDN перед малопосещаемым разделом. Разбор с цифрами до и после.

Проверка подписи образа на уровне рантайма, а не admission-вебхука

Kyverno, OPA Gatekeeper и Sigstore Policy Controller работают на слое API Kubernetes: перехватывают создание пода, проверяют подписи и аттестации, пропускают или отклоняют.

Проблема в том, на чём это держится. Вебхуки зависят от явной конфигурации и от сети: криво заданный селектор неймспейсов молча пропускает проверку, отказ вебхука ставит перед выбором между блокировкой кластера и тихим байпасом, а статические поды и прямой доступ к API kubelet обходят admission целиком.

Supply Chain NRI Plugin спускает проверку на слой ниже, в сам рантайм контейнеров, через который проходит любой контейнер независимо от способа запуска. Работает и с CRI-O, и с containerd, выпускается отдельным циклом. Порядок подключения описан в статье CNCF.

DRA дошёл до GA, но HAMi он не отменяет

Раньше словарь для GPU в Kubernetes состоял из одной строчки nvidia.com/gpu: 1: целая карта, берите или отказывайтесь. HAMi, которого TOC принял в инкубацию CNCF 15 июля 2026 года, целиком построен вокруг обхода этого ограничения: мутирующий вебхук, расширитель планировщика, аннотации и принуждение лимитов внутри контейнера.

Теперь словарь изменился. Dynamic Resource Allocation дошёл до GA в Kubernetes 1.34 и включён по умолчанию с 1.35, а вместе с consumable capacity под может нативно попросить у планировщика долю памяти устройства, без всяких аннотаций.

Отсюда и вопрос, который задают в чатах HAMi. Короткий ответ: нет, не отменяет. Кодирование дробных запросов DRA действительно забирает себе, а вот принуждать лимиты внутри контейнера на уровне вызовов CUDA он не проектировался. Что оставить HAMi, а что отдать DRA, разобрано в материале.

Kubernetes 1.37 выкидывает kube-dns, IPVS и cgroup v1: проверьте три вещи до апгрейда

Релиз назвали Garhwal, в нём 67 изменений: 16 фич доведены до стабильных, 23 в бете, 27 новых альфа и одно удаление. Команда явно расставляет приоритеты в сторону готовности к продакшену, а не новизны.

Проверить до обновления надо три вещи: не остался ли kube-dns вместо CoreDNS, не работает ли kube-proxy в режиме IPVS и не сидят ли ноды на cgroup v1. Всё три уезжают, и молча это не пройдёт.

Для контекста: по январскому опросу CNCF Kubernetes крутят в проде около 82% тех, кто вообще пользуется контейнерами, против 66% в 2023 году, а 66% организаций, которые хостят генеративные модели, гоняют через него инференс. Разбор релиза.