Что произойдёт, если не указать requests и limits для контейнера, и зачем они вообще нужны?

Короткий ответ

Без requests/limits планировщик не знает, сколько ресурсов резервировать для Pod, и под получает низший приоритет QoS (BestEffort) — он будет выселен первым при нехватке ресурсов на узле и может бесконтрольно потреблять CPU и память, мешая соседним подам.

Как это работает подробнее

requests — это объём ресурсов, который планировщик резервирует для Pod при выборе узла; limits — верхняя граница, которую контейнер не может превысить (для CPU — через throttling, для памяти — через убийство процесса, OOMKilled). Если не задать ни то, ни другое, под может занять сколько угодно свободных ресурсов узла, пока их хватает.

Пример кода

manifest.yamlКопировать

resources:
  requests: { cpu: "250m", memory: "256Mi" }
  limits: { cpu: "500m", memory: "512Mi" }

Что использовать на практике

• Практика. для предсказуемой работы прод-нагрузки желательно явно задавать и requests, и limits, ориентируясь на реальное потребление приложения под нагрузкой (через мониторинг), а не на произвольные числа. Слишком заниженные requests ведут к избыточному размещению подов на узле и конкуренции за ресурсы; слишком высокие — к неэффективному использованию кластера.

Подводные камни

• Риски. указывать limits без requests (Kubernetes в части версий автоматически приравнивает requests к limits, что может неожиданно повлиять на планирование); ставить лимит памяти намного ниже реального пикового потребления, что приводит к регулярным OOMKilled; не пересматривать значения после изменения нагрузки на сервис.