Kubernetes 1.37 «Garhwal»: KYAML стал стабильным, а Kubernetes получил десятки важных улучшений

Проект Kubernetes получил очередное крупное обновление — версию 1.37 с кодовым названием «Garhwal». Новый релиз ориентирован не на одну отдельную функцию, а на комплексное повышение зрелости платформы: сразу 16 возможностей перешли в стабильный статус, еще 23 получили статус Beta, а 27 функций появились или развились на этапе Alpha.

Одним из наиболее заметных изменений стал переход KYAML в Stable. Этот формат предназначен для более однозначного и безопасного описания конфигураций Kubernetes и призван уменьшить количество ошибок, связанных с особенностями обычного YAML. Одновременно стабильным стал API metrics.k8s.io, расширились возможности динамического управления ресурсами, появились новые инструменты для планирования групп Pod, а функции, связанные с сертификатами и доверенными цепочками, достигли уровня готовности для полноценного использования.

Для администраторов особенно важны и менее заметные изменения. Kubernetes продолжает переход на cgroup v2, совершенствует обработку SELinux, постепенно отказывается от устаревшего kube-dns и переводит kube-proxy с IPVS в категорию устаревающих технологий.

Что нового в Kubernetes 1.37

Релиз Kubernetes 1.37 является очередным этапом эволюции контейнерной платформы. Разработчики уделили внимание не только новым возможностям, но и переводу давно существующих функций из экспериментального состояния в стабильное.

Главные изменения можно условно разделить на несколько направлений:

• KYAML получил статус Stable;
• API metrics.k8s.io стал стабильным;
• HorizontalPodAutoscaler получил поддержку масштабирования до нуля в Beta;
• расширены возможности Dynamic Resource Allocation;
• gang scheduling перешел в Beta;
• Pod Certificates и ClusterTrustBundles стали стабильными;
• улучшена работа Kubernetes с SELinux;
• Storage Version Migration получил стабильный статус;
• продолжается переход с cgroup v1 на cgroup v2;
• начался новый этап отказа от kube-dns и IPVS-режима kube-proxy.

KYAML наконец стал Stable

Одним из главных нововведений Kubernetes 1.37 стал переход KYAML в стабильный статус. Технология появилась в Kubernetes 1.34 как Alpha-функция, затем в версии 1.35 перешла в Beta, а теперь после завершения проверки совместимости стала частью стабильного API-инструментария.

KYAML не является отдельным конкурентом YAML и не требует переписывать существующие Kubernetes-манифесты. Это более строгий и менее неоднозначный поднабор YAML, специально разработанный с учетом особенностей конфигураций Kubernetes.

Проблема традиционного YAML заключается не только в отступах. Формат допускает различные способы представления одних и тех же структур и использует неявное преобразование типов. В сложных конфигурациях это может приводить к ошибкам, которые сложно обнаружить при визуальной проверке.

KYAML делает структуру данных более явной. В частности, для строк используются двойные кавычки, объекты и массивы имеют однозначное представление, а потенциально неоднозначные конструкции YAML исключаются.

Важным преимуществом является обратная совместимость. KYAML-файл остается допустимым YAML, поэтому существующие инструменты Kubernetes не требуют немедленной замены.

Стабильной также стала возможность получить представление ресурсов в KYAML с помощью команды:

kubectl get <resource> -o kyaml

Это может оказаться особенно полезным при автоматизации, GitOps-процессах, ревью конфигураций и генерации манифестов.

Зачем Kubernetes нужен KYAML

В больших инфраструктурах Kubernetes-манифесты могут содержать сотни или даже тысячи строк. Чем больше конфигурация, тем выше вероятность ошибки в отступах, типах значений или структуре объекта.

Более строгий формат помогает уменьшить неоднозначность и делает конфигурационные файлы предсказуемее. Это особенно актуально для CI/CD, Helm, GitOps и систем автоматического управления инфраструктурой.

При этом разработчики Kubernetes не требуют от пользователей немедленно переходить на KYAML. Обычные YAML-манифесты продолжают работать, а существующие пайплайны не должны ломаться из-за появления нового формата.

metrics.k8s.io стал стабильным

Еще одним важным событием стал переход API metrics.k8s.io в Stable. До этого он находился в Beta почти девять лет.

Этот API предоставляет стандартный способ получения данных об использовании CPU и памяти Pod и узлами Kubernetes. Информация используется целым рядом инструментов, включая HorizontalPodAutoscaler и команду kubectl top.

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

При этом переход не означает мгновенное исчезновение старого API. Версия v1beta1 остается доступной в рамках политики совместимости Kubernetes, поэтому миграцию можно выполнять постепенно.

HPA научился масштабировать приложения до нуля

HorizontalPodAutoscaler получил еще одну важную возможность. В Kubernetes 1.37 поддержка масштабирования до нуля находится в Beta и включена по умолчанию.

