# OOMKilled или Evicted: как различить две причины остановки Pod

Диагностика: OOMKilled или Evicted: как различить две причины остановки Pod. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/kubernetes-oomkilled-vs-evicted/
Language: ru

OOMKilled и Evicted требуют разных действий. Первое обычно описывает завершение контейнера из-за нехватки памяти, второе — решение kubelet выселить Pod при давлении на узел. Одного exit code недостаточно: восстановите состояние контейнера, причину Pod и события узла.

## Сохраните состояние до пересоздания

Получите Pod YAML, describe и события с временными отметками. У контейнера изучите state, lastState, reason, exitCode и restartCount. У Pod сохраните phase и reason. После удаления объекта часть локального контекста уже недоступна, поэтому постоянный рестарт не должен быть первым диагностическим действием. Также запишите nodeName, UID Pod и container ID: одно имя Deployment может последовательно соответствовать нескольким экземплярам с разными причинами остановки.


[Официальный источник 1](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/).

## Найдите уровень принятия решения

При превышении cgroup memory limit ядро может убить процесс. Если завершается основной процесс контейнера, kubelet учитывает restartPolicy. Node-pressure eviction основан на состоянии узла и завершает Pod, после чего контроллер может создать замену. Узел способен столкнуться с OOM раньше, чем kubelet успеет высвободить ресурсы. Поэтому общий текст «не хватило памяти» не определяет, какую границу менять и где искать первичное событие.


[Официальный источник 2](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).

## Разделите два учебных случая

В первом случае контейнер ограничен 4 GiB, worker увеличивает рабочий набор и получает OOMKilled, а остальные Pod продолжают работу. Во втором контейнер укладывается в свой предел, но node memory.available падает и kubelet сообщает eviction. Число 4 GiB здесь иллюстрирует условие, а не рекомендуемый размер памяти для модели. Для каждого случая нужны независимые подтверждения из событий и учёта памяти.

| Признак | Область исследования |
| --- | --- |
| OOMKilled в lastState | Память контейнера и журнал ядра |
| Evicted в reason Pod | Сигналы давления и решения kubelet |
| Новый UID на другом узле | Создание замены контроллером |
| Рост restartCount | Перезапуск контейнера в том же Pod |


[Официальный источник 3](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/).

## Исправьте соответствующую границу

Для cgroup OOM оцените пик рабочего набора, кеш и memory-backed volumes; проверьте фактический limit. Для eviction исследуйте reservations, requests, соседние workloads и сигналы давления узла. Простое увеличение limit может усилить общий дефицит. Не меняйте QoS ради формального статуса без пересчёта ресурсов. Если причина связана с другой разновидностью pressure, не переносите автоматически выводы о RAM на local storage или PID pressure.

## Проверьте поведение восстановления

Повторите воспроизводимый сценарий в отдельной среде и сохраните, кто создаёт замену: restartPolicy контейнера или workload controller. Убедитесь, что причина остановки сохраняется в журнале наблюдаемости до исчезновения Pod. Критерий исправления включает нормальный повторный запуск и отсутствие прежнего события при сопоставимой нагрузке. Остаточный отчёт должен связывать UID, предел памяти, состояние узла и выбранное действие; так следующий инженер сможет отличить повторение исходной проблемы от нового сбоя.

Связанные разборы: [kubernetes gpu scheduling](/ru/journal/kubernetes-gpu-scheduling/); [memory optimized hosting](/ru/journal/memory-optimized-hosting/).