TGViewer
DevOps Portal | Linux DevOps Portal | Linux @loose_code · 13.1K subscribers
Post #1349 4.19K

Forwarded from Golang Portal

Вертикальное масштабирование пода без перезапуска стало возможным начиная с 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
  • ❤ 10
  • 👍 2
More from @loose_code
  1. Oct 1, 202622 октября встречаемся в Москве: Kuber Conf уже совсем скоро! Что будет на конференции: –…
  2. Oct 1, 2026Обработка миллионов файлов – это та точка, где большинство распределённых систем хранения…
  3. Oct 1, 2026Планы на 3 октября — прийти на RWB Infra x Security Meetup Мы направим прожекторы на инфра…
  4. Oct 1, 2026Docker 101: Как достучаться до контейнера без проброса порта Знали, что IP-адрес контейнер…
  5. Sep 30, 2026В этой статье разбирается, как спроектировать production-ready MCP-сервер для платформенны…
  6. Sep 30, 2026В этой статье объясняется, почему Ingress заменяют на Gateway API, за что на самом деле от…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →