DevOps FM

Как дать командам доступ к метрикам Kubernetes и не открыть весь Prometheus? Всем DevOps!🖖 В прошлом посте мы разбирали, как LegalOn перестраивает платформу для AI-агентов: даёт им нужный контекст и доступ к окружению, но оставляет чёткие границы действий. В свежем материале CNCF инженеры Adobe разбирают похожую задачу для наблюдаемости: как дать командам самостоятельный доступ к метрикам, не открывая весь общий Prometheus. В многопользовательском Kubernetes командам нужны собственные запросы и оповещения, но общий Prometheus нельзя открыть всем: его API не изолирует запросы по пространствам имён, а множество произвольных запросов создаёт на него нагрузку. В Adobe решили проблему через промежуточный слой: команда → проверка прав → ограничение области данных → Prometheus Этот слой ограничивает запросы данными своего пространства имён. А нужные метрики при необходимости можно дополнительно отправлять в отдельный Prometheus команды — для графиков и оповещений. Получается тот же принцип, что и в кейсе LegalOn: самообслуживание без прямого доступа ко всей инфраструктуре. В кейсе Adobe это помогло найти GPU, который 11 дней был выделен, включен, но не использовался. Как у вас устроен доступ команд к метрикам: общий Prometheus с изоляцией или отдельный для каждой команды? Делитесь опытом в комментариях💬

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

🔔В эфире DevOps FM – срединедельный дайджест новостей! 🔊 NVIDIA договорилась о покупке Hugging Face за $12,93 млрд. NVIDIA объявила о соглашении по покупке Hugging Face — платформы с open-source и open-weight AI-моделями. После сделки Hugging Face должна сохранить открытый и мультиоблачный подход. Для NVIDIA это возможность усилить позиции не только в GPU, но и в инфраструктуре для разработки и запуска AI-моделей. Закрытие сделки ожидается в первой половине 2027 года. Детали сделки можно прочитать в блоге NVIDIA. 🔊 В vm2 нашли критическую уязвимость с обходом sandbox и RCE. GitLab Threat Research обнаружила уязвимость с максимальным CVSS 10.0 в популярной Node.js-библиотеке vm2. Она позволяет обойти изоляцию и получить полный доступ к хост-системе. Проблема затрагивает версии 3.11.6 и ниже при включённом require.external. Исправление доступно в 3.11.7. Подробности читайте в исследовании GitLab. 🔊 Google Cloud пережил четырёхчасовой сетевой сбой. 1 сентября в зоне us-central1-b произошёл серьёзный сбой, затронувший Compute Engine, GKE, Cloud Run, Cloud SQL и другие сервисы. Причиной стала ошибка во время планового обслуживания: последовательно были отключены все оптоволоконные пути к части инфраструктуры, из-за чего часть VM в зоне потеряла сетевую связность. Сбой продолжался 4 часа 11 минут. Подробности инцидента — в отчёте Google Cloud. 🔊 Karmada получил статус CNCF Graduated. Karmada стал первым проектом CNCF для управления несколькими Kubernetes-кластерами, достигшим статуса Graduated. Платформа позволяет управлять приложениями сразу в нескольких кластерах, облаках и регионах, а в последних версиях развивает механизмы планирования для распределённых AI-нагрузок. Подробнее — на сайте CNCF. #новостной_дайджест #devopsfm #karmada #security #cloud

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

🎙️ На волне 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

🔔 Друзья, 9 сентября — День тестировщика, и в этот день в Москве пройдет ежегодная конференция, посвященная обеспечению качества и надежности ИТ-систем. Тема — производительность, отказоустойчивость и все практики, которые позволяют системам выдерживать высокие нагрузки. Будет особенно интересно инженерам по нагрузочному тестированию, QA-лидам, DevOps и SRE-специалистам. Можно прийти лично — пообщаться с коллегами, обменяться опытом и узнать много нового из практик и трендов. А если не получается приехать — конференцию можно смотреть онлайн. 📍 Москва, 9 сентября ⌨️ Очно и онлайн Подробности и регистрация на сайте. И в канале конференции.

