Kubernetes 1.31: sidecar в stable, deprecated in-tree storage drivers - проверяем кластеры

RC Kubernetes 1.31 вышел на прошлой неделе - стабильный релиз ожидается примерно через месяц. Мы в таких случаях не ждём GA, а начинаем разбираться заранее: смотрим changelog, прогоняем в тестовой среде, ищем, где оно может сломать нас раньше, чем мы сломаем его сами.

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

Deprecated in-tree storage drivers: надо проверить сейчас

Kubernetes последовательно выносит драйверы хранилищ из дерева core в отдельные CSI-плагины - процесс тянется с 1.23, но в 1.31 он продвинулся настолько, что ряд in-tree провайдеров получил статус deprecated с явной датой удаления в следующих минорных версиях.

Речь про драйверы для AWS EBS, GCE PD, Azure Disk, Cinder (OpenStack) и нескольких других - если кластер стоит в одном из этих облаков и StorageClass или PersistentVolume ссылаются на in-tree provisioner, пора мигрировать на CSI-эквивалент. Для on-premise и bare-metal окружений всё чище: там обычно уже давно ceph-csi, NFS-provisioner или что-то подобное.

Мы прошлись по кластерам на сопровождении с несложным запросом:

kubectl get storageclass -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.provisioner}{"\n"}{end}'

И отдельно проверили PV с deprecated provisioner-ами:

kubectl get pv -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.csiDriver.driver}{"\t"}{.spec.awsElasticBlockStore}{"\n"}{end}'

Результат: большинство кластеров чистые, но у двух клиентов с legacy-нагрузкой нашлись StorageClass, которые прописаны с kubernetes.io/aws-ebs вместо ebs.csi.aws.com. PV уже созданы, данные никуда не денутся - но новые PVC по этому StorageClass с 1.31 могут начать вести себя непредсказуемо, а в 1.32-1.33 provisioner и вовсе пропадёт.

Миграция несложная, но требует аккуратности: создать новый StorageClass с CSI-провайдером, убедиться что драйвер установлен, обновить дефолтный класс, при необходимости пересоздать рабочие нагрузки с volume claim templates (StatefulSet здесь - отдельная история, там PVC не пересоздаются автоматически).

Это именно та работа, которую не видно пока не надо делать срочно.

Sidecar containers в stable: наконец-то можно переходить без оговорок

В Kubernetes 1.30 sidecar перешёл в beta - мы тогда начали тестировать в staging. В 1.31 - stable. API зафиксирован, поведение стабилизировано, feature gate включён по умолчанию без возможности выключить.

Практически это означает: logging-агенты, которые сейчас работают как обычные контейнеры в поде (fluent-bit, vector, любой другой), можно и нужно переводить на нативную sidecar-механику через initContainers с restartPolicy: Always.

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

Порядок запуска и завершения гарантирован. Logging-агент стартует до основного контейнера приложения и завершается после. Без postStart-хуков с sleep, без надежды на то, что kubelet запустит контейнеры в нужном порядке.

Логи при рестарте пода не теряются. Это была реальная проблема у нескольких клиентов - приложение упало, перезапустилось, а logging-агент в этот момент тоже перезапускался, и несколько секунд логов просто пропадали. С нативным sidecar это закрыто.

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

Мы обновили конфигурации fluent-bit для нескольких кластеров - изменение минимальное, но требует пересмотра того, как описан контейнер. Раньше:

containers:
  - name: fluent-bit
    image: fluent/fluent-bit:3.0
    # ...обычный контейнер

Теперь:

initContainers:
  - name: fluent-bit
    image: fluent/fluent-bit:3.0
    restartPolicy: Always
    # ...остальное без изменений

Звучит тривиально - но несколько Helm-чартов, где порядок инициализации решался через initContainers с ожиданием healthcheck агента, потребовали пересмотра. С нативным sidecar часть этой логики стала избыточной, а местами вступала в конфликт с новой механикой. Ничего драматичного, но внимание нужно.

Планировщик: улучшения продолжаются

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

На нескольких кластерах мы видели эту проблему - под в Pending, узлы загружены неравномерно, а планировщик не торопится его разместить. После обновлений на 1.30 поведение улучшилось; в 1.31, судя по changelog, работа продолжается в том же направлении. Проверим на staging.

Что делаем сейчас

Тестовый кластер уже на RC. Основное внимание - поведение CSI-драйверов при миграции с in-tree (воспроизводим кейс из продакшна), и logging-агенты на новой sidecar-механике под нагрузкой.

Клиентам с выявленными in-tree StorageClass - отдельные задачи на миграцию, не дожидаясь GA 1.31. Это лучше сделать в плановом режиме, а не потому что старый provisioner внезапно перестал работать.