Kubernetes v1.33: Бета-версія масштабування подів з новими покращеннями

Від імені спільноти Kubernetes ми раді оголосити, що функція Вертикального масштабування подів на місці, яка була представлена в alpha версії v1.27, тепер перейшла до стадії Beta у випуску v1.33. Цей важливий етап забезпечить автоматичну можливість вертикального налаштування ресурсів для працюючих подів, пропонуючи більш гнучкий та безперебійний механізм управління виділенням CPU та пам’яті в продуктивних кластерах.

Що таке Вертикальне масштабування подів на місці?

Раніше, щоб оновити запити та ліміти CPU чи пам’яті контейнера, потрібно було видалити та створити новий под, що могло призвести до простоїв, втрати даних або перерв у наданні послуг. Вертикальне масштабування на місці дозволяє змінювати параметри ресурсів на живих подах, часто без перезапуску контейнерного середовища чи порушення роботи додатків.

• Поле spec.containers[*].resources тепер відображає бажану специфікацію ресурсів і може бути змінене для CPU та пам’яті під час виконання.
• Поле status.containerStatuses[*].resources відстежує фактичні ресурси, які надає Kubelet для кожного контейнера.
• Зміна розміру виконується через новий підресурс resize: kubectl edit pod --subresource=resize (потрібна версія kubectl v1.32+).

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

Чому важливо змінювати розмір подів на місці

• Зменшення перерв: Stateful sets, сервіси на базі бази даних та тривалі пакетні завдання можуть адаптувати виділення ресурсів без перезапуску, зберігаючи стан у пам’яті та уникаючи холодних стартів.
• Оптимізація використання ресурсів: Зменште розмір надмірно виділених подів, щоб звільнити потужності кластера. У свою чергу, виділяйте додаткові ресурси CPU або пам’яті в реальному часі для чутливих до затримок навантажень під час пікових запитів.
• Швидка реакція на навантаження: Швидко коригуйте ресурси, наприклад, надаючи Java мікросервісам додатковий CPU під час JIT компіляції, без очікування завершення роботи пода та його повторного планування.

Що змінилося з Alpha до Beta?

З моменту випуску alpha v1.27 команда SIG Node та учасники активно вдосконалювали цю функцію, враховуючи відгуки з виробництва та підвищуючи надійність. Основні покращення включають:

Оновлення для користувачів

• Підресурс resize: Усі оновлення на місці тепер повинні проходити через /pods//resize. Це чітке розмежування покращує контроль RBAC та аудит.
• Умови зміни розміру подів: Поле status.resize застаріло. Дві нові умови пода повідомляють про прогрес:
  
  • PodResizePending: вказує, що Kubelet не може негайно застосувати запит (наприклад, Deferred через тимчасовий тиск на вузол або Infeasible у разі відсутності ресурсів).
  • PodResizeInProgress: сигналізує, що зміна розміру триває, з детальними повідомленнями про помилки в reason: Error у разі виникнення проблем.

• Підтримка контейнерів Sidecar: Тепер вертикальне масштабування поширюється і на sidecar, що дозволяє таким інструментам, як Envoy, Fluentd та кастомні агенти, змінювати ресурси в реальному часі.

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

• Перероблена логіка виділення: Модуль виділення ресурсів Kubelet був рефакторизований для об’єднання відстеження “виділених” та “актуальних” ресурсів, що усуває проблеми гонки та невідповідності драйверів cgroup.
• Надійне збереження стану: Нові контрольні точки на диску (allocated_pods_state, actuated_pods_state) зберігають стан зміни розміру під час перезапуску вузлів. Це вирішує крайні випадки, коли середовища контейнерів повідомляють про різні значення cgroup.
• Швидше виявлення: Покращення генератора подій життєвого циклу подів (PLEG) знижують затримку між оновленням специфікації та дією Kubelet, з показниками, що демонструють до 50% швидше досягнення стабільності на тестових кластерах.
• Інтеграція CRI: Введення виклику UpdatePodSandboxResources CRI покращує співпрацю з плагінами середовища виконання (наприклад, Cilium NRI), що забезпечує миттєве сповіщення плагінів мережі та пристроїв про зміни ресурсів.
• Виправлення помилок: Вирішено десятки проблем, включаючи неправильні обчислення часток CPU з драйверами cgroup systemd, аномалії затримки перезапуску контейнерів та покращену стабільність тестів під час високої конкуренції.

