Процесс внутри Pod - OOMKilled, хотя пределы Pod не достигнуты

Question

Мы новички во всем мире Kubernetes, но к настоящему моменту в GKE работает ряд сервисов. Сегодня мы наблюдали странное поведение, когда один из процессов, запущенных внутри одного из наших модулей, был убит, даже несмотря на то, что у самого модуля было много доступных ресурсов, и он находился за пределами своих пределов.

Ограниченияопределены следующим образом:

resources:
  requests:
    cpu: 100m
    memory: 500Mi
  limits:
    cpu: 1000m
    memory: 1500Mi

Внутри модуля запущен Celery (Python), и этот конкретный выполняет несколько довольно длительных задач.

Во время работы одного иззадачи, процесс сельдерея был внезапно убит, по-видимому, вызвано ООМ. Журналы операций кластера GKE показывают следующее:

Memory cgroup out of memory: Kill process 613560 (celery) score 1959 or sacrifice child
Killed process 613560 (celery) total-vm:1764532kB, anon-rss:1481176kB, file-rss:13436kB, shmem-rss:0kB

График ресурсов для периода времени выглядит следующим образом:

Как ясно видно, ни процессор, ни использование памяти не приближались к пределам, определенным модулем Pod, поэтому мы озадачены тем, почему произошел какой-либо OOMKilling? Также немного сбит с толку тем фактом, что сам процесс был убит, а не собственно Pod?

Это конкретное OOM действительно происходит внутри ОС, а не в Kubernetes? И если да, то есть ли решение этой конкретной проблемы?

Answer 1

О вашем утверждении:

Также немного сбит с толку тем фактом, что сам процесс был убит, а не действительным модулем?

Вычислить ресурсы (CPU /Память) настроены для контейнеров, а не для модулей.

Если контейнер модуля уничтожен OOM , модуль не исключен . Базовый контейнер перезапускается kubelet на основе его RestartPolicy. Модуль будет по-прежнему существовать на том же узле, и значение Restart Count будет увеличиваться (если вы не используете RestartPolicy: Never, что не соответствует вашему случаю).

Если вы делаете kubectl describe на вашем модуленовый порожденный контейнер будет в состоянии Running, но вы можете найти причину последнего перезапуска в Last State. Кроме того, вы можете проверить , сколько раз он был перезапущен:

State:          Running
  Started:      Wed, 27 Feb 2019 10:29:09 +0000
Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137
  Started:      Wed, 27 Feb 2019 06:27:39 +0000
  Finished:     Wed, 27 Feb 2019 10:29:08 +0000
Restart Count:  5

---

Визуализация графика ресурсов может отличаться от фактического использования памяти. Так как он использует выборку 1 min interval (mean), если ваша память внезапно увеличится сверх верхнего предела, контейнер можно будет перезапустить до того, как ваше среднее использование памяти будет отображено на графике как высокий пик. Если ваш контейнер Python использует короткое / прерывистое высокое потребление памяти, он может быть перезапущен, даже если значения отсутствуют на графике.

С помощью kubectl top вы можете просмотреть последнее использование памяти, зарегистрированное для Pod. Хотя будет более точно видеть использование памяти в определенный момент времени, имейте в виду, что он выбирает значения из metrics-server, которые имеют --metric-resolution:

Интервал, с которого метрики будут извлекаться из Kubelets (по умолчанию 60 с).

Если ваш контейнер использует «остроконечное» использование памяти, вы все равно можете увидеть его перезапуск, даже не видяиспользование памяти на kubectl top.