В эфире DevOps FM – срединедельный дайджест новостей и статей!

⏺ 10 августа Docker выпустил обновление Docker VMM, переведя технологию в статус Public Beta.

Docker VMM — новый уровень виртуализации для Docker Desktop, который сделает работу контейнеров на Mac и Windows быстрее и стабильнее. Среди заявленных улучшений — более быстрый запуск контейнеров, ускоренный файловый I/O и более эффективное управление памятью. Сейчас технология доступна в Docker Desktop 4.86, а финальный релиз по имеющейся информации запланирован на конец октября.

Подробнее о том, что изменилось и как попробовать новый VMM — в блоге Docker.

⏺ После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 7.2.

Новая версия ядра традиционно приносит изменения в подсистемах, драйверах и производительности. Подробности о ключевых обновлениях и список основных изменений — читайте в OpenNET.

⏺ Debian обсуждают использование AI при разработке.

Debian объявили о начале общего голосования разработчиков по вопросу использования больших языковых моделей и AI-инструментов при разработке дистрибутива.

Прием голосов будет осуществляться до 28 августа. Как проходит голосование и какие позиции обсуждаются — читайте в OpenNET.

⏺ GitHub пережил масштабный сбой.

17 августа проблемы затронули сразу несколько ключевых сервисов платформы: Web и API показывали около 20% ошибок, а количество неудачных запросов к архивам и Raw-контенту доходило до 50%. Были затронуты Actions, Pull Requests, Issues, Webhooks, Copilot и другие сервисы.

GitHub постепенно восстановил сервисы. В качестве причины сбоев эксперты предположили сетевые инциденты в Amazon Web Services. Подробнее о масштабах сбоя — в статье.

#новостная_подборка #devops #github #docker #linux #debian

Пятничное чтиво от DevOps FM

📚AI-агенты постепенно заходят в DevOps: получают доступ к коду, инфраструктуре, CI/CD и production. Сегодня читаем о том, как безопасно управлять системами, которые умеют действовать самостоятельно.

⏺12 августа Docker представил Agent Baseline — набор практических рекомендаций для безопасного внедрения AI-агентов. В центре внимания — least privilege, наблюдаемость, аудит и возможность остановить агента, а не просто надеяться, что модель будет вести себя правильно. Подробнее читайте в статье.

⏺CNCF смотрит на проблему с другой стороны: если AI становится частью production, то где проходит граница между ML-командой, DevOps и Platform Engineering? И кто в итоге отвечает за надёжность всей этой системы? Подробнее читайте здесь.

⏺В разборе кейса Hugging Face хорошо показывает, почему вопрос контроля уже не теоретический. В ходе инцидента исследователи восстановили около 17 600 действий агента, объединённых примерно в 6 280 цепочек.

⏺GitLab, в свою очередь, показывает, как можно встроить AI-агентов в существующую инфраструктуру с учётом требований безопасности. В новой статье компания рассказывает об AI Gateway для GitLab Dedicated, который позволяет контролировать используемые модели и сохранять AI-обработку внутри выбранного региона. Подробнее читайте в статье.

👀Получается интересный сдвиг: раньше DevOps автоматизировал процессы, а теперь ему предстоит ещё и управлять AI-агентами.

И теперь главный вопрос — какие права мы готовы дать AI и насколько быстро сможем его остановить, если что-то пойдет не так? Пишите свое мнение в комментариях.

Желаем приятного чтения и хороших выходных!

#пятничноечтиво #devops #ai

Новостной дайджест от DevOps FM!

⌨️Делимся свежими новостями и релизами за прошедшую неделю.

⏺Kubeflow получил статус CNCF Graduated.

Kubeflow получил высший статус зрелости в CNCF. Проект объединяет инструменты для построения AI/ML-платформ на Kubernetes — от подготовки данных и обучения моделей до inference.

Для DevOps это ещё один сигнал: Kubernetes всё активнее становится инфраструктурой для AI — от обучения моделей до inference и serving. Детали читайте в статье.

⏺AWS продолжает развивать Argo CD в EKS.

В понедельник мы разбирали сценарий, где Git становится control plane для инфраструктуры и deployment. Теперь AWS расширяет возможности настройки управляемой Argo CD Capability в EKS — в частности, добавляет поддержку кастомных health checks и параметров сравнения ресурсов.

Похоже, AWS постепенно углубляет интеграцию GitOps с EKS, беря на себя всё больше операционных задач по управлению Argo CD. Подробнее — в блоге AWS.

