Resource Quotas и LimitRanges

Обзор #

Resource Quotas и LimitRanges позволяют ограничить потребление CPU, памяти и других ресурсов в неймспейсах. Используются для разграничения ресурсов между командами и предотвращения исчерпания ресурсов кластера.

Где создавать: в неймспейсе — Хранилище → ResourceQuotas / LimitRanges или через импорт манифестов.

ResourceQuota #

ResourceQuota задаёт жёсткие лимиты на суммарное потребление ресурсов в неймспейсе.

Создание квоты в GUI #

1. Откройте неймспейс → Хранилище → ResourceQuotas (или Квоты).
2. Нажмите + Создать квоту.
3. Задайте название квоты, при необходимости — лейблы и аннотации.
4. Для скоупа применения квоты задайте совпадающие выражения (scope selector).
5. На вкладке Ресурсы задайте:
   • requests.cpu — сумма запросов CPU подов;
   • requests.memory — сумма запросов памяти;
   • limits.cpu — сумма лимитов CPU;
   • limits.memory — сумма лимитов памяти.
6. На вкладке Хранилище задайте:
   • requests.storage — общий объём запросов на хранилище;
   • persistentvolumeclaims — количество PVC;
   • requests.ephemeral-storage, limits.ephemeral-storage — эфемерное хранилище;
   • по Storage Class — лимиты для конкретного класса.
7. На вкладке Количество задайте лимиты на количество объектов: pods, services, secrets, configmaps и др.
8. Нажмите Сохранить.

Просмотр и редактирование квоты #

На странице ResourceQuotas кликните по названию квоты. Обновите параметры и нажмите Сохранить. Или перейдите на вкладку Манифест, внесите изменения и выполните проверку.

LimitRange #

LimitRange задаёт ограничения по умолчанию и допустимые диапазоны для подов и контейнеров в неймспейсе.

Обратите внимание! LimitRange применяется только к новым объектам в момент их создания. Существующие поды и PVC не меняются.

Создание LimitRange в GUI #

1. Откройте неймспейс → Хранилище → LimitRanges (или Квоты → Limit Ranges).
2. Нажмите + Создать LimitRange или Создать.
3. Задайте название.
4. На вкладке Container задайте:
   • CPU Default Request (limits.defaultRequest.cpu) — запрос CPU по умолчанию;
   • CPU Default Limit (limits.default.cpu) — лимит CPU по умолчанию;
   • Memory Default Request (limits.defaultRequest.memory) — запрос памяти по умолчанию;
   • Memory Default Limit (limits.default.memory) — лимит памяти по умолчанию;
   • CPU Min/Max, Memory Min/Max — допустимые диапазоны для контейнеров.
5. На вкладке Pod задайте min/max для суммарных ресурсов пода.
6. На вкладке PersistentVolumeClaims задайте min/max для размера PVC.
7. Нажмите Сохранить.

Единицы измерения #

• Память: B, Ki, Mi, Gi.
• CPU: целые ядра (1, 2) или милликоры (100m, 500m).

Просмотр и редактирование LimitRange #

Для просмотра LimitRange кликните по названию в списке. Обновите параметры и нажмите Сохранить. Или перейдите на вкладку Манифест, внесите изменения и выполните проверку.

Примеры: ResourceQuota #

Лимиты на CPU и память #

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi

Лимиты на объекты #

apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-quota
  namespace: team-a
spec:
  hard:
    pods: "20"
    services: "5"
    persistentvolumeclaims: "10"
    secrets: "20"
    configmaps: "20"

Комбинированная квота #

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "50"
    persistentvolumeclaims: "15"

Примеры: LimitRange #

Лимиты по умолчанию для контейнеров #

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-a
spec:
  limits:
  - default:
      cpu: "500m"
      memory: 512Mi
    defaultRequest:
      cpu: "100m"
      memory: 128Mi
    type: Container

Пример: значения по умолчанию #

Memory Default Limit: 512Mi, CPU Default Limit: “1”, Memory Default Request: 256Mi, CPU Default Request: “0.5”:

• Если контейнер не указывает запрос на память — ему будет назначено 256Mi.
• Если контейнер не указывает лимит на память — 512Mi.
• Если контейнер не указывает запрос на CPU — 0.5 CPU.
• Если контейнер не указывает лимит на CPU — 1 CPU.

Min/Max для контейнеров #

apiVersion: v1
kind: LimitRange
metadata:
  name: container-limits
  namespace: team-a
spec:
  limits:
  - min:
      cpu: "100m"
      memory: 128Mi
    max:
      cpu: "2"
      memory: 2Gi
    type: Container

• CPU Min — контейнер с CPU ниже указанного не будет запущен.
• CPU Max — контейнер с CPU выше указанного не будет запущен.
• Memory Min/Max — аналогично для памяти.

Лимит для PVC #

apiVersion: v1
kind: LimitRange
metadata:
  name: pvc-limits
  namespace: team-a
spec:
  limits:
  - type: PersistentVolumeClaim
    min:
      storage: 1Gi
    max:
      storage: 10Gi

Проверка квот #

# Статус квот в неймспейсе
kubectl get resourcequota -n team-a

# Детали квоты
kubectl describe resourcequota compute-quota -n team-a

# LimitRanges в неймспейсе
kubectl get limitrange -n team-a

При превышении квоты создание новых ресурсов (подов, PVC и др.) будет отклонено с сообщением о превышении лимита.

Best practices и anti-patterns #

Best practices #

1. Согласованность Quota и LimitRange: LimitRange не должен задавать defaultRequest/default выше, чем позволяет Quota. Иначе суммарные запросы подов могут превысить квоту.
2. Реалистичные лимиты: Устанавливайте квоты на основе мониторинга и реального потребления команд.
3. Scope для Quota: Используйте scope selector (например, NotIn для Terminating) для исключения завершающихся подов из квоты.
4. Разделение по неймспейсам: Выделяйте отдельные неймспейсы для команд и задавайте квоты на каждый.

Anti-patterns #

1. Неадекватные значения по умолчанию: Слишком высокие LimitRange могут привести к исчерпанию ресурсов; слишком низкие — к неработоспособности приложений. Пример: приложение требует 2000m CPU, а LimitRange задаёт 1000m — приложение будет работать с задержками или падать.
2. Игнорирование реального использования: Max/min в LimitRange должны соответствовать фактическому потреблению. Иначе поды могут быть в Pending или приложение будет throttled.
3. LimitRange больше размера узла: Если default CPU/memory в LimitRange больше, чем у узла (например, 2 CPU и 4Gi при узле 1 CPU и 2Gi), Kubernetes не сможет запланировать поды.
4. Слишком низкие max: Если под требует 1 CPU и 2Gi, а max в LimitRange — 500m и 1Gi, под останется в Pending.

Типичные сценарии #

Несколько LimitRange в одном неймспейсе #

Если в неймспейсе несколько LimitRange с разными default-значениями, применяются значения последнего созданного объекта LimitRange.