Kubernetes 1.35: Зміна розміру Podʼа на місці переходить у стабільний стан

Автор Natasha Sarkar (Google) | Перекладач(і) Андрій Головін |

Цей випуск є важливим кроком: через понад 6 років після його первинної концепції можливість In-Place Pod Resize (також відома як In-Place Pod Vertical Scaling), вперше представлена як альфа-версія в Kubernetes v1.27 і переведена в бета-версію в Kubernetes v1.33, тепер є стабільною (GA) в Kubernetes 1.35!

Цей перехід є важливою віхою для підвищення ефективності використання ресурсів та гнучкості робочих навантажень, що виконуються на Kubernetes.

Що таке In-Place Pod Resize?

У минулому CPU та памʼять, виділені для контейнера в Podʼі, були незмінними. Це означало, що зміна цих ресурсів вимагала видалення та повторного створення всього Podʼа. Для сервісів зі станом, пакетних завдань або робочих навантажень з високою чутливістю до затримки це була надзвичайно руйнівна операція.

In-Place Pod Resize робить запити та обмеження CPU і памʼяті змінними, дозволяючи вам налаштовувати ці ресурси всередині запущеного Podʼа, часто без необхідності перезапуску контейнера.

Ключова концепція:

  • Бажані ресурси: Поле spec.containers[*].resources контейнера тепер представляє бажані ресурси. Для CPU та памʼяті ці поля тепер змінні.
  • Фактичні ресурси: Поле status.containerStatuses[*].resources відображає ресурси, що наразі налаштовані для запущеного контейнера.
  • Ініціювання зміни розміру: Ви можете запросити зміну розміру, оновивши бажані requests і limits у специфікації Podʼа, використовуючи новий підресурс resize.

Як почати використовувати In-Place Pod Resize?

Докладні інструкції та приклади надані в офіційній документації: Зміна розміру ресурсів CPU та памʼяті, призначених контейнерам.

Як це допоможе мені?

In-place Pod Resize є основою для безперебійного вертикального автомасштабування та покращення ефективності робочих навантажень.

  • Ресурси, що коригуються без порушень Ресурси робочих навантажень, чутливих до затримок або перезапусків, можуть бути змінені на місці без простоїв або втрати стану.
  • Більш потужне автоматичне масштабування Автомасштабувальники тепер мають можливість коригувати ресурси з меншим впливом. Наприклад, режим оновлення InPlaceOrRecreate Vertical Pod Autoscaler (VPA), який використовує цю можливість, перейшов у бета. Це дозволяє автоматично та безперебійно коригувати ресурси на основі використання з мінімальними порушеннями.
    • Див. AEP-4016 для отримання додаткової інформації.
  • Задоволення тимчасових потреб у ресурсах Робочі навантаження, які тимчасово потребують більше ресурсів, можна швидко налаштувати. Це дозволяє використовувати такі можливості, як CPU Startup Boost (AEP-7862), за допомогою якої застосунки можуть запитувати більше CPU під час запуску, а потім автоматично зменшувати їх.

Ось кілька прикладів використання:

  • Ігровий сервер, який потребує коригування розміру відповідно до кількості гравців.
  • Попередньо підігрітий робочий процес, який можна зменшити, коли він не використовується, але збільшити при першому запиті.
  • Динамічне масштабування залежно від навантаження для ефективного пакування контейнерів.
  • Збільшення ресурсів для JIT-компіляції під час запуску.

Зміни між бета-версією (1.33) та стабільною версією (1.35)

З моменту випуску першої бета-версії v1.33 розробники зосередилися на стабілізації можливості та поліпшенні її зручності використання на основі відгуків спільноти. Ось основні зміни в стабільній версії:

  • Зменшення обмеження памʼяті Раніше зменшення обмежень памʼяті було заборонено. Це обмеження було знято, і тепер зменшення обмежень памʼяті дозволено. Kubelet намагається запобігти OOM-kills, дозволяючи зміну розміру тільки в тому випадку, якщо поточне використання памʼяті нижче нового бажаного обмеження. Однак ця перевірка виконується за принципом best-effort і нічого не гарантує.
  • Зміна розміру за пріоритетом Якщо вузол не має достатньо місця для прийняття всіх запитів на зміну розміру, зміни розміру у стані Deferred повторюються на основі такого пріоритету:
    • PriorityClass
    • Клас QoS
    • Тривалість перебування у стані Deferred, причому старіші запити мають пріоритет.
  • Ресурси на рівні Podʼа (альфа) Підтримку зміни розміру Podʼа на місці з використанням ресурсів на рівні Podʼа впроваджено під окремою функціональною можливістю, яка у v1.35 має статус альфа.
  • Підвищена спостережуваність: Тепер є нові метрики Kubelet та події Podʼа, які спеціально повʼязані зі зміною розміру Podʼа на місці, щоб допомогти користувачам відстежувати та налагоджувати зміни ресурсів.

