Kubernetes 1.35 уже вышел, и главный смысл релиза не в «косметике», а в чистке старого стека. Команда проекта убрала поддержку cgroup v1, пометила режим IPVS в kube-proxy как устаревающий и прямо предупредила: Kubernetes 1.35 — последний релиз с поддержкой containerd 1.x.
Для команд, которые обновляют кластеры раз в год и живут по инструкциям двухлетней давности, это тот самый случай, когда апгрейд лучше проверить заранее, а не в ночь релиза.
Что в релизе действительно меняется
Главная техническая перемена — удаление поддержки cgroup v1. Kubernetes стабильно поддерживает cgroup v2 с версии 1.25, а в 1.35 старый режим окончательно уходит. Если узел работает на Linux-дистрибутиве без cgroup v2, kubelet на нем просто не запустится.
Вторая заметная история касается kube-proxy. Режим IPVS в Kubernetes 1.35 не удалили, но официально признали устаревающим. Причина прозаичная: поддерживать паритет между IPVS и другими режимами стало слишком дорого, а рекомендуемой заменой для Linux-узлов проект называет nftables.
Третье изменение касается containerd. Релиз 1.35 остается последним, где Kubernetes еще поддерживает ветку containerd 1.x. Перед следующим обновлением разработчики советуют перейти на containerd 2.0 или новее.
Какие ошибки были в исходном тексте
В черновике смешали изменения из разных версий Kubernetes. Утверждение про Kubernetes 1.37 не подтверждается: официальных анонсов с таким набором изменений у проекта нет. Описанные удаление cgroup v1 и устаревание IPVS относятся к Kubernetes 1.35, а не к 1.37.
Фраза про запрет ссылок на Secrets и ConfigMaps в статических подах тоже некорректна. Это не новшество 1.35: статические поды давно не должны ссылаться на объекты API вроде Secret и ConfigMap. То же касается флага --filename в kubectl run — его устаревание обсуждали еще в более ранних релизах, а не в 1.35.
Наконец, сроки «отключат в 1.40, удалят в 1.43» в исходнике приписаны IPVS, но такая логика в официальных материалах связана с другой функцией — Service.spec.externalIPs из Kubernetes 1.36. Для IPVS в 1.35 проект говорит об устаревании и рекомендуемой миграции на nftables, без таких дат в релизной заметке.
Что проверить администраторам и DevOps-командам
Если у вас on-prem-кластер или старые виртуальные машины, первым делом проверьте, включен ли cgroup v2 на узлах. Второй пункт — конфигурация kube-proxy: если в старом шаблоне или kubeadm-конфиге еще стоит IPVS, пора планировать переход на nftables. Третий — версия containerd: ветка 1.7 еще работает с Kubernetes 1.35, но это уже финальное предупреждение перед миграцией.
Для российского рынка это особенно актуально там, где кластеры живут долго и обновляются осторожно: в банках, телекоме, интеграторах и внутренних платформах крупных компаний. Иначе говоря, релиз бьет не по «зеленым» проектам, а по тем, которые годами считались стабильными просто потому, что их боялись трогать.
Значение для рынка
Kubernetes последовательно вычищает исторические компромиссы и подталкивает инфраструктуру к более современному Linux-стеку. Для бизнеса это означает простую вещь: стоимость «ничего не менять» растет. Чем старше кластер и чем больше в нем ручных настроек, тем дороже окажется следующий апгрейд.
Следующий практический шаг очевиден: перед обновлением до следующих веток Kubernetes стоит провести аудит рантайма, режима kube-proxy и параметров ядра на узлах, чтобы релиз не превратился в инцидент.
Источник: официальный анонс изменений Kubernetes v1.35. Дополнительно: релиз Kubernetes 1.35 и документация по режимам kube-proxy.