Раньше автоматическое масштабирование обычно подразумевало наличие как минимум одного экземпляра приложения. Теперь для рабочих нагрузок, использующих внешние или объектные метрики, значение minReplicas может быть установлено в ноль.

Это особенно интересно для приложений с периодической нагрузкой. Если сервис большую часть времени не получает запросов, Kubernetes может полностью остановить его Pod, а затем запустить их снова при появлении необходимости.

Такой подход позволяет экономить ресурсы Kubernetes-кластера и снижать стоимость инфраструктуры.

Однако масштабирование до нуля подходит не всем приложениям. Если запуск контейнера занимает много времени или приложение должно постоянно поддерживать соединения, полное выключение Pod может негативно сказаться на задержке ответа.

Dynamic Resource Allocation получил новые возможности

Dynamic Resource Allocation, или DRA, продолжает развиваться и в Kubernetes 1.37 переводит ряд возможностей в Stable.

DRA предназначен для более гибкого распределения специализированных ресурсов между рабочими нагрузками. Это особенно актуально для GPU, сетевых устройств и других аппаратных компонентов, которые невозможно эффективно описать только стандартными запросами CPU и памяти.

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

Особенно интересен этот механизм для сетевых устройств. Если Pod получает дополнительный сетевой интерфейс через DRA, другие компоненты теперь могут получать стандартизированную информацию о состоянии такого устройства.

Gang scheduling для AI, ML и HPC

Еще одна заметная функция Kubernetes 1.37 — переход gang scheduling в Beta.

Обычный планировщик Kubernetes работает с Pod по отдельности. Для многих традиционных приложений этого достаточно. Но распределенные задачи машинного обучения и высокопроизводительных вычислений часто требуют одновременного запуска нескольких Pod.

Представим задачу обучения модели, которой необходимы восемь GPU и восемь взаимосвязанных Pod. Если Kubernetes сможет запустить только четыре Pod, остальные четыре будут ждать ресурсов. При определенных условиях это приводит к неэффективному использованию кластера и даже к своеобразной взаимной блокировке.

Gang scheduling решает эту проблему с помощью подхода «все или ничего»: группа связанных Pod должна получить возможность запуститься как единое целое.

В Kubernetes 1.37 развитие этой функции связано с Workload API и концепцией PodGroup. Также появились механизмы, которые помогают учитывать рабочую нагрузку при вытеснении Pod и управлять очередями групп.

Для инфраструктур, где Kubernetes используется для AI/ML, HPC и других распределенных вычислений, это может стать одним из наиболее практически значимых изменений нового релиза.

Сертификаты Pod и ClusterTrustBundles стали стабильными

В Kubernetes 1.37 стабильный статус получили Pod Certificates и ClusterTrustBundles. Эти механизмы позволяют организовать более нативную доставку сертификатов, закрытых ключей и доверенных центров сертификации в рабочие нагрузки.

Pod может получить сертификат через специальный механизм проецируемого тома. При этом система может автоматически обновлять сертификат, когда подходит срок его действия.

ClusterTrustBundles дополняют этот механизм, предоставляя Pod информацию о доверенных сертификатах, необходимых для проверки соединений.

Такой подход особенно интересен для микросервисных архитектур, где компоненты постоянно взаимодействуют друг с другом по защищенным каналам. Вместо ручного управления сертификатами можно использовать встроенные механизмы Kubernetes и специализированный signer controller.

Улучшения SELinux

В Kubernetes 1.37 функции SELinuxMount и SELinuxChangePolicy достигли стабильного статуса и включены по умолчанию.

Изменения позволяют эффективнее работать с SELinux-контекстами при подключении томов. В подходящих конфигурациях вместо рекурсивной маркировки файловой системы используется параметр монтирования с контекстом.

Это может существенно сократить затраты времени на работу с большими томами, поскольку системе не всегда требуется проходить по каждому объекту файловой системы.

Однако администраторам необходимо учитывать совместимость рабочих нагрузок. Если один и тот же том используется Pod с различными SELinux-метками, новая модель может привести к тому, что отдельные Pod не смогут запуститься.

Для таких случаев Kubernetes предоставляет возможность сохранить прежнее поведение с помощью соответствующей политики изменения SELinux.

Улучшена инициализация watch cache

Разработчики также продолжили работу над надежностью Kubernetes API Server. В версии 1.37 окончательно стабилизирован механизм, связанный с инициализацией watch cache.

Watch cache играет важную роль в снижении нагрузки на etcd. При запуске или восстановлении API Server массовая инициализация кеша могла создавать дополнительный поток запросов к хранилищу.

Новая логика позволяет более контролируемо обрабатывать подобные ситуации. Запросы, которые нельзя безопасно обслужить во время восстановления кеша, могут получать HTTP 429 вместо того, чтобы создавать неконтролируемую нагрузку.

Для разработчиков операторов и контроллеров это означает необходимость корректно обрабатывать ответы 429 Too Many Requests. В автоматизированных системах рекомендуется использовать повторные попытки с экспоненциальной задержкой и учитывать заголовок Retry-After.

