Вертикальное масштабирование пода без перезапуска стало возможным начиная с Kubernetes v1.33.
Обычно, если вы хотели выдать приложению (Pod в Kubernetes) больше памяти или CPU, его приходилось перезапускать.
Это ок, если приложение спокойно относится к перезапускам, но есть такие, которым остановки/старты противопоказаны: базы данных, тяжёлые batch-задачи или штуки, которым нужна ровная непрерывная работа.
БетаНовая фича «in-place Pod resize» позволяет менять объём памяти и CPU у Pod, пока он продолжает работать. Начиная с версии 1.33 она считается достаточно зрелой для обычного использования и включена по умолчанию. До этого нужно было включать фича-гейт InPlacePodVerticalScaling.
КакВместо обычного
kubectl edit по Pod используется специальный подресурс
/resize. Например, можно сделать patch так:
kubectl patch pod mypod --subresource=resize ....
Это похоже на то, как устроены другие возможности 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-нагрузки.
Пример:
resizePolicy:
- resourceName: cpu
restartPolicy: NotRequired
- resourceName: memory
restartPolicy: RestartContainer
Источник👉
@GolangPortal
