Kubernetes 1.37 додав HPA до нуля, стійкий watch cache і checkpoint Pod

Kubernetes 1.37 «Garhwal» отримав 67 покращень: 16 можливостей стали стабільними, 23 перейшли у beta, 27 дебютували як alpha, а одна функція була вилучена або позначена застарілою. Серед найпрактичніших змін — стійкіший запуск watch cache, HorizontalPodAutoscaler із масштабуванням до нуля, файлові admission policies, а також перший Pod-рівневий механізм checkpoint і restore.

Watch cache більше не повинен тиснути на etcd під час старту

У 1.37 завершено стабілізацію resilient watch cache initialization. Під час запуску або повторної ініціалізації API server дорогі list/watch запити більше не мають лавиною йти до etcd чи забирати всю місткість API Priority and Fairness. Частину запитів система обробляє у контрольованих межах, а надлишкові може відхиляти з HTTP 429.

Для авторів операторів і контролерів це означає чітку вимогу: клієнт повинен поважати Retry-After, використовувати exponential backoff і не перетворювати тимчасове 429 на нескінченний гарячий retry-loop. Стабільніший control plane не врятує кластер, якщо десятки кастомних контролерів одночасно ігнорують backpressure.

HorizontalPodAutoscaler масштабується до нуля

Підтримка spec.minReplicas: 0 перейшла у beta та ввімкнена за замовчуванням. Вона працює з object або external metrics і підходить для черг, batch jobs та GPU workloads, які можуть не тримати Pod без активної роботи. CPU й memory metrics тут не підтримуються, бо без запущеного Pod немає джерела таких показників.

Коли HPA сам зменшує кількість реплік до нуля, у status з’являється умова ScaledToZero=True. Контролер відрізняє цей стан від ручного вимкнення deployment і може повернути навантаження після появи зовнішнього сигналу. Перед production-використанням потрібно виміряти cold-start, затримку доставки метрики та поведінку під час недоступності metric adapter.

Admission policies можна завантажувати з диска

Manifest-based admission control configuration стала beta. Webhooks і політики на CEL можна завантажити зі статичних manifest-файлів через staticManifestsDir. Такі правила діють із моменту запуску API server, продовжують працювати, коли etcd недоступний, і можуть захищати самі API-ресурси admission control від небажаної зміни.

Це корисно для базових незмінних guardrails, але додає новий канал конфігурації поза Kubernetes API. Файли потрібно версіонувати, доставляти однаково на всі control-plane nodes і перевіряти під час upgrade. Розбіжність manifestів між API servers може створити непередбачуване прийняття або відхилення запитів.

Checkpoint і restore на рівні Pod

У CRI з’явилися alpha RPC CheckpointPod та RestorePod. Вони дозволяють kubelet попросити сумісний container runtime створити checkpoint усього Pod і відновити його. Це лише початкова версія: runtime повинен окремо реалізувати нові RPC, а оператор має врахувати state volumes, мережеву ідентичність, секрети та сумісність ядра.

Alpha означає експеримент: checkpoint/restore не варто вмикати у критичному production лише через наявність API. Спочатку потрібні лабораторні тести на конкретному runtime й аналіз того, які частини стану справді потрапляють у checkpoint.

Що робити розробникам та операторам

• Перевірити custom controllers на коректну реакцію на 429 і Retry-After.
• Для scale-to-zero використовувати метрику, яка існує без активного Pod, та встановити безпечні пороги відновлення.
• Синхронізувати static admission manifests між усіма вузлами control plane.
• Перед оновленням перевірити deprecated API, feature gates і сумісність CNI, CSI та runtime.
• Провести canary-upgrade і порівняти latency API server, навантаження etcd та поведінку autoscaling.

Назва релізу відсилає до гімалайського регіону Garhwal і підкреслює взаємозалежність шарів спільноти. Для production-команд важливішою є практична тема релізу: control plane дедалі краще переживає відновлення, а ресурсоощадні режими стають доступнішими без зовнішніх autoscaler-рішень.

Джерело та права

Матеріал є самостійним українським перекладом-переказом статті Kubernetes v1.37: Garhwal, опублікованої командою релізу 26 серпня 2026 року. Контент офіційного репозиторію сайту Kubernetes поширюється за Creative Commons Attribution 4.0 International. Перекладено, адаптовано, скорочено й доповнено редакцією «Бібліотеки програміста». Обкладинка створена редакцією за допомогою AI та не входить до першоджерела.