Настройка LimitRange в Kubernetes: управление ресурсами подов

Введение / Зачем это нужно

В кластерах Kubernetes разработчики часто забывают или намеренно не указывают запросы (requests) и ограничения (limits) для контейнеров. Без чётких границ один «прожорливый» под способен забрать всю доступную оперативную память или процессорное время, вызывая падение соседних сервисов и нестабильность узла.

LimitRange решает эту проблему на уровне пространства имён. Он автоматически назначает значения по умолчанию, блокирует создание ресурсов, выходящих за допустимые рамки, и гарантирует предсказуемое поведение планировщика. Следуя этому гайду, вы настроите политику распределения ресурсов за несколько минут и защитите кластер от случайных перегрузок.

Требования / Подготовка

Перед началом убедитесь, что у вас есть:

• Доступ к кластеру с правами admin или edit на уровне нужного пространства имён.
• Установленный и настроенный kubectl версии 1.24 или выше.
• Существующий namespace, в котором планируется применить ограничения.
• Базовое понимание структуры подов и понятий requests / limits.

💡 Совет: Если вы работаете в production-окружении, сначала протестируйте конфигурацию в staging-пространстве, чтобы не заблокировать легитимные развертывания.

Пошаговая инструкция

Шаг 1: Проверка целевого пространства имён

Сначала убедитесь, что вы работаете в правильном контексте. Выведите список доступных пространств имён и переключитесь на нужное:

kubectl get namespaces
kubectl config set-context --current --namespace=<your-namespace>

Проверьте текущие привязки и убедитесь, что в пространстве ещё нет конфликтующих политик:

kubectl get limitrange -n <your-namespace>

Шаг 2: Создание манифеста LimitRange

Подготовьте файл limitrange-dev.yaml. В примере ниже заданы минимальные, максимальные и дефолтные значения для контейнеров. Обратите внимание на поле defaultRequest: оно применяется только если разработчик не указал requests в спецификации контейнера.

apiVersion: v1
kind: LimitRange
metadata:
  name: resource-limits
  namespace: <your-namespace>
spec:
  limits:
    - type: Container
      # Максимально допустимые значения для одного контейнера
      max:
        cpu: "2"
        memory: "2Gi"
      # Минимально допустимые значения
      min:
        cpu: "50m"
        memory: "64Mi"
      # Значения по умолчанию, если разработчик не указал limits
      default:
        cpu: "500m"
        memory: "512Mi"
      # Значения по умолчанию для requests, если они пропущены
      defaultRequest:
        cpu: "100m"
        memory: "128Mi"
    - type: Pod
      # Суммарные лимиты на все контейнеры внутри одного пода
      max:
        cpu: "4"
        memory: "4Gi"

⚠️ Важно: Значения default всегда должны быть меньше или равны max, а min — меньше или равны default. Нарушение этого правила приведёт к ошибке валидации при создании ресурса.

Шаг 3: Применение конфигурации в кластере

Примените манифест к целевому namespace:

kubectl apply -f limitrange-dev.yaml

После успешного применения политика вступает в силу мгновенно. Все новые поды в этом пространстве имён будут проходить проверку на соответствие указанным границам.

Шаг 4: Тестирование на реальном поде

Проверьте, как LimitRange обрабатывает под без явных лимитов. Создайте тестовый манифест:

apiVersion: v1
kind: Pod
metadata:
  name: test-limitrange
  namespace: <your-namespace>
spec:
  containers:
    - name: nginx
      image: nginx:latest

Примените его и изучите спецификацию запущенного контейнера:

kubectl apply -f test-pod.yaml
kubectl get pod test-limitrange -n <your-namespace> -o jsonpath='{.spec.containers[0].resources}'

В выводе вы должны увидеть автоматически подставленные requests: 100m / 128Mi и limits: 500m / 512Mi.

Проверка результата

Чтобы убедиться, что политика работает корректно, выполните два сценария:

1. Проверка подстановки значений по умолчанию: как в Шаге 4. Используйте kubectl describe pod <name> и обратите внимание на секцию Containers -> Limits/Requests. Если там указаны значения из limitrange.yaml, интеграция успешна.
2. Проверка блокировки превышения: запустите под с cpu: "3" или memory: "3Gi". Планировщик должен отклонить создание с ошибкой exceeded max cpu или exceeded max memory. Это подтверждает, что жёсткие границы активны.

Возможные проблемы

Ошибка forbidden: exceeded quota при создании LimitRange Эта ошибка возникает, если заданные вами default или max превышают свободный лимит ResourceQuota в пространстве имён. Либо уменьшите значения в LimitRange, либо увеличьте квоту через kubectl edit resourcequota.

Под не получает значения по умолчанию LimitRange работает только на этапе создания объекта. Если под уже существовал до применения политики, он останется без изменений. Пересоздайте под (kubectl delete pod <name> && kubectl apply -f pod.yaml), чтобы триггернуть валидацию.

Конфликт типов ресурсов (type: Container vs type: Pod) Если вы задаёте max для Pod, но не указываете max для Container, может возникнуть ситуация, когда один контейнер занимает всё доступное пространство. Всегда определяйте ограничения на уровне Container, а Pod используйте как дополнительный предохранитель для sidecar-архитектур.