Kubernetes 1.34: что перешло в GA и на что смотреть при плановом обновлении

Kubernetes 1.34 вышел на прошлой неделе, и мы уже начали разбирать changelog на предмет того, что реально влияет на production. Не всё, что переходит из Beta в GA, одинаково важно - часть изменений незаметна в повседневной эксплуатации, а часть требует внимания прямо сейчас. Разберём самое существенное.

Resource Management API: наконец-то GA

Самое заметное в 1.34 - перевод в stable нескольких API из группы Resource Management. Речь прежде всего о ResourceClaim и ResourceClaimTemplate из DRA (Dynamic Resource Allocation), которые дошли до GA после нескольких релизов в Alpha/Beta.

DRA - это альтернативный механизм запроса ресурсов, который не укладывается в классическую модель requests/limits. Главный use case - специализированное железо: GPU, FPGA, сетевые ускорители. Классическая модель там работает грубо: ресурс либо занят целиком, либо свободен. DRA позволяет описывать требования к ресурсу более гибко - например, запросить GPU с определёнными характеристиками, а не конкретное устройство.

На практике что это значит для нас сейчас:

• Кластеры без GPU/FPGA - DRA GA не влияет на повседневную работу. Feature gate DynamicResourceAllocation был включён по умолчанию с 1.32, но если вы не используете ResourceClaim в манифестах, ничего не меняется.
• Кластеры с GPU - если до этого вы использовали NVIDIA device plugin в классическом режиме через nvidia.com/gpu: 1, то он продолжает работать. Но если планировали пробовать DRA-режим через новые драйверы NVIDIA - теперь API стабилизировано, можно переходить без риска что оно поменяется в следующем релизе.
• Один важный момент с миграцией. Если на кластере есть ResourceClaim-объекты, созданные в период Beta (apiVersion resource.k8s.io/v1beta1), и вы обновляетесь до 1.34 - убедитесь, что контроллеры и device-плагины обновлены до версий, понимающих v1. Мы обновление с Beta-объектами DRA в production ещё не отрабатывали, но по changelog видно, что конвертация между версиями есть, однако без актуальных плагинов кластер может оказаться в состоянии, где старые ResourceClaim не reconciled.

HPA: улучшения в поведении scaling

HPA (Horizontal Pod Autoscaler) получил несколько изменений, которые переходят в GA.

HPAContainerMetrics - возможность масштабировать деплоймент по метрикам конкретного контейнера внутри пода, а не по агрегированным метрикам пода целиком. Это было в Beta достаточно долго, теперь GA. Для многоконтейнерных подов это существенно: если у вас приложение + sidecar (скажем, Envoy), и sidecar кушает немало CPU, агрегированная метрика даёт искажённую картину. С containerName в spec.metrics вы масштабируете по тому контейнеру, который действительно отвечает за нагрузку.

metrics:
- type: ContainerResource
  containerResource:
    name: cpu
    container: app
    target:
      type: Utilization
      averageUtilization: 70

Tolerance и stabilization - в 1.34 поведение HPA при небольших отклонениях метрик стало более предсказуемым. Раньше при oscillation вокруг целевого значения HPA мог совершать лишние scale-операции, что создавало шум в событиях и не всегда было приятно для workload. Теперь алгоритм более устойчив к мелким флуктуациям по умолчанию.

На кластерах, где мы сопровождаем HPA-конфигурации для нескольких заказчиков, это означает, что поведение может слегка измениться - не поломаться, но стать другим. Стоит после обновления посмотреть на историю scaling-событий и убедиться, что оно соответствует ожиданиям.

Что убрали и что сломается

В 1.34 несколько вещей окончательно удалены после долгого deprecation:

• flowcontrol.apiserver.k8s.io/v1beta3 - если у вас есть FlowSchema или PriorityLevelConfiguration с этой версией API (удалена в 1.32, но кластеры с долгим upgrade-лагом могут об этом ещё не знать), после обновления они перестанут работать. Нужно мигрировать на v1. Проверяется просто:

kubectl get flowschemas,prioritylevelconfigurations -o json | \
  jq '.items[].apiVersion' | grep -c v1beta3

Если вывод не ноль - есть что мигрировать до обновления.

• Несколько устаревших флагов kubelet - ряд флагов, которые перестали иметь смысл после полного перехода на CRI, окончательно убраны в предыдущих циклах (часть ещё в 1.27). Если у вас кастомизированный запуск kubelet через systemd-юнит или конфигурационный файл со старыми флагами - при обновлении kubelet просто не стартует. Проверьте /etc/kubernetes/kubelet.conf и systemd-оверрайды заранее.

Что в Alpha/Beta, на что стоит обратить внимание

InPlacePodVerticalScaling - вертикальное масштабирование без рестарта пода - всё ещё в Beta. Технически использовать можно, но API может меняться. В production использовать не рекомендуем до GA.

PodLifecycleSleepAction в lifecycle hooks дошёл до GA - теперь можно в preStop-хуке писать просто sleep: seconds: 5 вместо exec-команды. Мелочь, но приятная: убирает зависимость от наличия sleep в контейнере.

Как планируем обновление

Само обновление до 1.34 мы планируем через Deckhouse в штатном порядке - как делали с 1.33. Новых рисков по механике обновления платформы нет, Deckhouse поддержку 1.34 добавит в ближайшие недели.

Чеклист перед обновлением пополнился одним пунктом: проверка apiVersion у FlowSchema и PriorityLevelConfiguration. Остальное из нашего стандартного списка - PDB, кастомные kubelet-флаги, совместимость device-плагинов - актуально как всегда.

В целом 1.34 - это релиз, где GA-статус даёт реальную уверенность: API больше не изменятся, можно строить поверх них production-конфигурации. DRA GA особенно важен для тех, кто работает с GPU-кластерами - теперь есть стабильная основа. Остальное - плановое накопление улучшений, без срочности. В managed-сопровождении мы обновляем кластеры поэтапно, и 1.34 войдёт в базовую линейку для новых кластеров после того, как Deckhouse выпустит поддержку.