Kubernetes 1.37 "Garhwal": KYAML стал стабильным, а HPA получил масштабирование до нуля
Выпуск Kubernetes 1.37 Garhwal стал заметным этапом развития платформы оркестрации контейнеров. В новой версии разработчики перевели формат KYAML в стабильный статус, включили поддержку масштабирования рабочих нагрузок до нуля в HorizontalPodAutoscaler и представили ряд улучшений для управления ресурсами, безопасности, хранения данных и планирования задач.
KYAML представляет собой более строгий и однозначный вариант YAML, адаптированный для конфигураций Kubernetes. При этом он сохраняет совместимость с обычным YAML, поэтому переход не требует полного переписывания существующих манифестов. Стабильный статус означает, что формат и связанное с ним поведение теперь считаются достаточно зрелыми для использования в производственных кластерах. Команда также перевела в стабильный статус параметр `kubectl get -o kyaml`, позволяющий получать объекты в новом представлении. Подробнее о ключевых изменениях рассказывает материал о [стабильном KYAML в Kubernetes](https://linuxiac.com/kubernetes-1-37-garhwal-brings-kyaml-to-stable/).
Еще одним важным изменением стало завершение многолетнего перехода API `metrics.k8s.io` в стабильную ветку. Почти девять лет этот интерфейс находился в статусе Beta. Он предоставляет сведения о потреблении процессора и памяти подами и узлами кластера, а также используется такими инструментами, как `kubectl top` и HorizontalPodAutoscaler.
Именно в области автоматического масштабирования произошло одно из наиболее практичных нововведений. В Kubernetes 1.37 функция HorizontalPodAutoscaler scale-to-zero получила статус Beta и стала активной по умолчанию. Рабочие нагрузки, использующие внешние или объектные метрики, теперь могут задавать значение `minReplicas: 0`. Если приложение простаивает, кластер способен полностью остановить его поды, а затем запустить их снова при возвращении нагрузки. Это особенно полезно для сервисов с нерегулярным трафиком, фоновых обработчиков и задач, которые не должны постоянно занимать вычислительные ресурсы.
Расширились и возможности Dynamic Resource Allocation. Несколько функций DRA достигли стабильного уровня, а механизм получил дополнительную поддержку заявок на ресурсы, задаваемых непосредственно на уровне рабочих нагрузок. Такой подход важен для приложений, которым требуются специализированные устройства, ускорители, сетевые ресурсы или другие компоненты, распределяемые сложнее обычных CPU и RAM.
В beta-ветку добавлено групповое планирование, или gang scheduling. Оно позволяет запускать набор связанных подов только в том случае, если планировщик может одновременно выделить достаточно ресурсов для всей группы. Это предотвращает ситуацию, когда часть распределенного задания запускается, а оставшиеся компоненты надолго остаются в очереди. Возможность ориентирована прежде всего на проекты в области искусственного интеллекта, машинного обучения и высокопроизводительных вычислений.
Заметные изменения коснулись безопасности. Сертификаты подов и ClusterTrustBundles стали стабильными API. Благодаря этому Kubernetes предоставляет встроенные механизмы для передачи рабочим нагрузкам сертификатов и доверенной информации без необходимости полагаться исключительно на сторонние операторы или самописные решения.
В области хранения данных стабильным стал API StorageVersionMigration. Он помогает переводить сохраненные объекты между версиями схем и упрощает сопровождение кластеров при изменении форматов ресурсов. Кроме того, обновление Kubernetes включает улучшенную обработку томов SELinux, причем соответствующее поведение теперь активируется по умолчанию. Поддержка нативных гистограмм Prometheus, в свою очередь, перешла в статус Beta, открывая дополнительные возможности для наблюдаемости и более точного анализа метрик.
Администраторам следует учитывать и несколько направлений, связанных с устаревшими технологиями. Дополнение kube-dns официально объявлено устаревшим: для новых развертываний рекомендуется использовать CoreDNS. В путь депрекации также вошел режим IPVS компонента kube-proxy. Организациям, которые все еще используют эту конфигурацию, стоит заранее оценить варианты миграции и проверить совместимость сетевой архитектуры.
Отдельное внимание разработчики уделяют переходу от cgroup v1 к cgroup v2. Пользователям рекомендуется не откладывать миграцию, поскольку поддержка старой версии иерархии групп управления ресурсами в будущем будет удалена. Переход заранее позволит избежать неожиданных ограничений при последующих обновлениях и проверить работу контейнерного runtime, средств мониторинга и политик управления ресурсами.
Для команд эксплуатации выпуск Kubernetes 1.37 означает не только набор новых функций, но и необходимость пересмотреть жизненный цикл кластеров. Перед внедрением в production стоит проверить версии CoreDNS, kube-proxy и контейнерного runtime, протестировать HPA с нулевым количеством реплик, а также убедиться, что используемые манифесты корректно обрабатываются KYAML.
KYAML может оказаться особенно полезным в GitOps-процессах и инфраструктуре, где конфигурации проходят автоматическую проверку. Более строгий синтаксис уменьшает вероятность неоднозначного разбора YAML, облегчает ревью изменений и помогает выявлять ошибки еще до применения ресурсов в кластере. При этом сохранение совместимости с YAML снижает порог перехода для существующих проектов.
Обновление Kubernetes уже доступно. Перед развертыванием в рабочей среде рекомендуется ознакомиться с полным перечнем изменений, проверить депрекации и провести поэтапное тестирование на отдельном кластере. Подробный обзор возможностей выпуска, включая KYAML Kubernetes, опубликован в материале о релизе Garhwal на Linuxiac: Kubernetes 1.37 Garhwal и стабильный KYAML.
