Что произойдет, если будет превышение по CPU в Kubernetes

Анализ последствий превышения CPU в Kubernetes

Превышение лимитов CPU в Kubernetes — это ситуация, когда контейнер потребляет больше процессорного времени, чем ему выделено по лимитам (limits) в ресурсных запросах Pod'а. Это не то же самое, что превышение запросов (requests). Давайте разберем последствия с технической и практической точек зрения.

Механизм работы CPU limits в Linux

Kubernetes полагается на механизмы cgroups (control groups) ядра Linux для управления ресурсами. Для CPU используется подсистема cpu,cpuacct. Лимиты реализуются через CFS (Completely Fair Scheduler) Bandwidth Control.

Когда вы задаете limits.cpu: 500m (0.5 ядра), Kubernetes настраивает cgroup с двумя ключевыми параметрами:

• cpu.cfs_period_us (обычно 100000 мкс = 100 мс) — период расчета.
• cpu.cfs_quota_us (в нашем случае 50000 мкс = 50 мс) — квота на период. Контейнер может использовать 50 мс CPU времени каждые 100 мс.

# Пример Pod с requests и limits
apiVersion: v1
kind:	Pod
metadata:
  name: stressed-pod
spec:
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", "dd if=/dev/zero of=/dev/null & sleep 3600"]
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"   # Гарантировано 0.25 ядра
      limits:
        memory: "128Mi"
        cpu: "500m"   # Жесткий лимит в 0.5 ядра

Что происходит при превышении лимита?

1. Throttling (Ограничение производительности)

    Это основное и прямое последствие. Ядро Linux **приостанавливает** выполнение процессов контейнера (`cgroup`), когда они исчерпали свою квоту (`cpu.cfs_quota_us`) в текущем периоде (`cpu.cfs_period_us`). Процессы переходят в состояние "throttled" и не получают процессорного времени до начала следующего периода.

```bash
# Мониторинг Throttling через метрики cgroup
# Просмотр счетчика throttling (увеличивается при каждом ограничении)
cat /sys/fs/cgroup/cpu,cpuacct/kubepods.slice/<pod-uid>/cpu.stat
# nr_periods     <количество прошедших периодов>
# nr_throttled   <сколько раз была активирована квота>
# throttled_time <общее время, которое cgroup был throttled>
```

2. Увеличение задержки (Latency) и снижение пропускной способности (Throughput)

    *   Приложения, чувствительные к задержкам (базы данных, шлюзы API, системы реального времени), начнут страдать от периодических "заиканий".
    *   Среднее время обработки запроса (p95, p99) может резко вырасти, так как некоторые запросы будут выполняться в периоды throttling.
    *   Это часто проявляется в графиках как **"пилообразная" форма утилизации CPU** контейнера: резкий рост до лимита, затем спад до нуля в момент throttling.

1. Влияние на соседние Pod'ы и node

    *   **На одной ноде:** Pod, превышающий лимиты CPU, **не может** "украсть" CPU у других Pod'ов, чьи лимиты не исчерпаны. Механизм cgroups строго изолирует его. Однако, если на ноде есть **Best-Effort Pod'ы** (без limits) или Pod'ы, чьи фактические потребности ниже их requests, "свободный" CPU будет сначала распределен между ними.
    *   **Стабильность ноды:** Сам узел (kubelet, системные демоны) защищены системным cgroup (`system.slice`), поэтому его работа обычно не нарушается. Однако общая производительность ноды падает, так как часть CPU времени тратится впустую в ожидании (throttling).

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

Для обнаружения проблемы используйте следующие подходы:

• Метрики cAdvisor / kubelet: Метрика container_cpu_cfs_throttled_periods_total и container_cpu_cfs_throttled_seconds_total в Prometheus.
• Kubernetes Metrics Server: Утилизация CPU, отображаемая в kubectl top pods, будет показывать значения на уровне или чуть ниже лимита, но не сможет отобразить сам факт throttling.
• Логи приложения: Резкие скачки в логах времени ответа.

# Пример PromQL запроса для выявления Pod'ов с активным throttling
# Высокое соотношение throttled периодов к общему числу периодов
sum(rate(container_cpu_cfs_throttled_periods_total{container!=""}[5m])) by (pod, namespace)
/
sum(rate(container_cpu_cfs_periods_total{container!=""}[5m])) by (pod, namespace)

Стратегии решения и лучшие практики

• Правильная настройка Requests и Limits: requests должен отражать среднюю нагрузку для планирования, limits — пиковую, которую может выдержать приложение без сбоев. Для некоторых stateful-нагрузок (БД, очереди) иногда разумно не устанавливать CPU limits, чтобы избежать throttling, но делать это осторожно, с пониманием рисков для соседних workload'ов.
• Вертиканое автомасштабирование (VPA): Если превышение регулярное, используйте Vertical Pod Autoscaler для автоматической корректировки requests и limits на основе исторических данных.
• Горизонтальное масштабирование (HPA): Настройте Horizontal Pod Autoscaler по метрике CPU (которая учитывает limits). Если Pod постоянно упирается в лимит, HPA создаст дополнительные реплики, чтобы распределить нагрузку.
• Оптимизация приложения: Проанализируйте профиль потребления CPU с помощью pprof (Go), async-profiler (Java), py-spy (Python) для поиска "узких мест".

Вывод: Превышение CPU limits в Kubernetes не приводит к завершению контейнера (в отличие от памяти), но вызывает контролируемое ограничение производительности (throttling), что негативно сказывается на отзывчивости приложения. Ключ к управлению — тщательный мониторинг метрик throttling, обоснованное назначение ресурсов и использование механизмов автомасштабирования.