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

Последствия зависят от того, какой ресурс превышен и как заданы ограничения в манифесте Pod.

1. Превышение лимита CPU (limits.cpu):

• Контейнер не будет завершен.
• Ядро Linux (через механизм cgroups) начнет "троттлировать" (throttle) процессы контейнера, ограничивая им время CPU.
• Это приведет к увеличению latency и снижению производительности приложения, что может выглядеть как "подвисание".
• В метриках (например, из cAdvisor) будет виден throttling_time.

2. Превышение лимита памяти (limits.memory):

• Контейнер будет принудительно завершен ядром с событием OOMKilled (Out Of Memory).
• Kubernetes перезапустит Pod согласно его политике restartPolicy (например, Always).
• В событиях кластера можно увидеть:

     kubectl describe pod <pod-name>
     # В секции Events будет: 'OOMKilled'

Пример манифеста с корректными requests и limits:

apiVersion: v1
kind: Pod
metadata:
  name: example-app
spec:
  containers:
  - name: app
    image: nginx:alpine
    resources:
      requests:  # Гарантированно выделяемые ресурсы
        memory: "256Mi"
        cpu: "250m"
      limits:    # Жесткий верхний предел
        memory: "512Mi"
        cpu: "500m"

Практические рекомендации:

• CPU — сжимаемый ресурс. Установка limits близких к requests может привести к троттлингу под нагрузкой. Часто limits.cpu делают в 1.5-2 раза выше requests.cpu.
• Память — несжимаемый ресурс. Превышение лимита ведет к падению. Значение limits.memory должно быть основано на нагрузочном тестировании с запасом.
• Всегда настраивайте Liveness и Readiness пробы, чтобы Kubernetes мог корректно перезапускать неработоспособные Pod'ы.
• Используйте Horizontal Pod Autoscaler (HPA) для автоматического масштабирования по CPU/памяти, чтобы избежать ситуации, когда Pod'ам постоянно не хватает ресурсов.