DevOps FM

🐧Релиз Linux Kernel 7.2.11

15 октября вышло обновление стабильной ветки ядра Linux 7.2.11. Оно включает исправления сетевого стека, файловых систем, управления памятью и драйверов оборудования.

Среди наиболее интересных изменений:

🟡Сеть. Исправления затрагивают IPv4/IPv6, TCP, UDP и WireGuard. В Open vSwitch устранена ошибка, которая могла приводить к зависанию ядра при длительной обработке сетевых потоков.

⚫️Файловые системы и точки монтирования. Исправлена обработка операций монтирования и размонтирования, в том числе в пространствах имён.

🟡Шифрование и целостность данных. В dm-integrity исправлена ошибка переполнения буфера при определённых размерах метаданных. В dm-crypt добавлена проверка некорректных комбинаций параметров шифрования.

⚫️Управление памятью. В io_uring исправлен учёт страниц памяти для областей, занимающих несколько страниц.

🟡Драйверы. Обновления затрагивают сетевые адаптеры NVIDIA/Mellanox, Intel и Broadcom, а также драйверы Wi-Fi, Bluetooth и систем хранения.

👨‍💻 Подробнее об изменениях — в полном обзоре релиза.

#devops #linux #релиз

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

🟡GhostAction: вредоносные GitHub Actions похищали секреты из 345 репозиториев.

8 октября злоумышленники использовали скомпрометированные аккаунты сопровождающих проектов, чтобы внедрить вредоносные рабочие процессы. Они собирали не только секреты CI/CD, но и облачные ключи и другие учётные данные из истории Git — в том числе давно удалённые.

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

Подробнее — в разборе StepSecurity.

⚫️GitLab исправила критическую уязвимость, позволяющую выполнять код на сервере без авторизации.

Уязвимость CVE-2026-97229 получила максимальную оценку CVSS 10.0. При определённых условиях специально сформированное регулярное выражение в конфигурации CI/CD могло позволить удалённому злоумышленнику выполнить произвольный код на сервере GitLab.

Исправления доступны в версиях 19.4.2, 19.3.5 и 19.2.8.

Больше деталей читайте в объявлении GitLab.

🟡Let's Encrypt сократит срок действия сертификатов до 64 дней.

С 10 февраля 2027 года новые сертификаты будут действовать 64 дня вместо 90. Тестовая среда переходит на новый срок уже 14 октября 2026 года.

Это делает надёжное автоматическое продление ещё важнее: если процесс обновления сломается, запас времени до истечения сертификата станет меньше.

Подробности в объявлении Let's Encrypt.

⚫️Yandex Cloud продолжает восстановление после атак на дата-центры.

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

Следить за новостями можно в статусе Yandex Cloud.

#новостной_дайджест #devopsfm #безопасность #yandexcloud

AI Platform Engineering: как найти узкое место и не переплачивать за GPU

Представим ситуацию: AI-сервис тормозит под нагрузкой. Растёт время ответа, пользователи жалуются. Команда добавляет GPU-реплики, но задержка не снижается, а расходы растут.

Проблема может быть не в GPU. Узким местом способны оказаться CPU, подготовка данных, очереди запросов или видеопамять.

Эту тему раскрывают два материала CNCF: почему AI-инфраструктуре нужны согласованно работающие CPU и GPU и что нужно Kubernetes-платформе для работы с AI-нагрузками.

Что проверить до масштабирования?

⏺GPU загружен слабо, задержка растёт? Проверьте загрузку CPU, ограничения процессорного времени контейнеров, подготовку и передачу данных, ожидание в очередях. Сопоставьте эти показатели с задержками на разных этапах обработки запроса.

⏺GPU загружен сильно, очередь растёт? Сравните пропускную способность и задержку p95/p99 при разной нагрузке и размерах пакета запросов. Проверьте, не ограничивают ли производительность вычисления или видеопамять.

⏺Новые реплики не помогают? Проверьте, получают ли они доступ к GPU, хватает ли ресурсов узлов Kubernetes и действительно ли растёт общая пропускная способность, а не только число реплик.

⏺Задержка нестабильна? Сопоставьте длину очередей, загрузку CPU и GPU, потребление памяти и время обработки на разных этапах. Определите, при какой нагрузке начинает расти задержка.

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

❓А вы сталкивались с ситуацией, когда масштабирование не помогло? Что оказалось узким местом?

#devops #kubernetes #platformengineering

Канарейка застряла в релизе: поможем с деплоем!

Пятница, конец рабочей недели и новый DevOps-квест. The Silent Canary — интерактивный челлендж от Dynatrace Community, посвящённый Kubernetes и постепенному развёртыванию приложений.

Что предстоит сделать:

⏺Разобраться, почему canary-релиз застрял и не проходит проверки состояния приложения.

⏺Настроить проверки на PromQL, чтобы Argo Rollouts мог оценивать состояние новой версии.

⏺Исправить конфигурацию и провести релиз через этапы 33% → 66% → 100%.

В прохождении пригодятся Kubernetes, YAML, Argo CD, Argo Rollouts и Prometheus. Запустить окружение можно в GitHub Codespaces — без локальной настройки.

Попробовать челлендж можно здесь.

У челленджа есть дедлайн — 13 октября. За успешное прохождение можно получить бейдж и сертификат.

Делитесь в комментариях, получилось ли довести релиз до конца! Желаем всем хорошей практики и приятных выходных🚀