🔔Новостной дайджест от DevOps FM! ⏺ Вышел релиз Kubernetes 1.37. В новой версии добавили 67 изменений: 16 функций перешли в Stable, 23 — в Beta, ещё 27 получили статус Alpha. Среди основных изменений — переход Metrics API в Stable, обновления сетевых компонентов, поддержка Pod Certificates и Cluster Trust Bundles, а также изменения в kube-proxy и cgroup. Релиз также включает обновления и улучшения для безопасности, управления ресурсами и работы кластера. Подробнее об изменениях Kubernetes рассказали в своем блоге. ⏺Боты создают 98% трафика на git.kernel.org и заставляют ограничивать сервис. git.kernel.org получает около 6 млн запросов в день, и около 98% из них — боты, которые массово запрашивают страницы отдельных коммитов, создавая постоянную нагрузку на серверы. На пяти серверах 14–16 из 90 CPU-ядер постоянно заняты обработкой этих запросов, в результате администраторы начали отключать ресурсоёмкие операции, ограничивать анонимный доступ и сокращать количество доступных для обхода ссылок. Детали читайте в статье. ⏺Amazon завершила покупку DuckLabs, разработчика DuckDB. Сделка была закрыта 31 августа. Команда DuckDB присоединяется к AWS, при этом проект продолжит развиваться под руководством своих основателей. AWS планирует использовать технологии DuckDB для развития своего аналитического стека. Подробнее на OpenNET. ⏺Для Debian 11 завершилась официальная LTS-поддержка. 31 августа закончился период LTS для Debian 11 Bullseye. Для части пакетов и архитектур доступна Extended LTS от Freexian — она продлевает поддержку до 2031 года. Подробнее на OpenNET. ⏺Debian завершил голосование по правилам использования AI. Ранее мы писали о голосовании Debian по правилам использования генеративного AI. Теперь голосование завершено: проект выбрал вариант Responsible Generative AI Use. Подробности читайте в статье. #новостной_дайджест #devopsfm #kubernetes #debian

🔔27 августа в 16:00 МСК наши партнеры проведут бесплатный вебинар: «Нагрузочное тестирование на каждый Pull Request: как встроить перф-контроль в CI/CD за 15 минут» Главный бонус для участников — промокод на скидку на конференцию Перфоманс Конф 12 Вебинар посвящен открытой библиотеке Locomotive (Python, MIT) — инструменту, который встраивает нагрузочное и регрессионное тестирование прямо в CI/CD-пайплайн: тест запускается на каждый Pull Request, результат приходит комментарием к PR, деградация роняет сборку. На вебинаре обсудят: ⏺почему перф-регресс не ловится в CI; ⏺конфиг вместо кода; ⏺реалистичная нагрузка; ⏺пайплайн из коробки; ⏺как выносится вердикт; ⏺когда меняется контракт API; ⏺результаты и ограничения. Кому полезно: инженерам по нагрузочному тестированию и performance-инженерам, QA-, DevOps, SRE специалистам, Backend-разработчикам, QA-лидам и руководителям тестирования и другим. 🎙Спикеры — соавторы Locomotive: Илья Фирсов — выпускник ИТМО, backend-разработчик и DevOps-инженер, 4+ года коммерческой разработки. Дарья Едигарева — выпускница ИТМО, Python-backend-разработчик, 2 года коммерческой разработки. 27 августа, 16:00 МСК Бесплатно Регистрация по ссылке

А что, если 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 ⌨️ В эту пятницу собрали тренажеры, где можно на практике разбирать нетривиальные сценарии Kubernetes, networking и troubleshooting. ⏺ Deadnodes — тренировка в формате production-инцидента: получаем сломанное окружение, ищем root cause и восстанавливаем систему. Есть сценарии по Linux, Kubernetes, networking и базам данных. ⏺ iximiuz Labs — набор hands-on лабораториий с Linux, контейнерами и Kubernetes. Можно самостоятельно разбирать networking, container internals и troubleshooting-сценарии разной сложности. ⏺ Anycast и BGP — меняем маршруты и отключаем PoP, чтобы посмотреть, что происходит с трафиком и TCP-соединениями. Можно разобрать проблемы с long-lived connections и capacity при отказе части инфраструктуры. ⏺ Kubernetes Scheduler Simulator — практика работы с Filter/Score, resource requests, taints и tolerations. Можно посмотреть, почему Pod оказывается Pending, и сравнить стратегии размещения. Сохраняйте подборку, чтобы попробовать эти сценарии на практике и проверить свои навыки troubleshooting. Хорошей практики и приятных выходных! Делитесь своими любимыми тренажерами в комментариях. #девопс #тренажеры

Новостной дайджест от 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

DevOps через Git: насколько реально управлять всей инфраструктурой и deployment из Git? Что, если от создания VPC до выката приложения в Kubernetes вообще не заходить в AWS руками? Именно такой сценарий GitLab разбирает в статье — и он хорошо показывает, куда движется современный DevOps. Если сильно упростить, схема примерно такая: Git → GitLab CI/CD → OpenTofu → AWS/EKS → Argo CD → приложение OpenTofu создаёт и изменяет инфраструктуру, GitLab CI/CD управляет процессом и сборкой, а Argo CD следит за состоянием Kubernetes и синхронизирует его с Git. Вместо привычного сценария:

