Что произойдет с контейнером, если будет превышен лимит по памяти?

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

При превышении лимита памяти контейнер будет аварийно завершен (OOMKilled) системным демоном oom-killer. Процесс в контейнере получит сигнал SIGKILL (9), и контейнер перейдет в статус Exited с кодом ошибки 137 (128 + SIGKILL=9).

Подробный механизм работы OOM в контейнерах

1. Настройка лимитов памяти

В Docker/Kubernetes лимиты памяти задаются через:

• docker run --memory или --memory-swap
• В Kubernetes через resources.limits.memory в манифесте pod

# Пример манифеста Kubernetes
apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      limits:
        memory: "200Mi"  # Лимит памяти
      requests:
        memory: "100Mi"  # Гарантированная память
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]

2. Иерархия контроля памяти (cgroups)

Лимиты памяти в Linux контейнерах реализуются через подсистему memory cgroups v1/v2:

# Проверка лимитов cgroup для контейнера
docker run -d --name test-mem --memory 200m alpine sleep 3600
docker inspect test-mem | grep -i memory

# Или через cgroup напрямую
cat /sys/fs/cgroup/memory/docker/<container_id>/memory.limit_in_bytes

3. Последовательность событий при OOM

1. Потребление памяти достигает лимита

   • Контейнер пытается выделить больше памяти, чем разрешено лимитом
   • Ядро Linux активирует механизм OOM (Out Of Memory)

2. Выбор "жертвы" (oom_killer)

   • Демон oom-killer вычисляет "плохость" процесса по формуле:

     badness = (memory_usage * 1000) / memory_limit
     

   • Для контейнеризованных процессов учитывается иерархия cgroups
   • Процесс с наибольшим показателем "плохости" выбирается для уничтожения

3. Сигнал SIGKILL

   • Выбранному процессу отправляется сигнал SIGKILL (9)
   • Процесс не может перехватить или игнорировать этот сигнал
   • Контейнер аварийно завершается

4. Мониторинг и диагностика

Проверка статуса контейнера:

# Docker
docker ps -a --filter "status=exited"
docker inspect <container_id> --format='{{.State.OOMKilled}} {{.State.ExitCode}}'

# Kubernetes
kubectl get pods
kubectl describe pod <pod_name> | grep -A 5 -i "state"
kubectl get events --field-selector involvedObject.name=<pod_name>

Логи и метрики:

# Просмотр логов ядра (OOM events)
dmesg | grep -i "oom\|kill"

# Метрики cgroup
cat /sys/fs/cgroup/memory/docker/<container_id>/memory.oom_control
cat /sys/fs/cgroup/memory/docker/<container_id>/memory.max_usage_in_bytes

5. Практические последствия и стратегии

Типичные проблемы:

• Потеря данных: Несохраненные данные в памяти исчезают
• Нарушение работы приложения: Особенно критично для stateful-сервисов
• Каскадные сбои: В микросервисной архитектуре может вызвать цепную реакцию

Профилактические меры:

А) Мониторинг и алертинг

# Prometheus правила для алертов
groups:
- name: memory_alerts
  rules:
  - alert: ContainerMemoryNearLimit
    expr: (container_memory_working_set_bytes / container_spec_memory_limit_bytes) > 0.8
    for: 5m
    labels:
      severity: warning
    annotations:
      description: 'Container {{ $labels.container }} memory usage >80%'

Б) Правильная настройка лимитов

• Всегда устанавливайте requests и limits в Kubernetes
• Используйте мониторинг потребления для реалистичных лимитов
• Настройте swap (с осторожностью, может маскировать проблемы)

В) Техники разработки приложений

# Пример graceful degradation при нехватке памяти
import resource
import signal
import sys

def handle_memory_warning(signum, frame):
    """Обработчик сигнала перед OOM"""
    # Сброс кешей, сохранение состояния
    cleanup_cache()
    save_state()
    sys.stderr.write("WARNING: Approaching memory limit\n")

# Установка обработчика SIGUSR1 (может использоваться для предупреждения)
signal.signal(signal.SIGUSR1, handle_memory_warning)

# Установка мягкого лимита (для предупреждения)
soft_limit = int(resource.getrlimit(resource.RLIMIT_AS)[0] * 0.9)
resource.setrlimit(resource.RLIMIT_AS, (soft_limit, hard_limit))

Г) Инфраструктурные решения

• Horizontal Pod Autoscaler в Kubernetes для автомасштабирования
• Регулярное тестирование на устойчивость (Chaos Engineering)
• Использование памяти с учетом кеширования (working_set vs rss)

6. Особые сценарии

Своп (swap) в контейнерах:

# Docker с swap
docker run --memory 100m --memory-swap 200m ...

# Kubernetes (требует включения swap на узле)
# Важно: swap может привести к деградации производительности

OOM в Kubernetes с несколькими контейнерами:

• Если в pod несколько контейнеров, убивается только нарушивший лимит
• Политики QoS (Quality of Service) влияют на приоритет убийства:
  • Guaranteed (requests == limits) - низкий приоритет для OOM
  • Burstable (requests < limits) - средний приоритет
  • BestEffort (без limits) - высокий приоритет

7. Отладка и анализ

Профилирование потребления памяти:

# Профилирование heap в Java приложениях
kubectl exec <pod> -- jmap -heap 1

# Анализ памяти Go приложений
kubectl exec <pod> -- curl http://localhost:6060/debug/pprof/heap?debug=1

# Инструменты для Docker
docker stats
docker run --rm -it --pid=container:<container_id> alpine htop

Вывод

Превышение лимита памяти приводит к немедленному завершению контейнера через механизм OOM-killer. Для предотвращения таких ситуаций необходимы:

1. Адекватные лимиты, основанные на мониторинге
2. Graceful degradation в приложениях
3. Многоуровневый мониторинг с алертингом
4. Регулярное нагрузочное тестирование
5. Инфраструктурные механизмы автомасштабирования

Правильная обработка сценариев нехватки памяти — критически важный аспект надежности контейнеризованных приложений в продакшен-средах.