⚙️ Теория
🧩 Requests vs Limits
requests:
- используются scheduler для выбора node;
- задают ресурсный запрос для планирования и влияют на QoS/cgroup-настройки (это не абсолютная runtime-гарантия для CPU в любой момент).
limits:
- верхняя граница использования ресурса контейнером;
- при memory limit может происходить OOMKill.
🧠 QoS классы Pod
Kubernetes определяет QoS классы:
GuaranteedBurstableBestEffort
Класс влияет на порядок eviction при давлении по памяти/ресурсам.
⚠️ Типовые анти-паттерны
limitsсильно ниже реальных пиков -> OOMKill;- отсутствие requests -> плохая предсказуемость планирования;
- одинаковые шаблоны для всех сервисов без профилирования.
❓ Что нужно уметь объяснить
Почему pod с low CPU limit может быть "жив", но медленный?
CPU throttling не всегда убивает контейнер, но резко ухудшает latency.
Почему OOMKill часто повторяется циклически?
Приложение стартует, доходит до пика памяти, упирается в limit и убивается; без изменения лимита/потребления цикл повторяется.
Почему requests должны быть основаны на метриках?
Потому что "на глаз" обычно приводит к overcommit или недовыделению ресурсов и нестабильному поведению кластера.
🧪 Практика
1. Минимальный корректный ресурсный профиль
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "1"
memory: "512Mi"
2. Диагностика OOM/eviction
kubectl describe pod <pod>
kubectl get events --sort-by=.lastTimestamp
kubectl top pod -A
kubectl top node
3. Guardrails
- задавать requests/limits для всех production workload;
- пересматривать значения по p95/p99 потреблению;
- использовать VPA/HPA осознанно и отдельно проверять взаимодействие автоскейлинга с лимитами.
🧾 Вывод
Resources в Kubernetes это не формальность. Корректные requests/limits и понимание QoS напрямую влияют на стабильность, плотность размещения и предсказуемость при нагрузке.