Команда VK Cloud подготовила перевод обзора релиз-команды Kubernetes (Arsh Sharma, Christopher Tineo, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Troy Connor) из блога kubernetes.io. О том, что устареет, сломается и перейдёт в GA в Kubernetes v1.37, релиз которого запланирован на 26 августа 2026 года. Будет полезен тем, кто эксплуатирует кластеры Kubernetes в проде: DevOps- и SRE-инженерам, платформенным командам, которые планируют обновление.

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

Устаревание и удаление функций в Kubernetes v1.37

Kubectl: kubectl run --filename/-f устареет

Флаг --filename (или -f) для kubectl run признаётся устаревшим, поскольку создаваемый под всегда собирается исключительно из аргументов командной строки, таких как NAME и --image.

Подробности и обсуждение см. в kubernetes/kubernetes#138671.

Kubelet: статические поды больше не могут ссылаться на Secrets и ConfigMaps

Статические поды изначально не должны были напрямую читать ресурсы API, поскольку создаются не через API-сервер, но из-за бага могли ссылаться на Secrets или ConfigMaps через поля вроде configMapRef или secretRef. Этот баг теперь исправлен: начиная с v1.37 такие ссылки строго запрещены, а feature gate PreventStaticPodAPIReferences, который раньше позволял отключить это ограничение, удалён.

Подробности и обсуждение см. в kubernetes/kubernetes#140226.

Устаревание поддержки режима ipvs в kube-proxy

Поддержка режима ipvs в kube-proxy появилась в v1.8 для устранения узких мест производительности iptables. Но одного ядрового API ipvs недостаточно для полной реализации Kubernetes Services, поэтому режим ipvs под капотом по-прежнему использует iptables (KEP-3866, «The ipvs mode of kube-proxy will not save us»).

Кластеры, где kube-proxy работает в режиме ipvs (или mode: ipvs в KubeProxyConfiguration), теперь при старте будут выводить в лог предупреждение об устаревании. График устаревания выглядит так:

• К v1.40 режим ipvs для kube-proxy ожидаемо отключат по умолчанию (но он останется доступен через feature gate).

• К v1.43 поддержку режима ipvs ожидаемо удалят полностью KEP-5495, Graduation Criteria. 

Чтобы узнать, какой режим используется сейчас, выполните:

kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'

Чтобы понять причины этого устаревания, см. KEP-5495: Deprecate ipvs mode in kube-proxy.

Текущие крупные изменения