⏺IncidentRelay 2.0 — новый релиз self-hosted incident management.

Open-source проект для управления дежурствами, маршрутизации алертов и incident response получил новый major-релиз.

IncidentRelay ориентирован на SRE и DevOps-команды, которым нужна self-hosted альтернатива облачным платформам управления инцидентами.
Подробности о ключевых обновлениях и список основных изменений — читайте в OpenNET.

⏺GitHub опубликовал разбор масштабного сбоя 17 августа.

Напомним, тогда GitHub был недоступен или работал с ошибками почти 8 часов. Теперь компания раскрыла детали: проблема с autoscaling Istio sidecar-подов привела к перегрузке сети и каскаду отказов.

Ситуацию дополнительно усугубили агрессивные retry: нагрузка на отдельные сервисы выросла многократно.

Получился отличный пример того, как ошибка в автоматическом масштабировании + retry storm могут превратить локальную проблему в большой outage.
Подробнее — в разборе GitHub.

#devops #инциденты #gitlab #kubeflow

А что, если AI посмотрит ваш Kubernetes?

AI-помощники для Kubernetes — уже далеко не новость.

Но становится интереснее, когда AI работает прямо в OpenShift Console и при включённом Cluster Interaction может получать актуальный контекст работающего кластера.

Red Hat в своем блоге показывает 5 сценариев для OpenShift Lightspeed — AI-помощника, который помогает работать с OpenShift и Kubernetes.

Собрали самое интересное 👇

1. Спросить вместо поиска по документации

Например:

How do I configure a custom ingress controller?

What are the prerequisite network requirements for setting up an OpenShift cluster?

Lightspeed использует официальную документацию Red Hat и учитывает версии OpenShift и Lightspeed в вашем окружении.

2. Сгенерировать YAML

Можно попросить AI подготовить конфигурацию:

Generate a YAML file for a deployment running a basic NGINX server with 3 replicas.

Или:

Create a NetworkPolicy that limits traffic to pods in the production namespace.

Получаем черновик манифеста, который дальше, конечно, нужно проверить перед применением.

3. Разобраться с проблемой

Здесь уже можно использовать AI не только для генерации конфигурации, но и для troubleshooting.

Например:

Why is my application pod stuck in ImagePullBackOff?

I am getting a CrashLoopBackOff error on my frontend pod. What is happening there?

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

4. Разобраться с виртуализацией

Для OpenShift Virtualization можно задавать вопросы вроде:

Is there a storage vMotion equivalent?

How do I import a VMware virtual machine into OpenShift Virtualization?

Удобный вариант, чтобы разобраться с Kubernetes-based virtualization и сопоставить её с уже знакомыми подходами.

5. А теперь самое интересное — live-кластер

При включённом Cluster Interaction Lightspeed может получать актуальный контекст активного кластера через OpenShift API.

Например:

Show me all degraded pods running in the payment-processing namespace.

Are there any active security alerts or failed deployments on my cluster right now?

То есть вопрос можно сформулировать не только как: «Как сделать X в OpenShift? Но и как: «Что сейчас происходит с моим кластером?»

Сам сценарий AI-assisted troubleshooting для Kubernetes уже существует. Интерес Lightspeed — в его интеграции с OpenShift и доступе к контексту работающего кластера.

При этом Cluster Interaction сейчас имеет статус Technology Preview, поэтому воспринимать его как готовую замену привычным инструментам мониторинга и диагностики точно не стоит.


👀 А когда такая возможность выйдет из Technology Preview — дали бы вы AI read-only доступ к production-кластеру? Делитесь своим мнением в комментариях 💬

#DevOps #Kubernetes #OpenShift #AI

🎙️ На волне DevOps FM!

Пятница — отличный повод немного отвлечься от рабочих задач и послушать что-нибудь интересное.

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

🗣 DevOps в 2026: Platform Engineering, AI-агенты и будущее джунов от DevOps Kitchen Talks. Что происходит, когда у вас уже 600 сервисов и 3600 пайплайнов? Обсуждают internal platform, её архитектуру и self-service-возможности для разработчиков, а также границы ответственности platform team. Отдельный фокус — AI-агенты и multi-agent workflows: что происходит, когда автоматизация начинает работать уже не только с инфраструктурой, но и непосредственно с engineering-процессами.

