В этом материале
OOMKilled и Evicted требуют разных действий. Первое обычно описывает завершение контейнера из-за нехватки памяти, второе — решение kubelet выселить Pod при давлении на узел. Одного exit code недостаточно: восстановите состояние контейнера, причину Pod и события узла.
OOMKilled и Evicted требуют разных действий. Первое обычно описывает завершение контейнера из-за нехватки памяти, второе — решение kubelet выселить Pod при давлении на узел. Одного exit code недостаточно: восстановите состояние контейнера, причину Pod и события узла.
Сохраните состояние до пересоздания
Получите Pod YAML, describe и события с временными отметками. У контейнера изучите state, lastState, reason, exitCode и restartCount. У Pod сохраните phase и reason. После удаления объекта часть локального контекста уже недоступна, поэтому постоянный рестарт не должен быть первым диагностическим действием. Также запишите nodeName, UID Pod и container ID: одно имя Deployment может последовательно соответствовать нескольким экземплярам с разными причинами остановки.
Найдите уровень принятия решения
При превышении cgroup memory limit ядро может убить процесс. Если завершается основной процесс контейнера, kubelet учитывает restartPolicy. Node-pressure eviction основан на состоянии узла и завершает Pod, после чего контроллер может создать замену. Узел способен столкнуться с OOM раньше, чем kubelet успеет высвободить ресурсы. Поэтому общий текст «не хватило памяти» не определяет, какую границу менять и где искать первичное событие.
Разделите два учебных случая
В первом случае контейнер ограничен 4 GiB, worker увеличивает рабочий набор и получает OOMKilled, а остальные Pod продолжают работу. Во втором контейнер укладывается в свой предел, но node memory.available падает и kubelet сообщает eviction. Число 4 GiB здесь иллюстрирует условие, а не рекомендуемый размер памяти для модели. Для каждого случая нужны независимые подтверждения из событий и учёта памяти.
| Признак | Область исследования |
|---|---|
| OOMKilled в lastState | Память контейнера и журнал ядра |
| Evicted в reason Pod | Сигналы давления и решения kubelet |
| Новый UID на другом узле | Создание замены контроллером |
| Рост restartCount | Перезапуск контейнера в том же 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; memory optimized hosting.