#devops #тренажеры #gamedev

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

⏺GitHub Actions пережил серьёзный сбой из-за проблем с сетевой связностью.

5 октября GitHub Actions и Hosted Runners несколько часов работали с перебоями. В пике 47% рабочих процессов завершались ошибкой, а 71,9% заданий не запускались в течение пяти минут.

Причиной стал сетевой сбой между инфраструктурой GitHub и облачными сервисами баз данных и хранения. Self-hosted runners не пострадали.

Узнать подробности можно в статусе GitHub.

⏺Azure столкнулся со сбоем сетевой инфраструктуры сразу в нескольких регионах.

С 30 сентября по 1 октября проблемы затронули ExpressRoute Gateway, VPN Gateway, Azure Firewall, Application Gateway/WAF и Azure VMware Solution. Часть клиентов столкнулась с деградацией или потерей сетевой связности.

Microsoft связывает сбой с изменением в сервисе управления шлюзами, которое вызвало повышенную нагрузку одновременно с плановым обслуживанием ОС.

Читайте детали в жунале Microsoft.

⏺Kubernetes-инфраструктура Dell оказалась уязвима сразу по нескольким направлениям.

В Container Storage Modules обнаружили две уязвимости с CVSS 10.0. Без аутентификации они позволяют получить административный доступ к подключённым системам хранения.

Отдельная уязвимость в CSM Operator позволяет получить root на узлах Kubernetes. Dell рекомендует обновить CSM до версии 1.18.0 или новее.

Подробнее — в бюллетене Dell.

⏺В GitLab AI Gateway нашли способ превратить конфигурацию AI-агента в RCE.

CVE-2026-90970 позволяет пользователю с доступом к Duo Agent Platform выйти за пределы изоляции шаблонов и выполнить команды на AI Gateway.

Уязвимость исправлена в версиях 19.2.4, 19.3.2 и 19.4.1.

Узнать больше можно в GitLab Docs.

⏺Istio готовится к очередному отключению старых источников артефактов.

13 октября Istio временно отключит старые источники артефактов в Google Cloud. Это очередной тест перед окончательным выводом этой инфраструктуры из эксплуатации в декабре.

Если в CI/CD используются gcr.io/istio-release, registry.istio.io или старый источник Helm-чартов, их стоит заменить заранее.

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

#новостной_дайджест #devops #kubernetes #github #azure #gitlab #istio

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

🎙 Что послушать на выходных: Kubernetes становится слишком сложным?

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

В этот раз предлагаем включить свежий выпуск «Kubernetes: слишком сложно?» от DevOps Дефлопе.

В выпуске обсуждают, как Kubernetes прошёл путь от первых развертываний до eBPF, сложных сетевых решений и внутренних платформ. А ещё — зачем скрывать инфраструктурную сложность от разработчиков и сможет ли искусственный интеллект взять на себя часть работы с Kubernetes.

В гостях Александр Качмашев, техлид внутреннего облака в «Точке», и Александр Поломодов, эксперт по архитектуре и ИИ в разработке.

Получился разговор не только про Kubernetes, но и про то, куда движется инфраструктура и каким будет DevOps в будущем.

🎧 Выпуск «Kubernetes: слишком сложно?» послушать можно здесь.

Желаем приятного прослушивания и выходных без инцидентов! А тем, кто дежурит 🛡 — спокойных смен 🙌🏼

#пятничная_подборка #подкаст #devops #kubernetes #platformengineering #ai

🔔В эфире 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

3 проблемы при запуске приватной LLM в Kubernetes

🖖Бодрый DevOps! Заметили, сколько компаний разворачивают приватные LLM в 2026? Ростелеком, корпорации ITG и прочие крупные игроки уже перешли от запуска пилотов к работе в проде.

Но как только модель оказывается в Kubernetes, появляются сложности. В карточки выше вынесли основные проблемы, с которыми вы столкнетесь при настройке контура приватной LLM.

А пример рабочей архитектуры разберем на камерной встрече DevOps Lab: ML in Production, 26 июня в Новосибирске. Инженер Никсис Пётр Рукин расскажет о KServe, инструменте для ML-инференса, Modelcar для упаковки модели в OCI-образ и загрузок через стандартные механизмы контейнерных рантаймов.

Разберём:

• Как ускорить старт инференса
• Как один OCI-артефакт модели обслуживает 10 деплойментов без копирования
• Как настроить autoscaling моделей, чтобы не платить за простой

Ждём вас на DevOps Lab – покажем, как правильно :)

📍 26 июня, Новосибирск
📍 Регистрация: по ссылке

#никсис #devopslab #ml

Контроль доступа в Kubernetes

🔐Всем DevOps! Собрали для вас подборку статей с LearnKube, которая поможет разобраться, кто может подключаться к серверу API, что именно ему разрешено и как это контролировать в Kubernetes.

В первой статье Гулькан Топку и Артур Чиао сосредоточились на аутентификации. На примерах поймете, как действуют ограничения к серверу HTTP API, ни слова про kubectl.

Следующий этап – авторизация и RBAC. Всё о том, как ограничить доступ, чтобы у каждого пользователя и сервиса были только нужные права.

И наконец, практическая модель адаптации аутентификации под свою инфраструктуру, например через LDAP.

Желаем приятного чтения и продуктивной недели!

#девопс #kubernetes #безопасность