Ограничения ресурсов в Kubernetes

TL;DR

Устанавливайте requests и limits для контейнеров в Kubernetes: requests резервируют ресурс для планировщика, limits ставят жёсткую границу и предотвращают деградацию узла. Настройте запросы низко, а лимиты достаточно высоко, чтобы не нарушить соседние приложения. Для памяти особенно важно иметь пределы — это защищает кластер от OOM.

Быстрые ссылки

• Единицы ресурсов

• Создание ограничения CPU

• Создание ограничения памяти

• Ограничения хранилища

• Запросы ресурсов

• Использование requests и limits

• Заключение

Установка ограничений ресурсов на поды Kubernetes предотвращает ситуацию, когда один некорректный контейнер влияет на остальные рабочие нагрузки. Kubernetes позволяет ограничивать использование CPU и памяти, а при превышении лимитов поды могут быть завершены, что поддерживает общую стабильность кластера.

Единицы ресурсов

Перед определением лимитов полезно понять, как Kubernetes выражает доступные ресурсы.

CPU измеряется в долях виртуальных CPU (vCPU) или в милли-CPU (m). Примеры:

0.5

означает половину vCPU. Эквивалентно 500m (милли-CPU).

На облачных провайдерах vCPU обычно соответствует виртуальному ядру/логическому потоку процессора. На bare-metal vCPU обычно соответствует одному гиперпотоку.

Память измеряется в байтах. Можно указать целое число байт или удобные форматы:

512Mi

или

1Gi

Факты о единицах:

• 1 Ki = 1024 байт
• 1 Mi = 1024 Ki = 1 048 576 байт
• 1 Gi = 1024 Mi = 1 073 741 824 байт

(Пример: 512Mi = 536 870 912 байт.)

Важно: локализация единиц не изменяет их значения — “Mi” и “Gi” используются во всём кластере.

Создание ограничения CPU

Чтобы добавить ограничение CPU для контейнера, включите поле resources:limits в манифест контейнера.

Оригинальный фрагмент из примера:

apiVersion: v1

Ниже — корректный пример Pod-манифеста с ограничением CPU, который можно применить через kubectl:

apiVersion: v1
kind: Pod
metadata:
  name: demo
  namespace: demo
spec:
  containers:
  - name: my-container
    image: example/example
    resources:
      limits:
        cpu: "0.5"

В этом примере контейнер ограничен 0.5 vCPU (или 500m). Kubernetes будет ограничивать (throttle) использование CPU так, чтобы контейнер не мог потреблять более половины доступного CPU-времени за короткий интервал.

Советы:

• Для более мелких градаций используйте милли-CPU, например cpu: “250m”.
• Лимит CPU не вызывает завершения контейнера — вместо этого ядро планировщика cfs throttling ограничит выполнение потоков.

Важно: CPU-лимит предотвращает перераспределение процессорного времени, но не освобождает память — для этого нужны memory limits.

Создание ограничения памяти

Создание ограничения памяти похоже на CPU: поменяйте limits:cpu на limits:memory.

Пример минимального фрагмента:

limits:

memory: "512Mi"

Корректный YAML-манифест с ограничением памяти:

apiVersion: v1
kind: Pod
metadata:
  name: demo-memory
  namespace: demo
spec:
  containers:
  - name: mem-container
    image: example/example
    resources:
      limits:
        memory: "512Mi"

При превышении лимита памяти kubelet пометит контейнер как кандидата на завершение и, в большинстве случаев, ядро ОС завершит процесс (OOM-killer). Контейнер будет перезапущен в соответствии с политикой RestartPolicy.

Совет: всегда устанавливайте memory limit для рабочих контейнеров, особенно для приложений на JVM, баз данных и сервисов, которые могут использовать непредсказуемое количество памяти.

Ограничения хранилища

У всех узлов Kubernetes есть пул эфемерного хранилища (ephemeral storage), который используется для кешей, логов и образов контейнеров. Можно задать ограничение на использование эфемерного хранилища контейнером:

limits:

ephemeral-storage: "1Gi"

Пример:

apiVersion: v1
kind: Pod
metadata:
  name: demo-storage
spec:
  containers:
  - name: storage-container
    image: example/example
    resources:
      limits:
        ephemeral-storage: "1Gi"

Поведение:

• Контейнер, пытающийся использовать больше, чем указано, может быть эвакуирован (evicted).
• Если в поде несколько контейнеров, суммарное использование всех контейнеров сравнивают с лимитом пода/узла.
• Kubernetes отслеживает использование хранения периодическими сканированиями файловой системы узла.

Файловая система и project quotas:

• Для более точного контроля можно включить поддержку project-квот (например, XFS или ext4 с проектными квотами).
• Файловая система должна быть примонтирована с соответствующей опцией, а в kubelet включена функция LocalStorageCapacityIsolationFSQuotaMonitoring.
• Инструкции по настройке указаны в официальной документации Kubernetes.

Запросы ресурсов

Помимо лимитов, можно задавать requests — ожидаемое количество ресурса, которое контейнер будет использовать. Requests доступны для CPU, памяти и эфемерного хранилища.

Чтобы задать request, используйте поле requests вместо limits в тех же блоках ресурсов.

Пример:

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"

Планировщик (scheduler) использует requests для принятия решения, на какой узел поместить под. Узел считается пригодным, если сумма requests всех подов, включая новый, не превышает доступной ёмкости узла.

Отличия request от limit:

• Request — это гарантия планировщика: пространство зарезервировано для пода при размещении.
• Limit — это верхняя граница, которую контейнер не должен превышать.
• Контейнер может фактически потреблять больше, чем request, если ресурсы свободны, но не больше, чем limit.

