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 — це не стільки радикальна зміна, скільки етап еволюційного розвитку платформи, який, з одного боку, впроваджує нові можливості, усуває старі помилки та підвищує рівень безпеки, а з іншого — закладає архітектурну основу для майбутніх масштабних оновлень.