Настройка ResourceQuotas и LimitRanges в Kubernetes
Представьте: вы заходите на новый проект, а там неймспейс production работает без единого ResourceQuota. Один разработчик задеплоил батч-джобу с requests.cpu: 0 и limits.cpu: 0 — то есть вообще без ограничений. За 20 минут джоба сожрала ресурсы двух нод, и остальные поды ушли в Pending. По данным CNCF, отсутствие квот — одна из трёх главных причин нестабильности в production-кластерах. Наши клиенты часто экономят до 30% затрат на облако после внедрения правильных квот. Без ResourceQuota один недонастроенный под может парализовать работу всего кластера, как это произошло в нашем проекте с онлайн-ритейлером: из-за отсутствия лимитов тестовый неймспейс «съел» половину production-ресурсов.
Согласно официальной документации Kubernetes, ResourceQuota позволяет ограничить совокупное потребление ресурсов в namespace, предотвращая перегрузку кластера.
Почему отсутствие квот — это бомба замедленного действия?
Resource Quotas и Limit Ranges решают разные задачи, но их часто путают. ResourceQuota — лимит на весь неймспейс: суммарное CPU, память, количество подов, сервисов, PVC. Если квота исчерпана, новые объекты не создаются — kubectl apply возвращает ошибку exceeded quota. LimitRange работает на уровне контейнера: задаёт дефолтные requests/limits и минимальные/максимальные значения. Это страховка от контейнеров без явных ограничений.
Как правильно настраивать ResourceQuota и LimitRange?
Начинаем с аудита: kubectl get resourcequota --all-namespaces покажет, у каких неймспейсов нет квот. Затем проверяем, какие поды работают без лимитов: kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.containers[].resources.requests == null)'. После этого проектируем иерархию. Типичная схема для multi-tenant кластера:
| Неймспейс | requests.cpu | limits.cpu | requests.memory | limits.memory | Pods |
|---|---|---|---|---|---|
| production | 20 | 40 | 40Gi | 80Gi | 100 |
| staging | 8 | 16 | 16Gi | 32Gi | 50 |
| dev | 4 | 8 | 8Gi | 16Gi | 30 |
LimitRange для dev выглядит так:
apiVersion: v1
kind: LimitRange
metadata:
name: dev-limits
namespace: dev
spec:
limits:
- type: Container
default:
cpu: 200m
memory: 256Mi
defaultRequest:
cpu: 100m
memory: 128Mi
max:
cpu: "2"
memory: 2Gi
min:
cpu: 50m
memory: 64MiДефолты — это страховка: контейнер без явных ресурсов получит 100m/128Mi автоматически, не дав занять всю ноду.
Что делать, если квоты конфликтуют с HPA?
Вторая грабля — конфликт LimitRange с HPA. Если LimitRange задаёт max.cpu: 500m, а HPA при масштабировании пытается запустить под с limits.cpu: 1, под не создастся. Диагностируется через kubectl describe events -n namespace | grep FailedCreate. Решение — либо поднять max в LimitRange, либо настроить HPA с учётом этих ограничений.
Сравнение ResourceQuota и LimitRange: что лучше?
ResourceQuota лучше подходит для контроля бюджета неймспейса, а LimitRange — для предотвращения расточительных контейнеров. Вместе они дают полный контроль. ResourceQuota эффективнее ограничивает общие затраты, чем LimitRange в одиночку, ведь квоты касаются суммы всех контейнеров. Но без LimitRange контейнеры могут остаться без явных лимитов — тогда HPA может создать поды, которые «задушат» соседей.
| Характеристика | ResourceQuota | LimitRange |
|---|---|---|
| Область действия | Неймспейс | Контейнер |
| Что ограничивает | Суммарные ресурсы, количество объектов | CPU/memory на контейнер |
| Дефолты | Нет | Да (default/request) |
Пошаговый процесс внедрения квот
- Аудит текущего состояния: собираем все неймспейсы, проверяем наличие квот и лимитов. Используем
kubectl get resourcequota --all-namespacesи скрипты для поиска подов без ресурсов. - Анализ метрик за последние 30 дней: из Prometheus выгружаем потребление CPU и памяти по неймспейсам, определяем пиковые значения и резервы. Это основа для проектирования квот.
- Проектирование квот: для каждого неймспейса задаём requests и limits с запасом 20-30% от пика. Учитываем autoscaling и burst-нагрузки.
- Написание манифестов: создаём YAML для ResourceQuota и LimitRange. Для multi-tenant кластера применяем шаблоны с переменными.
- Тестирование на staging: применяем квоты сначала на dev и staging, проверяем логи и события. Отслеживаем ошибки типа
exceeded quota. - Развёртывание на production: поэтапно, с мониторингом через Alertmanager при превышении 85% квоты.
- Документирование: фиксируем схему квот, правила изменения, runbook для типовых ошибок (например,
FailedCreateиз-за LimitRange).
Типичная ошибка: неймспейс с ResourceQuota не создаёт поды. Ошибка: pods "app-xyz-7d9f" is forbidden: exceeded quota: dev-quota, requested: requests.cpu=500m, used: requests.cpu=9800m, limited: requests.cpu=10. Решение: либо поднять квоту, либо разобраться, кто держит ресурсы с помощью kubectl describe resourcequota dev-quota -n dev.
Типичные ошибки при настройке квот
- Установка слишком низких лимитов, что приводит к постоянному отказу в создании подов
- Игнорирование LimitRange, из-за чего контейнеры без явных ресурсов получают дефолты, но не все разработчики это знают
- Неучет burst-нагрузок: квоты не должны быть жесткими, нужен запас 20-30%
Что входит в работу
- Аудит текущих неймспейсов и подов
- Проектирование квот под нагрузку (сбор метрик за последние 30 дней)
- Написание манифестов ResourceQuota и LimitRange
- Тестирование на staging-окружении
- Интеграция с Loki и Alertmanager для уведомлений
- Документация и передача знаний команде
Сроки
Простая конфигурация для 3–5 неймспейсов: 1 день. Мульти-тенантный кластер с десятками команд и интеграцией с Prometheus: 2–3 дня. Экономия облачных затрат после настройки достигает 30%, что при среднемесячных расходах на облако в несколько тысяч долларов дает ощутимый эффект. Инвестиции в настройку квот окупаются в среднем за 1-2 месяца.
Свяжитесь с нами для аудита вашего кластера. Наши инженеры помогут настроить квоты и снизить затраты. Закажите услугу настройки ResourceQuota и LimitRange — получите стабильный кластер и экономию бюджета.
Подробнее о ResourceQuota и LimitRange читайте в официальной документации.
