Kubernetes v1.33: Вертикальное масштабирование пода без перезапуска

Вертикальное масштабирование пода без перезапуска стало возможным начиная с Kubernetes v1.33. Если вы хотели выдать приложению (Pod в Kubernetes) больше памяти или CPU, его приходилось перезапускать. Это ок, если приложение спокойно относится к перезапускам, но есть такие, которым остановки/старты противопоказаны: базы данных, тяжёлые batch-задачи или штуки, которым нужна ровная непрерывная работа.

Новая фича «in-place Pod resize» позволяет менять объём памяти и CPU у Pod, пока он продолжает работать. Начиная с версии 1.33 она считается достаточно зрелой для обычного использования и включена по умолчанию. До этого нужно было включать фича-гейт InPlacePodVerticalScaling.

Как

Вместо обычного kubectl edit по Pod используется специальный подресурс /resize. Например, можно сделать patch так:

Это похоже на то, как устроены другие возможности Kubernetes. Например:

🔹/status — подресурс, которым можно обновлять только поле status объекта, не трогая его spec.

🔹/scale — подресурс у Deployment или StatefulSet, позволяющий менять количество реплик без редактирования всего манифеста.

Аналогично, /resize — подресурс у Pod, который позволяет менять ресурсы на месте.

Важно: это применяется к отдельным Pod. Если запустить kubectl set resources на Deployment, StatefulSet или Job, это всё равно поменяет шаблон и породит новые Pod, а не сделает in-place изменение.

Увеличивать CPU просто, увеличение памяти обычно проходит, если на узле есть свободная ёмкость. Уменьшать CPU тоже легко, а вот уменьшение памяти — самый сложный кейс и может провалиться, быть отложено или потребовать перезапуск в зависимости от политики. Чтобы понимать, как идёт процесс, следите за полями status и conditions у Pod.

Политика ресайза

Каждый контейнер в спецификации Pod может задать resizePolicy. Внутри этого поля CPU и память перечисляются отдельно, и для каждого выбирается политика перезапуска. Доступны два значения:

🔹NotRequired: Kubernetes попытается изменить значения ресурсов на месте, пока контейнер работает. Это значение по умолчанию. Это best-effort: если рантайм не может безопасно применить изменение (особенно при уменьшении памяти), операция завершится ошибкой вместо принудительного перезапуска.

🔹RestartContainer: чтобы применить новые настройки ресурсов, Kubernetes обязан перезапустить контейнер. Полезно для приложений, которые читают лимиты ресурсов только при старте, например некоторые JVM-нагрузки.