Контейнер с Python-приложением в Kubernetes периодически перезапускается с причиной OOMKilled. Что это означает, и как правильно настроить ограничения ресурсов?

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

OOMKilled означает, что процесс превысил заданный лимит памяти контейнера, и ядро/контейнерная среда принудительно завершила его; решение — определить реальное потребление памяти приложением под нагрузкой через мониторинг и либо увеличить лимит с запасом, либо устранить избыточное потребление.

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

requests задаёт гарантированные ресурсы для планирования пода, а limits — жёсткий потолок; при превышении лимита памяти ядро Linux (через cgroups) убивает процесс немедленно, без возможности корректно освободить ресурсы, в отличие от превышения лимита CPU, которое приводит к троттлингу, а не к убийству процесса.

Пример кода

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

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"   # запас над наблюдаемым p99 потребления под нагрузкой
    cpu: "500m"
# kubectl describe pod <name> покажет:
# Last State: Terminated, Reason: OOMKilled

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

• Практика. Лимит памяти стоит выставлять с запасом поверх наблюдаемого p95/p99 потребления под реальной нагрузкой, а не «на глаз»; для многопроцессных серверов (несколько воркеров Gunicorn в одном контейнере) суммарное потребление растёт с числом воркеров, и лимит должен учитывать их все.

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

• Риск. Ставят limits.memory равным requests без запаса, из-за чего любой временный всплеск нагрузки вызывает перезапуск; не отличают OOMKilled контейнера от обычного исключения MemoryError внутри Python — это разные механизмы (первый уровня ОС/cgroups, второй — уровня интерпретатора).