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ʼа. Для stateful сервісів, batch завдань або робочих навантажень з високою чутливістю до затримки це було надзвичайно деструктивна операція.

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

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

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

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

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

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

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

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

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

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

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

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

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

Що далі?

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

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

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

  • Прискорення запуску VPA CPU (AEP-7862): Дозволяє застосункам запитувати більше ресурсів CPU під час запуску та зменшувати їх після певного періоду часу.
  • Підтримка VPA для оновлень на місці ([AEP-4016] (https://github.com/kubernetes/autoscaler/tree/455d29039bf6b1eb9f784f498f28769a8698bc21/vertical-pod-autoscaler/enhancements/4016-in-place-updates-support)): Підтримка VPA для InPlaceOrRecreate нещодавно перейшла в бета-версію, а кінцевою метою є переведення функції в стабільну версію. Підтримка режиму InPlace все ще знаходиться в стадії розробки; див. PR #8818.
  • Автомасштабування Ray: планується використовувати функцію In-Place Pod Resize для підвищення ефективності робочого навантаження. Дивіться цю публікацію в блозі Google Cloud для отримання додаткової інформації.
  • Агент-пісочниця «Soft-Pause»: Дослідження можливості використання функції Pod Resize для покращення затримки. Детальніше див. Github issue.
  • Підтримка середовища виконання: середовища виконання Java та Python не підтримують зміну розміру памʼяті без перезапуску. Триває відкрита дискусія з розробниками Java, див. помилку.

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

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

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

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

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

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

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

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

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

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