> Зайди в AWS, поправь вот это. > Потом сделай kubectl apply. > А почему staging теперь отличается от production?

Получаем:

> Изменение инфраструктуры — commit. > Изменение приложения — commit. > Дальше автоматика сама приводит окружение к нужному состоянию.

И вот это уже интереснее, чем просто очередная связка инструментов. IaC + CI/CD + GitOps постепенно превращаются в единую декларативную цепочку, где Git становится источником истины не только для кода, но и для окружения. Плюсы очевидны: ⏺меньше ручных действий; ⏺изменения проходят review; ⏺инфраструктура воспроизводима; ⏺rollback часто превращается в git revert; ⏺окружение можно восстановить из кода. Но ведь чем больше production мы передаём автоматизации, тем важнее становится надёжность самого control plane. Отсюда возникают следующие вопросы: ⏺Что делать, если GitLab недоступен? ⏺Как внести emergency change? ⏺Кто имеет break-glass доступ? ⏺Можно ли восстановить инфраструктуру, если недоступны инструменты, которые ей управляют? И, пожалуй, это один из интересных вопросов современного DevOps — что важнее: полностью исключить ручные изменения или сохранить возможность быстро обойти автоматизацию в аварийной ситуации? Делитесь своим мнением в комментариях💬 Желаем продуктивной недели и спокойных дежурных смен!

Пятничное чтиво от 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 – срединедельный дайджест новостей и статей! ⏺ 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 тг

KYAML vs YAML: зачем усложнять простое? YAML давно стал привычным инструментом для DevOps. Но у него есть обратная сторона: неявные типы, зависимость структуры от отступов и множество возможностей, которые Kubernetes на самом деле не использует. Kubernetes предлагает более строгий подход к конфигурациям — KYAML и описывает его преймущества в своем блоге. Идея в том, чтобы оставить от YAML только то, что действительно нужно Kubernetes, и убрать неоднозначности. Что получает DevOps? 🟡 меньше зависимости от отступов; 🟡 более предсказуемую работу со строками и типами; 🟡 явное обозначение списков [] и структур {}; 🟡 более удобную работу с генерацией, шаблонами и автоматизацией; 🟡 KYAML остаётся валидным YAML и рассчитан на совместимость с существующими YAML-парсерами. Но есть и другая сторона. Среди обсуждений инженеров можно встретить мнение, что KYAML не избавляет Kubernetes-конфиги от сложности, объясняя это тем, что:  🟡 KYAML не уберёт Helm-шаблоны, огромные манифесты и десятки взаимосвязанных параметров. А значит, вместо решения основной проблемы можно получить ещё один формат, который команде придётся изучать и поддерживать; 🟡YAML уже встроен практически во всю DevOps-экосистему — от IDE и линтеров до CI/CD-инструментов. KYAML — новый подход, а значит, не все инструменты одинаково хорошо его поддерживают. И здесь возникает главный вопрос: KYAML действительно решает проблемы YAML — или просто вводит более строгие правила там, где и так всё работало? 👀 А вы бы использовали KYAML в своих проектах, либо же обычного YAML вам вполне хватает? Поделитесь мыслями.

KYAML vs YAML: зачем усложнять простое? YAML давно стал привычным инструментом для DevOps. Но у него есть обратная сторона: неявные типы, зависимость структуры от отступов и множество возможностей, которые Kubernetes на самом деле не использует. Kubernetes предлагает более строгий подход к конфигурациям — KYAML и описывает его преймущества в своем блоге. Идея в том, чтобы оставить от YAML только то, что действительно нужно Kubernetes, и убрать неоднозначности. Что получает DevOps? 🟡 меньше зависимости от отступов; 🟡 более предсказуемую работу со строками и типами; 🟡 явное обозначение списков [] и структур {}; 🟡 более удобную работу с генерацией, шаблонами и автоматизацией; 🟡 KYAML остаётся валидным YAML и рассчитан на совместимость с существующими YAML-парсерами. Но есть и другая сторона. Среди обсуждений инженеров можно встретить мнение, что KYAML не избавляет Kubernetes-конфиги от сложности, объясняя это тем, что:  🟡 KYAML не уберёт Helm-шаблоны, огромные манифесты и десятки взаимосвязанных параметров. А значит, вместо решения основной проблемы можно получить ещё один формат, который команде придётся изучать и поддерживать; 🟡YAML уже встроен практически во всю DevOps-экосистему — от IDE и линтеров до CI/CD-инструментов. KYAML — новый подход, а значит, не все инструменты одинаково хорошо его поддерживают. И здесь возникает главный вопрос: KYAML действительно решает проблемы YAML — или просто вводит более строгие правила там, где и так всё работало? 👀 А вы бы использовали KYAML в своих проектах, либо же обычного YAML вам вполне хватает? Поделитесь мыслями.

