Kubernetes 1.30: sidecar containers в beta и что это меняет для logging и service mesh

Kubernetes 1.30 выходит в апреле - релиз плановый, без громких сломанных обратных совместимостей, но с несколькими вещами, которые стоит разобрать, прежде чем нажимать «обновить» на продакшн-кластерах. Главное из них - sidecar containers перешли в beta, и это не просто смена статуса в changelog.

Почему sidecar в beta - это важнее, чем кажется

Исторически sidecar-паттерн в Kubernetes - это костыль поверх init-контейнеров и обычных контейнеров пода. Logging-агент (fluent-bit, fluentd, векторный коллектор - подставьте свой) запускался как обычный контейнер вместе с основным приложением. Проблема: порядок запуска и завершения не гарантировался. Приложение могло стартовать раньше, чем logging-агент готов принимать данные. При завершении пода - обратная история: основной контейнер останавливался, sidecar ещё мог работать или уже нет. Логи терялись.

С 1.28 появилась нативная поддержка: init-контейнеры с restartPolicy: Always стали «настоящими» sidecar-контейнерами. Kubernetes запускает их до основного контейнера и завершает после. В 1.30 это переходит в beta - значит, API стабилизируется и менять его уже не будут ломая обратную совместимость.

Для нас практически это означает следующее:

Logging-агенты можно переводить на нативный sidecar. Флюент-бит рядом с приложением, который стартует первым и останавливается последним - без ручных postStart/preStop-хуков и без надежды на то, что контейнеры и так запустятся в нужном порядке.

Service mesh агенты (Envoy-прокси в Istio или Linkerd) получают правильную семантику. До нативного sidecar трафик мог пройти через контейнер приложения раньше, чем Envoy поднял свой listener. Редко, но случалось - особенно при быстрых рестартах. Нативный порядок инициализации это закрывает.

Job-и наконец завершаются нормально. Это было отдельной болью: Job с logging-sidecar зависал, потому что sidecar не получал сигнала о завершении и держал под живым. Теперь Kubernetes знает, что sidecar - вспомогательный контейнер, и завершает его корректно при завершении основного.

Что ещё в 1.30

Помимо sidecar, несколько изменений в планировщике и resource API, которые заслуживают внимания.

Улучшенный планировщик с QueueingHints. Механизм переработан: планировщик теперь лучше понимает, когда стоит повторно рассматривать поды для размещения после изменений в кластере. На практике - меньше ситуаций, когда под завис в Pending без видимой причины, а узлы при этом не полностью загружены. У нас несколько клиентов сталкивались с этим на кластерах с неравномерной нагрузкой - посмотрим, насколько улучшения ощутимы в реальности.

API для управления ресурсами (DRA - Dynamic Resource Allocation) продолжает развиваться. Основная идея: вместо того чтобы описывать ресурсы (GPU, специализированные ускорители) через примитивные лимиты в виде чисел, можно декларировать требования к ресурсу через отдельные объекты. Пока это актуально в первую очередь для ML-нагрузок с GPU, но архитектурно это правильное направление.

Отмена ряда устаревших API. Обычная гигиена релиза. Если на кластере всё ещё живут манифесты с flowcontrol.apiserver.k8s.io/v1beta2 - самое время обновить.

Как мы обновляемся: staging сначала

У нас есть несколько клиентов на сопровождении с кластерами в продакшне на 1.28 и 1.29. Перед любым обновлением до новой минорной версии - staging первым, с минимальной выдержкой.

Для 1.30 интересен именно момент с sidecar containers. В staging мы разворачиваем несколько типовых нагрузок с logging-агентами - fluent-bit как sidecar. Задача: проверить, что переход на нативный restartPolicy: Always не ломает существующие конфигурации, которые писались ещё под старую модель.

Первые наблюдения на staging: поды с нативным sidecar стартуют предсказуемее, метрики показывают, что логи при рестарте пода действительно не теряются. Правда, несколько helm-чартов, которые настраивали порядок через initContainers с ожиданием healthcheck, потребовали пересмотра: с нативным sidecar часть этой логики стала избыточной, а местами создала конфликт.

Это нормально - именно для этого существует staging.

Что не трогаем пока

Job-нагрузки с sidecar - следующий этап. Там польза от нативного sidecar максимальная (проблема зависания Job-а с logging-агентом реальная), но и риски пересмотра конфигурации выше. Отдельный тест, отдельное окно.

DRA оставляем наблюдать: у текущих клиентов GPU-нагрузок нет, API в alpha/beta - трогать в продакшне без нужды незачем.

Календарь обновления продакшн-кластеров - после того, как staging отстоится ещё пару недель. Kubernetes 1.30 - не тот релиз, который требует спешки, но sidecar в beta - повод пересмотреть архитектуру logging и mesh-инициализации там, где это было решено обходными путями.