🗣 Kubernetes 2035: кто будет управлять инфраструктурой? от «В SREду на кухне» / AvitoTech. GitOps, Crossplane, автоматизация Kubernetes и развитие абстракций над инфраструктурой. Интересный вопрос выпуска — сколько деталей инфраструктуры разработчику действительно нужно видеть и какие операции со временем можно передать платформе и автоматизации.

🗣 Инфраструктура & MLOps от [I'ML]. Здесь уже про инфраструктуру для ML и AI-систем. Обсуждают ML Platform, Data Platform, вывод моделей в production и особенности эксплуатации AI workloads. Хороший выпуск, чтобы посмотреть, какие привычные DevOps-подходы приходится адаптировать для AI.

Желаем приятного прослушивания и дежурств без алертов!🛡

#пятничная_подборка #подкаст #DevOps #PlatformEngineering #AIEngineering

Platform Engineering 2.0: как меняется роль внутренней платформы

Kubernetes, Terraform, GitOps, CI/CD, Backstage — классический стек Platform Engineering уже хорошо знаком.

Но что происходит с этой моделью, когда появляются AI-нагрузки и новые способы взаимодействия с инфраструктурой?

В материале CNCF автор предлагает рассматривать это как следующий этап — Platform Engineering 2.0.

При этом фундамент не меняется: Platform as a Product, удобство для разработчиков, готовые пути, самообслуживание и безопасность на ранних этапах остаются актуальными. Меняется масштаб задач платформы и круг её пользователей.


Что добавляется:

⏺AI становится ещё одним типом нагрузки

Платформе теперь приходится учитывать GPU/TPU, запуск и обслуживание моделей, обработку запросов, жизненный цикл моделей, MCP-шлюзы и специальные механизмы защиты.

То есть AI — это не отдельный слой где-то рядом с платформой. Для platform team это ещё один класс нагрузки со своими требованиями к ресурсам, безопасности и управлению.

⏺Пользователей становится больше

Помимо разработчиков и platform engineers, с платформой работают ML-инженеры, специалисты по данным, команды безопасности и соответствия требованиям, FinOps — и постепенно AI-агенты.

Отсюда практический вопрос: можно ли пользоваться платформой программно?

Интерфейс и Backstage отлично подходят человеку. Но автоматизации и агентам нужны интерфейсы через API: ресурсы, действия, права доступа и ограничения.

⏺FinOps перемещается ближе к созданию ресурсов

Стоимость становится частью решения ещё до развёртывания.

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

⏺Безопасность уходит глубже в платформу

Меньше ручных проверок после развёртывания — больше политик и контроля непосредственно на уровне платформы и среды выполнения.

Для AI добавляются свои риски: неконтролируемое использование AI, prompt injection, отравление моделей, утечки данных при обработке запросов.

⏺Платформа становится модульной

Отдельные возможности должны быть доступны через API и собираться в разные сценарии: интерфейс, CLI, CI/CD, автоматизация или агент.

По сути, архитектура начинает выглядеть так:

Developer / ML Engineer / Agent
↓
Platform APIs
↓
Identity / Policy / Cost
↓
Kubernetes / Cloud / GPU / AI

И здесь важно: Kubernetes, Terraform, GitOps, Backstage никуда не исчезают. Меняется слой над ними — платформа начинает решать задачи, которые раньше находились за пределами классического самообслуживания разработчиков.


В итоге из концепции Platform Engineering 2.0 можно сделать вполне практичную вещь — ревизию собственной платформы.

Спросить себя:

→ Можем ли мы быстро выдать специализированный ресурс?

→ Можем ли мы сделать это через API?

→ Знаем ли стоимость до развёртывания?

→ Можем ли мы применять политики на уровне платформы?

→ Может ли автоматизация или агент работать с платформой без человека?

Если где-то ответ «нет» — вот там и находится следующая задача для platform team⌨️

#DevOps #Platformengineering

Как LegalOn адаптирует Platform Engineering под AI-агентов ⌨️

Продолжаем тему Platform Engineering — сегодня разбираем кейс LegalOn Technologies от Signadot. LegalOn Technologies от Signadot.

У LegalOn около 200 инженеров, GKE, Argo CD и собственная платформа Akupara. С появлением AI-агентов узким местом всё чаще становится уже не создание кода, а его проверка и доставка.

Архитектуру они разделили на три части:

⏺Контекст

Каталог продуктов в YAML используется как источник данных для Terraform и агентов. На основе Terraform HCL и Kubernetes-конфигураций они строят граф знаний, доступный через MCP.

По данным LegalOn, это снизило потребление токенов примерно на 25%.

⏺Соединение с реальным окружением

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

Так появляется быстрый цикл, без необходимости каждый раз проходить полный путь через CI/CD: зменение → проверка → результат → исправление

⏺Изолированная среда

Для PR LegalOn использует Signadot: изменённые сервисы запускаются в отдельном окружении, которое можно использовать для тестов и проверки взаимодействия компонентов.

Но здесь меняется сама роль платформы.

Если раньше Platform Engineering строился вокруг разработчика: разработчик → платформа → инфраструктура

то теперь появляется второй потребитель: разработчик / агент → платформа → инфраструктура

Агенту нужны не только API и инструменты, но и контекст, быстрый цикл проверки и чёткие границы действий.

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

#DevOps #PlatformEngineering #LegalOn

Redis Streams vs Kafka

📝 Что выбрать для системы обработки событий: Redis Streams или Kafka?

Сегодня заглянем в Reddit-тред, где инженеры поделились своим опытом использования этих инструментов в реальных продакшен-системах.

suhaanthvv

Для системы уведомлений я выбрал Redis Streams + Consumer Groups вместо Kafka/SQS. Нам нужны retry, replay, восстановление после падения consumer'а и DLQ. Пока Redis закрывает эти задачи, но главный вопрос — в какой момент его возможностей становится недостаточно и стоит переходить на Kafka?

dragon_idli

Мы используем Kafka примерно для
30 млн событий, при этом кластер рассчитан на 70 млн. Redis у нас работает отдельно для ultra-low-latency сценариев. Например, игровые события внутри комнат — там важна минимальная задержка.

gvensan

Я бы использовал Redis, пока не появляются multi-site, независимые команды и необходимость в длинном replay. Вот тогда Kafka начинает выглядеть более оправданно.

7z3b

Мы сначала использовали Redis, но потом ушли на NATS JetStream. Stream'ы росли, потребление памяти увеличивалось, и Redis становился слишком дорогим. Kafka тоже не выбрали — managed-вариант был дорогим, а самостоятельно поддерживать Kafka не хотелось.

💬 Отдельно в обсуждении подняли вопрос replay:

srikanth_builds

Если сообщение повторно доставляется спустя время, ситуация могла измениться: например, пользователь уже не имеет доступа к данным. Поэтому authorization нужно проверять в момент доставки, а не только при постановке события в очередь.

Полный тред можно почитать здесь.

А какой production-кейс заставил бы вас отказаться от Redis Streams в пользу Kafka? Делитесь опытом в комментариях💬

#devops #reddit #redis #kafka

Почему Kubernetes API server может съесть память на обычном LIST 👀

Получить список объектов через Kubernetes API кажется безобидной операцией. Но в большом кластере один такой запрос может вернуть тысячи объектов и заметно увеличить пиковое потребление памяти.

Где возникает проблема?

API server разбивает большие ответы на страницы, но размер страницы ограничен количеством объектов, а не объёмом данных. Поэтому несколько крупных объектов вполне могут превратить одну страницу в большой объём памяти.

При чтении из etcd такая страница сначала собирается целиком, а затем передаётся API server для обработки:

etcd → API server → декодирование → клиент

В результате один и тот же объём данных на короткое время находится в памяти сразу с двух сторон. Если несколько больших запросов выполняются одновременно, API server может упереться в лимит памяти.

Что меняет RangeStream?

В Kubernetes 1.37 etcd RangeStream получил статус Beta. Вместо целой страницы данные передаются небольшими частями: API server обрабатывает их по мере поступления и освобождает память перед следующей частью.

Большой запрос всё равно остаётся большой операцией, но теперь его размер меньше влияет на пиковое потребление памяти.

Что это даёт на практике?

Особенно полезно помнить об этом при расследовании ситуаций, когда API server внезапно начинает потреблять много памяти. Если память растёт рывками, а явного изменения нагрузки нет, причиной может быть не количество запросов, а размер возвращаемых данных.

Например, оператор регулярно получает список крупного пользовательского ресурса, а несколько таких запросов одновременно создают высокий пик памяти.

В таком случае стоит посмотреть, кто выполняет большие запросы, сколько объектов возвращается и насколько велики сами объекты.

Использование RangeStream можно проверить по метрике:

etcd_request_duration_seconds_count{operation="listStream"}

🌐 Подробно о проблеме и механике RangeStream — в разборе Kubernetes.

#kubernetes #devops #et