Ответ
В Kubernetes управление ресурсами реализуется через секцию resources в спецификации контейнера Pod. Используются два ключевых понятия: requests (запросы) и limits (лимиты).
Базовый пример в манифесте Pod или Deployment:
apiVersion: v1
kind: Pod
metadata:
name: my-app-pod
spec:
containers:
- name: app-container
image: myapp:latest
resources:
requests:
memory: "128Mi"
cpu: "250m" # 250 милли-CPU (0.25 ядра)
limits:
memory: "256Mi"
cpu: "500m" # 500 милли-CPU (0.5 ядра)Что это означает:
requests— это гарантированные ресурсы, которые планировщик (scheduler) резервирует для Pod. Pod будет размещен на ноде, где есть как минимум столько свободных ресурсов.limits— это жесткий потолок. Контейнер не может использовать больше.
Последствия превышения лимитов:
- CPU: Если контейнер пытается использовать больше CPU, чем его
limit, ядро Linux будет его throttle (ограничивать), что проявляется в повышенном времени ожидания CPU. - Память: Если контейнер превышает лимит памяти, он будет OOMKilled (убит). Pod перезапустится согласно политике
restartPolicy.
Административные механизмы (на уровне Namespace):
- LimitRange: Задает стандартные лимиты по умолчанию и допустимые диапазоны для контейнеров в Namespace.
- ResourceQuota: Устанавливает общие квоты на потребление ресурсов (суммарные CPU/memory/количество Pods) для всего Namespace, что не позволяет командам исчерпать ресурсы кластера.
В продакшн-кластерах я всегда настраиваю и requests, и limits. Requests критичны для эффективного планирования и загрузки нод, а limits защищают от "шумных соседей". Отсутствие limits — распространенная причина нестабильности.