Показники продуктивності та врахування накладних витрат

Попередні випробування від SIG продуктивності Kubernetes вказують на те, що вертикальне масштабування на місці вводить мінімальні накладні витрати. У тестових умовах з частими змінами розміру:

• Середнє використання CPU Kubelet зросло на 2–3%, в основному через записи контрольних точок.
• Накладні витрати на пам’ять на вузол зросли на менше 10 МБ, оскільки нові файли стану залишаються компактними.
• Затримка зміни розміру від kubectl apply до оновлення cgroup в середньому становить 200–300 мс на 16-ядерному вузлі, у порівнянні з 1–2 секундами для відтворення пода.

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

Безпека та врахування RBAC

З введенням підресурсу resize оператори кластерів можуть створювати детальні політики RBAC:

• Створювати окремі ролі, які дозволяють користувачам patch або update лише підресурс resize, запобігаючи несанкціонованим змінам специфікацій.
• Аудиторські журнали будуть чітко фіксувати операції PATCH /pods//resize, спрощуючи відстеження відповідності.
• Політики безпеки подів (PSA) можуть забезпечити, що лише певні надійні простори імен або облікові записи служб можуть виконувати вертикальне масштабування, зменшуючи зону ризику від неправильних налаштувань.

Інтеграція з дорожньою картою Vertical Pod Autoscaler

Команда Autoscaling SIG Kubernetes працює над тим, щоб Vertical Pod Autoscaler (VPA) міг нативно використовувати масштабування на місці. Майбутні KEP пропонують новий режим оновлення InPlaceOrRecreate, де VPA:

• Спробує спочатку здійснити безперебійне масштабування на місці.
• Повернеться до відтворення пода, коли живе оновлення буде неможливим (наприклад, зменшення пам’яті за межі системних лімітів).

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

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

“Перехід вертикального масштабування на місці до стадії Beta — це величезний крок вперед для управління ресурсами Kubernetes”, — говорить Келсі Хайтовер, головний адвокат розробників у Google Cloud. “Це з’єднує горизонтальне та вертикальне масштабування, надаючи операторам найкраще з обох світів.”

Згідно з Джанет Куо, старшим архітектором хмарних технологій у Red Hat: “З надійним збереженням стану та інтеграцією CRI ми тепер можемо впевнено запускати критично важливі бази даних на Kubernetes з мінімальними перервами під час подій масштабування.”

Що далі?

• Усталенність у виробництві: Продовження фокусування на налаштуванні продуктивності, стабільності під навантаженням та зменшенні крайніх випадків збоїв у великих кластерах.
• Послаблення обмежень: Пункти дорожньої карти включають підтримку зменшення лімітів пам’яті на місці та розширення коригувань часток CPU у cgroup v2.
• Підтримка постачальників хмарних послуг: AWS EKS, GCP GKE та Azure AKS оголосили про попередні плани впровадження цієї функції у своїх керованих пропозиціях до третього кварталу 2024 року.
• Відгуки користувачів: Запрошуємо вас повідомляти про проблеми, ділитися історіями успіху та пропонувати покращення через GitHub, списки розсилки SIG Node та #sig-node у Kubernetes Slack.

Як почати та зробити внесок

З функцією InPlacePodVerticalScaling, увімкненою за замовчуванням у v1.33, ви можете почати експериментувати вже сьогодні:

kubectl edit pod  --subresource=resize

Ознайомтеся з офіційною документацією для прикладів і перегляньте KEP-1287 для отримання повних деталей дизайну. Ваші внески та відгуки є критично важливими, оскільки ми рухаємося до загального доступу та ширшої інтеграції в екосистему.

Ми з нетерпінням чекаємо, як ви використаєте цю функцію для створення більш чутливих, економічно ефективних і стійких робочих навантажень у Kubernetes!

Джерело: Блог Kubernetes