Kubernetes 1.35: оновлення ресурсів Pod без перезапуску та підготовка до containerd 2.0

Kubernetes 1.35 вийшов 17 грудня 2025 року з 60 покращеннями. Для експлуатаційних команд найпомітніші зміни стосуються оновлення ресурсів Pod без перезапуску, стабільнішої поведінки під час рестарту kubelet і підготовки до завершення підтримки containerd 1.x.

Зміна ресурсів Pod стала стабільною можливістю

In-place update of Pod resources досягла статусу GA. CPU та пам’ять контейнерів можна коригувати без повного пересоздання Pod, якщо це дозволяють політики ресурсу й конкретна зміна. Це особливо корисно для довгих обчислень, stateful-навантажень і сервісів, де перезапуск має помітну ціну.

In-place не означає безумовно безперервно

Команда повинна перевіряти статус resize, підтримку середовища виконання та поведінку застосунку. Зменшення пам’яті може конфліктувати з фактичним споживанням, а зміна лімітів CPU — вплинути на затримку. Автоматизації мають чекати підтвердження нового стану, а не вважати успіхом сам запис у API.

Рестарт kubelet менше впливає на готовність

У 1.35 стабілізовано відновлення стану контейнерів після перезапуску kubelet. Здорові контейнери не повинні тимчасово ставати NotReady лише через технічний рестарт агента вузла. Це зменшує випадкове вилучення Pod із балансувальників під час обслуговування, але не замінює PodDisruptionBudget і перевірку readiness probes.

containerd 1.x наближається до межі підтримки

Kubernetes 1.35 є останнім випуском із підтримкою гілки containerd 1.x. Перед наступним оновленням вузли треба перевести на containerd 2.0 або новіший. Метрика kubelet, що сигналізує про втрату підтримки CRI, допомагає знайти непідготовлені вузли, але версію runtime варто також перевіряти в інвентаризації кластера.

План міграції має охоплювати весь вузол

• перевірте сумісність Kubernetes, containerd і ОС;
• протестуйте конфігурацію registry mirrors та приватних реєстрів;
• звірте параметри cgroup і systemd;
• перевірте CSI, CNI, GPU-плагіни та засоби безпеки;
• оновлюйте канаркову групу вузлів до основного пулу;
• підготуйте повернення образу вузла, а не ручне виправлення.

Не вмикайте alpha-функції без окремої оцінки

Restart All Containers у Pod з’явився як alpha-можливість за feature gate. Він може бути корисним для AI/ML-завдань і керованого відновлення, але його API та поведінка ще можуть змінитися. Для виробничого середовища потрібні окремий тестовий кластер, чіткий сценарій відмови й спостереження за станом.

Оновлення починається з залежностей

Перед переходом звірте матрицю підтримки керованого провайдера, ingress-контролера, autoscaler, admission webhooks і операторів. Матеріал TechPulse про міграцію з Ingress на Gateway API допоможе відокремити мережеву модернізацію від оновлення ядра. Стаття про сигнали витрат Kubernetes пояснює, які метрики варто зберегти до зміни ресурсів.

Першоджерело: офіційний огляд Kubernetes 1.35.