Будущее удаление поддержки cgroup v1 {#cgroup-v1-support}

Поскольку современные дистрибутивы Linux и контейнерные рантаймы по умолчанию используют cgroup v2, поддержка устаревшей cgroup v1 официально сворачивается. Начиная с релиза v1.35 настройка failCgroupV1 по умолчанию равна true. Как следствие, kubelet не сможет инициализироваться на узлах, которые всё ещё используют cgroup v1, если не задано явное переопределение конфигурации.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false # временное переопределение

Это переопределение стоит рассматривать как временное решение. Продвинутые возможности управления ресурсами, такие как изменение ресурсов пода на лету и Tiered Memory Protection, полностью зависят от cgroup v2. Хотя переопределение остаётся доступным в Kubernetes v1.37, пользователям рекомендуется переходить на cgroup v2, поскольку поддержку cgroup v1 планируется удалить в одном из будущих релизов.

Подробнее об этом устаревании см. в KEP-5573: Remove cgroup v1 support.

Обратно несовместимые изменения в Kubernetes v1.37

Перемаркировка тома SELinux («SELinuxMount») переходит в статус GA {#SELinuxMount-GA}

Ожидается, что SELinuxMount достигнет статуса GA и будет включён по умолчанию в v1.37. Тома будут монтироваться с -o context=<label> (опция монтирования по умолчанию) вместо рекурсивной перемаркировки, но только если CSI-драйвер тома явно включил эту возможность через CSIDriver с .spec seLinuxMount: true.

Поскольку одно монтирование может иметь только один контекст SELinux, поды с разными метками SELinux, которые делят том на одном узле, теперь могут не запуститься. Раньше такие поды сосуществовали благодаря рекурсивной перемаркировке. Чтобы сохранить прежнее рекурсивное поведение для конкретной нагрузки, задайте seLinuxChangePolicy: Recursive в спецификации пода.

На кластерах без включённого SELinux это никак не сказывается. Подробнее см. в материале SELinux Volume Label Changes goes GA (and likely implications in v1.37)

Ключевые улучшения Kubernetes v1.37

Metrics API переходит в статус GA {#metrics-api-ga}

Ожидается, что API metrics.k8s.io перейдёт в статус Stable (GA) в Kubernetes v1.37, проведя в статусе Beta почти девять лет. API предоставляет стандартный способ получения данных об использовании CPU и памяти подами и узлами. На нём строятся широко используемые возможности Kubernetes, такие как Horizontal Pod Autoscaler (HPA) и команды вроде kubectl top.

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

Подробнее об этом улучшении см. в KEP-5207: metrics.k8s.io API definition.

Kubelet в user namespace, также известный как rootless-режим

Традиционно компоненты узла Kubernetes, такие как kubelet, работают на хосте с привилегиями root. Хотя для многих развёртываний это необходимо, такой подход означает, что уязвимость в одном из этих компонентов может сильнее повлиять на базовую систему.

Ожидается, что в Kubernetes v1.37 kubelet в user namespace (rootless-режим) перейдёт в статус Beta. Это улучшение позволяет компонентам узла Kubernetes работать внутри Linux user namespace как непривилегированный пользователь на хосте, оставаясь при этом root внутри самого namespace. Это снижает потребность в привилегиях root на уровне хоста, добавляет дополнительный уровень изоляции и помогает ограничить последствия потенциальных уязвимостей, затрагивающих компоненты узла.

Подробнее об этом улучшении см. в KEP-2033: Kubelet in UserNS(aka Rootless Mode).

Монитор состояния тома

Исторически в Kubernetes не было API, через который CSI-драйверы могли бы сообщать о сбоях хранилища. Такие сбои проявлялись лишь через неудачные монтирования или зависшие операции ввода-вывода. Поскольку remediation-контроллерам не на что было машиночитаемо опереться, единственным способом найти первопричину сбоя было сопоставлять объекты Kubernetes с внешними дашбордами вендоров.

В Kubernetes v1.37 этот KEP возвращает статус повышения на Alpha после первоначальной реализации в v1.21 и добавляет четыре новых CSI RPC. Плагин контроллера сообщает о состоянии томов хранилища через ControllerListVolumeHealth (перечисляет неисправные тома) и ControllerGetVolumeHealth (проверяет конкретный том). Монитор состояния тома⁴ на стороне контроллера опрашивает эти CSI-контроллеры и сохраняет результаты в PersistentVolumeClaim.status.healthStatus.

На стороне узла kubelet вызывает NodeGetVolumeHealth, чтобы получить состояние отдельных томов на этом узле, и записывает его в Pod.status.volumeHealth, а NodeGetStorageHealth сообщает о состоянии драйверов, зарегистрированных на узле, в CSINode.status.storageHealth.

Словарь ошибок остаётся простым, расширяемым и машиночитаемым (Inaccessible, Degraded и т. д.), а дополнительные детали, специфичные для драйвера, доступны через reason и message. Наконец, отчёты на стороне контроллера и на стороне узла остаются независимыми и потому отображаются раздельно, давая потребителям более целостную картину состояния хранилища.

Подробнее об этом улучшении см. в KEP-1432: Volume Health Monitor.

Хотите узнать больше?

Новые функции и устаревания также анонсируются в release notes Kubernetes. Мы официально объявим, что нового в Kubernetes v1.37, в составе CHANGELOG этого релиза.

Релиз Kubernetes v1.37 запланирован на среду, 26 августа 2026 года. Следите за обновлениями!

Анонсы изменений можно посмотреть в release notes для:

• Kubernetes v1.36

• Kubernetes v1.35

• Kubernetes v1.34

• Kubernetes v1.33