Как 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

Как дать командам доступ к метрикам Kubernetes и не открыть весь Prometheus?

Всем DevOps!🖖 В прошлом посте мы разбирали, как LegalOn перестраивает платформу для AI-агентов: даёт им нужный контекст и доступ к окружению, но оставляет чёткие границы действий.

В свежем материале CNCF инженеры Adobe разбирают похожую задачу для наблюдаемости: как дать командам самостоятельный доступ к метрикам, не открывая весь общий Prometheus.

В многопользовательском Kubernetes командам нужны собственные запросы и оповещения, но общий Prometheus нельзя открыть всем: его API не изолирует запросы по пространствам имён, а множество произвольных запросов создаёт на него нагрузку.

В Adobe решили проблему через промежуточный слой:
команда → проверка прав → ограничение области данных → Prometheus

Этот слой ограничивает запросы данными своего пространства имён. А нужные метрики при необходимости можно дополнительно отправлять в отдельный Prometheus команды — для графиков и оповещений.

Получается тот же принцип, что и в кейсе LegalOn: самообслуживание без прямого доступа ко всей инфраструктуре.

В кейсе Adobe это помогло найти GPU, который 11 дней был выделен, включен, но не использовался.

Как у вас устроен доступ команд к метрикам: общий Prometheus с изоляцией или отдельный для каждой команды? Делитесь опытом в комментариях💬

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

⏺В Forgejo обнаружили критическую уязвимость с RCE и CVSS 9.9.

CVE-2026-89094 позволяет выполнить произвольный код при обработке специально подготовленного шаблонного репозитория. Проблема затрагивает версии Forgejo до 16.0.4.

Если Forgejo используется во внутренней Git-инфраструктуре, стоит проверить версию и обновиться.

Подробнее в статье OpenNET.

⏺Вышел Cilium 1.20 с новыми возможностями для сетей Kubernetes.

Обновили Gateway API до версии 1.6, добавили ExternalAuth, TCPRoute и UDPRoute, а также поддержку IPv6 в AWS ENI IPAM.

Появилась возможность перейти от общего пула IP-адресов к нескольким пулам без пересоздания кластера и смены IP-адресов.

Больше об изменениях читайте в блоге CNCF.

⏺Исследователи показали способ подмены идентичности рабочей нагрузки в SPIFFE/SPIRE.

Получив root на узле, атакующий может подменить данные cgroup, которые агент SPIRE использует для определения рабочей нагрузки, и получить криптографический идентификатор другой нагрузки.

Способ атаки пока не наблюдали в реальных атаках, но он показывает проблему модели доверия при компрометации узла.

Подробнее — в исследовании Unit 42.

⏺AWS не смог восстановить часть инфраструктуры после масштабного повреждения.

Масштаб повреждений оказался больше расчётного сценария отказа, поэтому часть ресурсов в Бахрейне и ОАЭ восстановить не удалось.

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

Детали читайте в Reuters.

#новостной_дайджест #devopsfm #kubernetes #security #cilium #aws

👩‍💻 Что нового в Kubernetes 1.37?

Бодрый DevOps! В эту пятницу разбираем свежие материалы команды Kubernetes о v1.37 Garhwal. Выбрали несколько изменений, о которых стоит почитать перед обновлением кластера.

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

Разбор масштабирования до нуля.

⏺Больше контроля над памятью.
Memory QoS перешёл в Beta. Kubernetes получает более точный контроль за потреблением памяти контейнерами.

Как работает новый механизм.

⏺Kubernetes без root.
Компоненты ноды теперь можно запускать от непривилегированного пользователя. Ещё один шаг к уменьшению привилегий в кластере.

Разбор rootless-режима.

⏺GPU и другие специализированные ресурсы.
DRA получил новые возможности для более гибкого распределения ресурсов — особенно актуально для кластеров с GPU.

Подробнее о DRA.

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

А если хочется погрузиться глубже — держите полный обзор изменений Kubernetes 1.37.

Желаем всем хороших выходных и спокойных дежурств!🛡

#девопс #kubernetes #пятничное_чтиво

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

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

⏺В KVM нашли уязвимость, позволяющую гостевой системе получить доступ к памяти хоста.

CVE-2026-89775 затрагивает ARM64-системы с включённой вложенной виртуализацией. При определённых условиях гостевая система может читать и записывать память ядра хоста.

Проблема появилась в Linux 6.16 и исправлена в версиях 6.18.51 и 7.2.5. Для дистрибутивов стоит проверить доступность исправлений.

Подробнее — в материале OpenNET.

⏺GitHub усилил защиту GitHub Actions.

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

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

Читайте подробности в блоге GitHub.

⏺GitHub переводит ubuntu-latest на Ubuntu 26.04.

С 19 октября по 19 ноября GitHub начнёт поэтапно переводить ubuntu-latest с Ubuntu 24.04 на 26.04.

