Kubernetes 1.35 Timbernetes: меньше рестартов, больше безопасности

Проект Kubernetes продолжает активно развиваться. В декабре 2025 года была выпущена очередная версия 1.35 под кодовым именем Timbernetes. Релиз включает около 60 изменений: 17 функций получили статус стабильных (stable), 19 находятся в стадии бета и ещё 22 — на этапе альфа. При этом акцент сделан не на количестве новшеств, а на их прикладной ценности: улучшено управление ресурсами, снижены риски простоев, усилены встроенные механизмы безопасности и убраны некоторые устаревшие функции.

Простоев меньше, надежность выше

Ключевое практическое нововведение — возможность обновления ресурсов Pod без перезапуска. Эта опция позволяет динамически изменять выделенные процессорные ресурсы и объём оперативной памяти для уже запущенных Pod без их пересоздания. Ранее любые подобные изменения приводили к удалению Pod и запуску нового экземпляра, что автоматически означало рестарт контейнеров.

Теперь вертикальное масштабирование больше не требует таких остановок и не приводит к прерыванию stateful-нагрузок — приложений, чувствительных к перезапуску (например, базы данных или сервисы с длительными соединениями), — а также batch-нагрузок, то есть пакетных задач вроде аналитических расчётов, ETL-процессов или обучения ML-моделей, для которых рестарт означает потерю прогресса.

Для технических команд это означает переход от «масштабирования через рестарт» к более аккуратной и управляемой модели эксплуатации. Обновление ресурсов Pod без перезапуска — это не просто удобство, но и основа для более сложных сценариев.

В сочетании с Vertical Pod Autoscaler — компонентом Kubernetes, который автоматически подбирает оптимальные значения CPU и памяти на основе реального потребления, — платформа получает возможность адаптироваться к изменяющимся нагрузкам без rollout’ов. Rollout — это поэтапная замена старых Pod на новые, которая формально избегает полного простоя, но всё равно приводит к рестартам контейнеров и кратковременным деградациям, что критично для систем с жёсткими требованиями к SLA.

Заметный прогресс произошёл и в области безопасности. Kubernetes 1.35 развивает нативную идентификацию рабочих нагрузок за счёт сертификатов Pod — kubelet теперь способен автоматически генерировать ключи, запрашивать, монтировать и обновлять сертификаты без использования сторонних решений вроде SPIFFE или cert-manager. Это снижает количество доверенных компонентов в цепочке безопасности и создаёт встроенную основу для mTLS-взаимодействия и zero-trust-архитектур, которые раньше требовали сложных внешних надстроек.

Избавление от легаси

Для операторов кластеров не менее значимым изменением стало то, что в Kubernetes 1.35 полностью удалена поддержка cgroup v1. cgroup — это механизм ядра Linux, отвечающий за ограничение и изоляцию ресурсов процессов. Устаревшая версия cgroup v1 имела разрозненную архитектуру и ограничения, тогда как новая cgroup v2 использует единую иерархию и поддерживает более гибкое, динамическое управление ресурсами. Теперь kubelet требует cgroup v2, а узлы на старых Linux-дистрибутивах без его поддержки больше не смогут работать в составе кластера.

Параллельно версия 1.35 становится последней с поддержкой containerd 1.x. Перед следующим обновлением кластеры необходимо перевести на containerd 2.0 или более новые версии. Также режим ipvs в kube-proxy (компонент, отвечающий за сетевую маршрутизацию трафика к сервисам) объявлен устаревшим. Теперь для Linux рекомендуется использовать nftables, что упрощает сетевой стек.

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