Практическая метрика: ставьте request таким образом, чтобы суммарные requests отражали реальное устойчивое потребление, а limits давали запас для пиков.

Использование requests и limits — практические рекомендации

Ментальная модель: requests = бронь места в отеле, limits = стена вокруг номера.

Правила и эвристики:

• Ставьте низкие requests, чтобы повысить вероятность планирования пода, но не настолько низкие, чтобы он постоянно перескакивал в OOM или вызывал thrashing.
• Устанавливайте limits достаточно высокими, чтобы покрыть пиковое использование, но не настолько высокими, чтобы один под мог «съесть» весь узел.
• Для критичных сервисов задавайте request близким к среднему использованию, а limit — к 2×–3× среднего пика (зависит от нагрузки).
• Для кратковременных burst-слоев можно позволить request < среднее и limit в разумных пределах.

Мини-методология выбора значений:

1. Собирать метрики: используйте prometheus/metrics-server/Perf для CPU и памяти в проде за N дней.
2. Проанализировать распределение: посмотреть медиану (P50), пиковые значения (P95, P99).
3. Установить request = P50 или чуть ниже для ненапряжённых приложений. Для критичных — request = P75.
4. Установить limit = P95–P99 или несколько кратное среднего, учитывая характер пиков.
5. Наблюдать и корректировать через 2–4 недели.

Тестирование и валидация:

• Выполните нагрузочные тесты, имитирующие реальные пики.
• Проверяйте поведение при OOM и CPU-throttling.

Когда это не работает (примеры ошибок)

• Слишком низкие requests приводят к частому переустановлению подов в пиковые часы.
• Отсутствие memory-limits может привести к OOM-убийствам на узле и падению соседних подов.
• Слишком высокие limits “съедают” ресурсы и снижают плотность размещения.
• Неправильная настройка project quotas для ephemeral-storage даёт ложные представления о доступности диска.

Альтернативные подходы и дополнения

• LimitRange: используйте LimitRange в неймспейсе, чтобы задать минимальные и максимальные значения request/limit и задать значения по умолчанию.

Пример LimitRange:

apiVersion: v1
kind: LimitRange
metadata:
  name: limits
  namespace: demo
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "250m"
      memory: "256Mi"
    type: Container

• ResourceQuota: контролируйте суммарное потребление ресурсов в неймспейсе.

Пример ResourceQuota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: demo-quota
  namespace: demo
spec:
  hard:
    requests.cpu: "2"
    requests.memory: "2Gi"
    limits.cpu: "4"
    limits.memory: "4Gi"

• Вертикальное масштабирование (VerticalPodAutoscaler) может применять изменения requests/limits автоматически.

Ролевые чек-листы

Разработчик:

• Указать разумный request, отражающий среднее использование.
• Указать memory limit для всех сервисов.
• Поставить health checks и тестировать при ограниченных ресурсах.

SRE/Платформенная команда:

• Наладить сбор метрик (CPU, memory, storage, throttling).
• Ввести LimitRange и ResourceQuota для контролируемых неймспейсов.
• Проводить нагрузочное тестирование и корректировать рекомендации.

Операционный инженер:

• Следить за эвикшнами (evictions) и OOM в логах kubelet.
• Настроить alert’ы на высокий уровень throttling и частые перезапуски.
• Обеспечить мониторинг свободного эфемерного хранилища на узлах.

Матрица рисков и смягчения

Примеры тестов и критерии приёмки

Критерии приёмки:

• Под запускается в ожидаемое время на узле, где суммарные requests удовлетворяются.
• Во время имитированного пика приложение не превышает memory limit более чем N раз (N = согласованный предел на инциденты).
• Не происходит массовых эвикшенов узла после корректировки лимитов.

Тест-кейсы:

1. Нагрузочный тест CPU: поднять нагрузку до значения чуть выше limits и наблюдать throttling.
2. Тест памяти: постепенно увеличивать память, наблюдать OOM и поведение перезапуска.
3. Тест диска: генерировать большие файлы, проверить эвикшены при превышении ephemeral-storage.

Полезные шаблоны и сниппеты

• Быстрая команда для просмотра использования requests/limits в неймспейсе:

kubectl get pods -n  -o custom-columns=NAME:.metadata.name,CPU_REQUESTS:.spec.containers[*].resources.requests.cpu,MEM_REQUESTS:.spec.containers[*].resources.requests.memory,CPU_LIMITS:.spec.containers[*].resources.limits.cpu,MEM_LIMITS:.spec.containers[*].resources.limits.memory

• Пример проверки евикшенов на узле:

journalctl -u kubelet | grep -i eviction

Факто-бокс: ключевые числа

• 1 Ki = 1024 байт
• 1 Mi = 1 048 576 байт
• 1 Gi = 1 073 741 824 байт
• 0.5 vCPU = 500m

Глоссарий (1 строка)

• request — ресурс, зарезервированный планировщиком для пода.
• limit — верхняя граница ресурса, которую контейнер не должен превышать.
• ephemeral-storage — временное хранилище на узле для кешей, логов и образов.

Заключение

Всегда настраивайте requests и limits для контейнеров в Kubernetes. Это простая практическая мера, которая защищает стабильность кластера, повышает предсказуемость планирования и уменьшает риск массовых падений при пиковых нагрузках. Начните с измерений, примените LimitRange/ResourceQuota для контроля и регулярно пересматривайте значения по метрикам.

Источник рекомендаций: опыт эксплуатации Kubernetes и официальная документация Kubernetes.