Що далі?

Перехід In-Place Pod Resize до стабільної версії відкриває можливості для потужної інтеграції в екосистемі Kubernetes. Наразі планується подальше вдосконалення в декількох напрямках.

Інтеграція з автомасштабувальниками та іншими проєктами

Планується інтеграція з декількома автомасштабувальниками та іншими проєктами для підвищення ефективності робочого навантаження в більшому масштабі. Деякі проєкти, що обговорюються:

  • Прискорення запуску VPA CPU (AEP-7862): Дозволяє застосункам запитувати більше ресурсів CPU під час запуску та зменшувати їх після певного періоду часу.
  • Підтримка VPA для оновлень на місці (AEP-4016): Підтримка VPA для InPlaceOrRecreate нещодавно перейшла в бета-версію, а кінцевою метою є переведення можливості в стабільну версію. Підтримка режиму InPlace все ще знаходиться в стадії розробки; див. PR #8818.
  • Автомасштабування Ray: планується використовувати можливість In-Place Pod Resize для підвищення ефективності робочого навантаження. Дивіться цю публікацію в блозі Google Cloud для отримання додаткової інформації.
  • Agent-sandbox «Soft-Pause»: Дослідження можливості використання In-Place Pod Resize для покращення затримки. Детальніше див. Github issue.
  • Підтримка середовища виконання: середовища виконання Java та Python не підтримують зміну розміру памʼяті без перезапуску. Триває відкрита дискусія з розробниками Java, див. помилку.

Якщо у вас є проєкт, який може виграти від інтеграції з можливістю зміни розміру Podʼа на місці, зверніться до нас, скориставшись каналами, зазначеними в розділі зворотного звʼязку!

Розширення функціональних можливостей

Наразі можливість In-Place Pod Resize заборонена при використанні в поєднанні з: swap, статичним менеджером CPU та статичним менеджером памʼяті. Крім того, ресурси, крім CPU та памʼяті, залишаються незмінними. Розширення набору підтримуваних можливостей та ресурсів розглядається в міру надходження відгуків про потреби спільноти.

Також планується підтримка витіснення робочих навантажень; якщо на вузлі недостатньо місця для зміни розміру Podʼа з високим пріоритетом, метою є надання можливості політикам автоматично виселяти Pod з нижчим пріоритетом або збільшувати розмір вузла.

Покращена стабільність

  • Усунення станів гонитви між kubelet і планувальником Відомі стани гонитви між kubelet і планувальником щодо зміни розміру Podʼа на місці. Ведуться роботи з вирішення цих проблем у наступних версіях. Дивіться проблему для більш детальної інформації.

  • Більш безпечне зменшення обмеження памʼяті Перевірку Kubelet за принципом best-effort для запобігання OOM-kill можна зробити ще безпечнішою, перемістивши перевірку використання памʼяті в саме середовище виконання контейнерів. Дивіться тікет для більш детальної інформації.

Надання відгуків

З метою подальшого розвитку цієї базової можливості, будь ласка, поділіться своїми відгуками щодо її вдосконалення та розширення. Ви можете поділитися своїми відгуками через GitHub issues, списки розсилки або канали Slack, повʼязані зі спільнотами Kubernetes #sig-node та #sig-autoscaling.

Дякуємо всім, хто долучився до реалізації цієї довгоочікуваної можливості!

Змінено November 03, 2026 at 6:52 PM PST: [uk] Add blog posts ippr-goes-ga, kubelet-config-drop-in-directory-ga and ensure-secret-pulled-images (15146984ed)