Для CI это означает изменение окружения без изменений в самих workflow: обновятся версии системных пакетов и предустановленных инструментов.

Если используется ubuntu-latest, GitHub рекомендует заранее проверить сборки на Ubuntu 26.04 или зафиксировать ubuntu-24.04.

Детали узнавайте в статье на GitHub.

⏺В Kubernetes 1.37 добавили отслеживание неиспользуемых PVC.

PersistentVolumeClaimUnusedSinceTime перешла в статус Beta и включена по умолчанию.

Теперь Kubernetes может помечать PVC как Unused, если его не использует ни один работающий Pod, и фиксировать время перехода в это состояние.

Это позволит находить давно неиспользуемые PVC и использовать эту информацию для последующей очистки.

Подробности — в блоге Kubernetes.

#новостной_дайджест #devopsfm #kubernetes #github #linux

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

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

⏺В Amazon EKS показали, как Pod могут потерять равномерное распределение по зонам доступности.

После потери части узлов 1000 Pod перестали равномерно распределяться между тремя зонами. Даже после восстановления ёмкости перекос сохранялся более 16 часов.

topologySpreadConstraints не перераспределяют уже запущенные Pod. Для исправления AWS предлагает Kubernetes Descheduler.

Подробнее — в блоге AWS.

⏺Исследователи нашли побочный канал через inotify.

Анализ событий файловой системы позволяет отслеживать действия других пользователей без доступа к содержимому файлов. Исследователи показали возможность отслеживать SSH-сессии и восстанавливать ввод с клавиатуры.

Для атаки достаточно доступа к событиям файловой системы.

Подробности читайте в статье OpenNET.

⏺В LXD и Incus обнаружили критические уязвимости с получением root.

Несколько уязвимостей позволяют непривилегированному пользователю работать с произвольными файлами и выполнять код с правами root. Проблемы связаны с миграцией, резервным копированием и загрузкой образов.

Уязвимости исправлены — стоит проверить версии LXD и Incus.

Детали в статье OpenNET.

⏺Google выпустил инструмент для миграции Kubernetes из EKS в GKE с помощью ИИ.

GKE Agentic Migration анализирует Terraform и Kubernetes-манифесты, переводит настройки AWS в конфигурацию GKE и формирует Pull Request.

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

Подробнее — в блоге Google Cloud.

⏺Ubuntu ускоряет выпуск исправлений ядра.

Canonical переходит на двухнедельный цикл доставки обновлений ядра Linux. Подготовка нового обновления будет запускаться каждую неделю.

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

Читайте больше в статье OpenNET.

#новостной_дайджест #devopsfm #linux #aws #gke #devops

Как retry может усугубить инцидент

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

Это хороший повод посмотреть на retry не только как на защиту от временных ошибок, но и как на источник дополнительной нагрузки. Особенно в распределённых системах, где один запрос может повторяться сразу на нескольких уровнях.

Представим цепочку:

A → B → C → D

D начинает отвечать ошибками.
C делает retry.
B получает ошибку от C и тоже делает retry.
A повторяет запрос к B.

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

Особенно опасно, когда retry есть сразу на нескольких уровнях:

клиент → SDK → сервис → service mesh → зависимый сервис

Если каждый из трёх уровней повторяет неудачный вызов один раз, число обращений в худшем случае может вырасти:

1 → 2 → 4 → 8

В случае Uber проблемный сервис находился более чем на пяти уровнях глубины в цепочке зависимостей. Обычная стратегия retry могла увеличить нагрузку на него ещё на 46–135%.

Uber ограничил усиление нагрузки через error ownership: каждый сервис определяет, является ли ошибка его собственной или пришла от зависимости.

Если ошибка возникла ниже по цепочке, сервис не должен автоматически запускать свой retry поверх уже выполняющихся повторных попыток. Иначе один и тот же сбой начинает повторно обрабатываться сразу несколькими уровнями.

По данным Uber, такой подход позволил предотвратить до 9,5 млн лишних retry-запросов.

Что проверить у себя?

⏺Где именно реализован retry: в приложении, SDK, прокси или service mesh?

⏺Может ли один запрос пройти через несколько механизмов повторных запросов?

⏺Сколько запросов к зависимому сервису приходится на один исходный запрос?

⏺Видно ли отдельно количество исходных запросов и повторных попыток?

Полезный показатель можно посчитать напрямую:

коэффициент усиления = запросы к зависимому сервису / исходные запросы

Например, 10 000 исходных запросов → 17 000 запросов к зависимому сервису означает, что часть нагрузки появилась из-за повторных попыток.

Если во время сбоя одновременно растут ошибки, retry и QPS зависимого сервиса, система может сама усиливать собственную деградацию.

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

👀 Разбор кейса Uber можно прочитать здесь.

#devops #retry