Kubernetes продолжает переход на cgroup v2

Еще один важный долгосрочный тренд — отказ Kubernetes от cgroup v1.

Начиная с предыдущих релизов, проект все активнее переводит пользователей на cgroup v2. В Kubernetes 1.37 возможность временно использовать старую модель сохраняется, но ее следует воспринимать как переходный механизм.

cgroup v2 необходима для ряда современных возможностей управления ресурсами Linux. В частности, с ней связаны расширенные функции контроля памяти и некоторые новые механизмы динамического изменения ресурсов.

Если узлы Kubernetes по-прежнему используют cgroup v1, администраторам уже сейчас стоит проверить конфигурацию операционной системы и среды выполнения контейнеров.

В противном случае очередное обновление Kubernetes в будущем может потребовать срочной миграции.

Kube-dns официально отправляется в устаревание

В Kubernetes 1.37 разработчики формально обозначили kube-dns как устаревающую технологию.

CoreDNS уже давно является стандартным DNS-решением Kubernetes. Он используется по умолчанию с Kubernetes 1.13 и продолжает развиваться значительно активнее старого kube-dns.

Одной из причин окончательного перехода является поддержка современных возможностей Kubernetes, включая EndpointSlices и сценарии с двойным стеком IPv4/IPv6.

Поэтому новые кластеры не должны строиться вокруг kube-dns, а владельцам старых инфраструктур стоит заранее запланировать миграцию.

IPVS в kube-proxy также движется к удалению

Еще одно изменение, которое важно учитывать администраторам, касается kube-proxy. Его режим IPVS также оказался на пути к устареванию.

Это не означает, что существующие кластеры перестанут работать сразу после обновления до Kubernetes 1.37. Однако долгосрочные инфраструктурные проекты должны учитывать направление развития Kubernetes и не инвестировать в устаревающую конфигурацию без необходимости.

Перед обновлением production-кластера желательно проверить текущую конфигурацию kube-proxy, используемый сетевой стек и возможности CNI-плагина.

Что означает Kubernetes 1.37 для администраторов

Для обычного пользователя Kubernetes 1.37 может показаться относительно спокойным обновлением. Большая часть изменений не требует немедленного переписывания манифестов. Но для крупных кластеров новый релиз имеет большое значение.

Перед обновлением стоит проверить несколько направлений:

• используется ли cgroup v1 на рабочих узлах;
• остался ли kube-dns в инфраструктуре;
• используется ли IPVS в kube-proxy;
• есть ли рабочие нагрузки с SELinux;
• используются ли старые версии API для получения метрик;
• готовы ли контроллеры и операторы корректно обрабатывать HTTP 429;
• можно ли использовать HPA scale-to-zero для отдельных приложений;
• требуется ли кластеру DRA для GPU и специализированного оборудования.

Стоит ли переходить на Kubernetes 1.37

Для новых кластеров Kubernetes 1.37 выглядит естественным выбором, поскольку релиз уже находится в активно поддерживаемой ветке. Официальная таблица релизов указывает для серии 1.37 поддержку до августа 2027 года, а завершение жизненного цикла ожидается в октябре 2027 года.

Для production-кластеров обновление лучше выполнять по стандартной процедуре: сначала протестировать новую версию в отдельной среде, затем обновить control plane и после этого постепенно перевести рабочие узлы.

Особое внимание следует уделить не только Kubernetes API, но и CNI, CSI, ingress-контроллерам, операторам, мониторингу и другим компонентам, от которых зависит конкретный кластер.

Kubernetes 1.37 уже доступен. Подробнее см. в официальном объявлении о выпуске и полном списке изменений.

Итоги

Kubernetes 1.37 «Garhwal» — это крупный релиз, в котором разработчики одновременно продвинули несколько давно развивающихся технологий до стабильного уровня. Наиболее заметным изменением стал KYAML, который теперь официально является Stable и может использоваться для более строгого и однозначного представления Kubernetes-конфигураций.

Не менее важен переход metrics.k8s.io в стабильный статус. Вместе с развитием HPA это формирует более зрелую основу для автоматического управления ресурсами.

Для современных вычислительных задач интересны gang scheduling и развитие DRA. Они делают Kubernetes более подходящим для AI, машинного обучения, HPC и кластеров со специализированным оборудованием.

Одновременно Kubernetes продолжает очищать платформу от устаревших компонентов. kube-dns и IPVS постепенно уходят в прошлое, а пользователям рекомендуется переходить на CoreDNS и современные сетевые механизмы. Аналогично продолжается миграция с cgroup v1 на cgroup v2.

Таким образом, Kubernetes 1.37 нельзя назвать исключительно функциональным обновлением. Это еще один шаг к более предсказуемой, безопасной и стандартизированной платформе для управления контейнерными нагрузками.

Часто задаваемые вопросы

Редактор: AndreyEx