Kubernetes 1.37 навчив HPA масштабувати навантаження до нуля

Kubernetes 1.37 переводить масштабування HorizontalPodAutoscaler до нульової кількості реплік у beta та вмикає можливість за замовчуванням. HPA тепер може сам прибрати останній Pod, коли роботи немає, а після появи сигналу з object або external metric знову запустити навантаження. Раніше для такого сценарію зазвичай був потрібен окремий компонент, add-on або експериментальний feature gate.

Де нуль реплік справді економить ресурси

Найочевидніший сценарій — споживачі черг, фонові процесори й batch-задачі, для яких робота може безпечно чекати у надійному сховищі. Якщо кожен Pod резервує окремі CPU, багато пам’яті або GPU, утримувати одну порожню репліку цілодобово дорого. HPA може прибрати її повністю та повернути capacity лише тоді, коли у черзі з’являться завдання.

Це не безкоштовна оптимізація. Після появи роботи контролер має побачити метрику, порахувати потрібну кількість реплік, дочекатися scheduler і старту застосунку. Отже, користувач отримує cold-start delay. Звичайний Kubernetes Service не накопичує HTTP-запити, поки за ним немає готових Pods. Для синхронного вебтрафіку потрібен окремий буфер, gateway або інша архітектура, яка переживе паузу запуску.

Чому CPU та RAM недостатньо

Resource metrics виникають усередині запущених Pods. Коли реплік нуль, вимірювати CPU чи пам’ять нема в кого, а тому немає й сигналу для пробудження. Саме тому конфігурація з minReplicas: 0 повинна мати щонайменше одну object або external metric. API server відхилить HPA, який спирається лише на CPU чи memory.

Зовнішній сигнал існує незалежно від працівників. Наприклад, довжина черги залишається доступною, навіть коли жоден consumer не працює. У прикладі автор використовує метрику queue_consumer_lag, яку Prometheus Adapter публікує через External Metrics API. Перед створенням HPA варто напряму перевірити API метрики: якщо adapter її не повертає, автоматичний запуск із нуля не відбудеться.

Як контролер відрізняє економію від ручної паузи

Нуль реплік має дві різні причини: workload міг зменшити HPA або його міг навмисно зупинити оператор. Kubernetes не повинен самовільно запускати вручну призупинену систему. Для цього в 1.37 контролер використовує status condition ScaledToZero. Коли саме HPA переводить кількість реплік із додатного значення в нуль, він записує ScaledToZero=True і продовжує оцінювати зовнішні сигнали.

Після пробудження condition стає ScaledToZero=False із причиною NotScaledToZero. Якщо ж Deployment має нуль реплік без відповідної умови, HPA трактує стан як ручну паузу. Це можна перевірити командою kubectl describe hpa. Помилка читання метрики відображається як ScalingActive=False, після чого потрібно відновити metrics pipeline або вручну повернути capacity.

Стабілізація та межі

Звичайні правила HPA залишаються чинними. Типове п’ятихвилинне вікно стабілізації зменшення не дає короткому падінню черги миттєво вимкнути всіх workers. Його можна змінити через spec.behavior.scaleDown, але надто коротке значення збільшить кількість cold starts, а надто довге зменшить економію.

У прикладі один worker відповідає тридцяти завданням, а верхня межа становить десять реплік. Це лише модель: реальне співвідношення слід визначати за latency, пропускною здатністю одного Pod і швидкістю накопичення черги. Також потрібно встановити alerts на недоступність external metric та тривале перебування завдань у черзі.

Що перевірити під час оновлення

• Feature gate HPAScaleToZero має бути активним одночасно в kube-apiserver і kube-controller-manager.
• Під час version-skew upgrade не створюйте HPA з нульовим мінімумом, доки обидва компоненти control plane не оновлені.
• Перед downgrade або вимкненням функції змініть minReplicas щонайменше на 1 і вручну запустіть workloads, що вже стоять на нулі.
• Виміряйте cold start образу, доступність metrics adapter та поведінку буфера під піковою чергою.

Практичний висновок: beta-функція добре підходить для асинхронних workers із дорогою останньою реплікою. Для HTTP-сервісів без буферизації та для задач із жорстким latency SLO нуль реплік може коштувати дорожче, ніж постійний мінімум.

Джерело та ліцензія

Матеріал підготовлено за публікацією Johannes Würbach Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler. Контент Kubernetes Website поширюється за Creative Commons Attribution 4.0. Український текст перекладено й адаптовано редакцією з атрибуцією.