Что такое OOM или Out of memory?

Out of Memory (OOM) - это ситуация, когда контейнер или под в Kubernetes пытается использовать больше памяти, чем ему выделено. Когда это происходит, Linux OOM Killer (убийца процессов) вмешивается и завершает процесс, который потребляет слишком много памяти, чтобы защитить стабильность всей системы.

Почему возникает OOM?

1. Неправильное планирование ресурсов:

Заниженные лимиты памяти для контейнеров
Неучет пиковых нагрузок при планировании ресурсов

2. Утечки памяти:

Неосвобождаемые ресурсы в приложениях
Накопление данных в кэше
Неоптимальная работа сборщика мусора

3. Внезапные всплески нагрузки:

Резкое увеличение количества запросов
Обработка больших объемов данных
Параллельное выполнение тяжелых операций

Как обнаружить OOM на мониторинге?

Для обнаружения проблем с памятью в Kubernetes рекомендуется настроить следующие метрики:

1. Метрики контейнеров:

container_memory_usage_bytes
container_memory_working_set_bytes
container_memory_rss

2. Метрики нод:

node_memory_MemAvailable_bytes
node_memory_MemTotal_bytes

3. События Kubernetes:

OOMKilled события
Evicted поды
Failed контейнеры

Научиться находить OOM на графиках

Рекомендиуем настроить алерты:

Использовании памяти у pod на > 80% от лимита
Частых перезапусках подов, особенно по CrashLoopBackOff
Наличии OOMKilled событий в Kuberenetes

Что делать для исправления?

1. Временно увеличить лимиты по памяти (requests, limits), чтобы убрать симптом для дальнейшего анализа:

# deployment.yaml
      ...
      containers:
        - name: application
        ...
        resources: 
          limits:
            cpu: 100m
            memory: 1024Mi
          requests:
            cpu: 100m
            memory: 128Mi

2. Вспомнить, какие изменения случились за последнее время:

Релизы приложения
Проблемы с инфраструктурой
Обновление настроек приложения (лимиты)

3. Изучить потребление памяти pod'ом за последние 7 дней (лучше 14+ дней):

Бывает на графиках видно, что приложение "течет" по памяти
Больше трафика, по сравнению с прошлым интервалом

4. Определив причину, внести изменения в:

Настройки приложения (например, JVM)
Настройки инфраструктуры (например, вынести приложение на более холодную ноду)
Настройки базы данных (например, создать новые индексы под новые запросы)
Настройки масштабирования приложения (HPA (Horizontal Pod Autoscaler), VPA (Vertical Pod Autoscaler)
Архитектурное решение (например, разделить нагрузку на различные компоненты)

5. Настроить алерты и мониторинг, для автоматического отслеживания будущих OOM.