🎙 Что послушать на выходных: Kubernetes и энергопотребление В пятницу делимся свежим выпуском Kubernetes Podcast про Project Kepler — open-source проект для наблюдения за энергопотреблением Kubernetes-нагрузок. В гостях Ники Маноледаки, Staff Platform Engineer в Grafana Labs и мейнтейнер Project Kepler. Вместе с ведущими она обсуждает, как оценивать энергопотребление рабочих нагрузок, какие метрики для этого можно собирать и почему получить реально точные данные не так просто. Отдельно поговорили о том, зачем Kepler недавно переписали, как проект использует eBPF и Prometheus и при чём здесь растущие вычислительные нагрузки AI. 🎧 Выпуск «Measuring Sustainability via Project Kepler» послушать можно здесь. Желаем приятного прослушивания и хороших выходных! А тем, кто дежурит 🛡, — спокойных смен. #подкаст #devops #kubernetes #observability #opensource

Новостной дайджест от DevOps FM! 🔔 Делимся свежими новостями, релизами и разборами инженерных практик за неделю. 🟡 В блоге Kubernetes вышел предварительный обзор версии 1.37, релиз которой запланирован на конец августа. Разработчики рассказали о ключевых изменениях, которые планируется включить в релиз: более 20 новых экспериментальных функций, а также улучшения для динамического распределения ресурсов, сетевого стека и управления рабочими нагрузками. Подробнее читайте в обзоре. ⚫️ В том же блоге Kubernetes вышел анонс релиза Gateway API v1.6, в котором ресурсы TCPRoute и UDPRoute перешли в стабильный канал Standard. Это обновление приносит переносимую и стабильную маршрутизацию трафика на L4-уровне. Детали читайте в официальном обзоре. 🟡 Исследователи Wiz обнаружили критическую цепочку уязвимостей CosmosEscape в Azure Cosmos DB (не без ИИ-помощника). Найденая брешь в API Gremlin позволяла полностью обойти изоляцию облака, получить доступ к внутреннему токену платформы и получить доступ на чтение и запись к базам данных любых клиентов, включая внутренние сервисы Microsoft вроде Teams и Copilot. Microsoft уже полностью устранила проблему, переработав архитектуру безопасности. Подробный технический разбор читайте в материале The Hacker News. ⚫️ Компания Percona представила Technical Preview сервера для MongoDB 8.3, пропустив промежуточные ветки 8.1 и 8.2. Сборка объединила улучшения сразу трех минорных релизов, включая новый планировщик запросов Cost-Based Ranker, а также прирост производительности до 195% при массовой вставке временных рядов. Разработчики подчеркивают, что версия предназначена только для ознакомления — какие архитектурные изменения и новые лимиты памяти ждут СУБД, читайте в официальном блоге Percona. 🟡 В блоге Red Hat вышел технический обзор обновлений OpenShift, посвященный защищенным вычислениям и безопасности ИИ. Одним из ключевых нововведений стал инструмент Agent Sandbox — изолированная среда на уровне виртуальных машин для безопасного запуска автономных ИИ-агентов и выполнения непроверенного кода. Также технология конфиденциального ИИ на bare-metal серверах перешла в статус GA. Как новые механизмы защищают веса моделей на уровне процессора и GPU — читайте в обзоре. ⚫️ Исследователи обнаружили компрометацию npm-пакета keyv в рамках масштабной кампании Shai-Hulud (“Дюна”, привет). Вредоносный код запускался через lifecycle-скрипт preinstall и мог извлекать секреты из окружений разработки и CI/CD-пайплайнов, включая токены облачных сервисов. Зараженные версии удалены из npm. Проверить затронутые зависимости и индикаторы компрометации можно в техническом разборе Wiz. #новостная_подборка #devops #kubernetes #security #cloudsecurity #mongodb #openshift #supplychain #npm

🎉 Команда DevOps FM поздравляет с Днём системного администратора! Забавно, что идеальный рабочий день системного администратора выглядит примерно так: - мониторинг молчит; - платформа управления ИТ-инцидентами не звонит; - бэкапы успешно проходят проверку; - пользователи не пишут «ничего не менял, оно само». То есть когда инфраструктура незаметна, именно потому что очень много для этого сделано. Поздравляем всех, кто делает ее такой незаметной 🙌🏼 Желаем всем хороших выходных и спокойных дежурств! #SysAdminDay