Kubernetes 1.36: In-Place Pod-Level Resources Vertical Scaling теперь в Beta

В Kubernetes 1.36 функция In-Place Pod-Level Resources Vertical Scaling достигла статуса Beta, что означает её включение по умолчанию через флаг InPlacePodLevelResourcesVerticalScaling. Теперь пользователи могут обновлять агрегированный бюджет ресурсов пода (spec.resources) для уже запущенных подов, часто без перезапуска контейнеров. Это упрощает управление ресурсами в сложных сценариях, таких как поды с сайдкарами, и снижает время простоя при масштабировании.

Что такое Pod-Level Resources и почему это важно

Pod-Level Resources — это модель, при которой ресурсы (CPU и память) задаются на уровне всего пода, а не отдельных контейнеров. Такой подход упрощает управление для сложных подов, особенно тех, что используют сайдкары, поскольку позволяет контейнерам совместно использовать общий пул ресурсов. Ранее, в версии 1.34, эта модель стала Beta, а в 1.35 функция In-Place Pod Vertical Scaling (изменение ресурсов отдельных контейнеров без перезапуска) достигла стабильного статуса. Теперь, в 1.36, эти возможности объединились: можно динамически менять общий бюджет пода без остановки приложений.

Как работает изменение Pod-Level ресурсов на лету?

Когда инициируется изменение на уровне пода, kubelet обрабатывает это как событие изменения для каждого контейнера, который наследует свои лимиты из общего бюджета. Чтобы определить, требуется ли перезапуск, kubelet проверяет параметр resizePolicy внутри каждого контейнера. Если для контейнера установлено NotRequired, kubelet пытается обновить ограничения cgroup динамически через Container Runtime Interface (CRI). Если же установлено RestartContainer, контейнер будет перезапущен для безопасного применения новых границ. Важно отметить, что resizePolicy пока не поддерживается на уровне пода — kubelet всегда ориентируется на настройки отдельных контейнеров. Это означает, что для полного использования возможностей In-Place Scaling необходимо правильно настроить resizePolicy для каждого контейнера.

Как In-Place Pod-Level Resources Vertical Scaling влияет на производительность приложений?

Влияние на производительность минимально, поскольку изменение ресурсов происходит без перезапуска контейнеров в большинстве случаев. Если контейнеры настроены с resizePolicy: NotRequired, kubelet динамически обновляет cgroup, что не прерывает работу приложения. Однако если требуется перезапуск (RestartContainer), возникает кратковременный простой, но он обычно короче, чем полное пересоздание пода. Для критичных приложений рекомендуется сначала тестировать изменения на неосновных нагрузках.

Пример: масштабирование общего пула ресурсов

Рассмотрим под, в котором задан общий лимит CPU в 2 ядра. Если в пиковый момент требуется увеличить производительность, можно изменить pod-level ресурсы, например до 4 ядер. Контейнеры, у которых нет индивидуальных лимитов, автоматически подстроятся под новый размер, что позволяет расширить общий пул без ручного пересчёта для каждого контейнера. Это особенно полезно для приложений с неравномерной нагрузкой, таких как веб-серверы или микросервисы с сайдкарами. Например, если один из контейнеров временно потребляет больше ресурсов, другие могут уступить ему часть общего бюджета, повышая общую эффективность.

Кого затронет нововведение

Разработчики и администраторы Kubernetes, управляющие сложными подами с сайдкарами или микросервисами, получат гибкость в управлении ресурсами без простоев. Бизнес выигрывает от повышения эффективности использования инфраструктуры, так как можно точнее настраивать ресурсы под реальные потребности. Для пользователей, которые уже используют Pod-Level Resources, обновление будет прозрачным, так как функция включена по умолчанию. В российском и СНГ-сегменте, где Kubernetes широко применяется в облачных провайдерах и корпоративных дата-центрах, это упростит автоматическое масштабирование и снизит операционные затраты.

Что будет дальше

Ожидается, что в следующих версиях Kubernetes функция будет доработана: возможно, появится поддержка resizePolicy на уровне пода, а также улучшится интеграция с HPA (Horizontal Pod Autoscaler) и VPA (Vertical Pod Autoscaler). Сообщество также работает над оптимизацией работы с cgroups v2. Пока же пользователям рекомендуется тестировать новую возможность на не критичных нагрузках, чтобы оценить её поведение в своих сценариях.

Итог

In-Place Pod-Level Resources Vertical Scaling в Kubernetes 1.36 — это значительный шаг к более гибкому и эффективному управлению ресурсами. Возможность изменять общий бюджет пода без перезапуска контейнеров снижает время простоя и упрощает эксплуатацию. Следите за обновлениями документации и тестируйте новую функцию в своих кластерах, чтобы подготовиться к её стабильному релизу.