Ограничения ресурсов в Kubernetes: CPU, память и хранилище

Логотип Kubernetes в векторном стиле на синем фоне

Коротко о ресурсных единицах

CPU измеряется в vCPU (виртуальных ядрах). Значение

0.5

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

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

512Mi

или

1Gi

Эти обозначения совместимы с Kubernetes и общепринятыми утилитами.

Примеры манифестов: создание CPU-лимита

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

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

В этом примере контейнер будет ограничен 0.5 vCPU и при попытке потребить больше будет троттлен (ограничен по CPU-времени). Троттлинг обычно выражается как уменьшение доступного процессорного времени в коротких интервалах (например, из расчёта квоты на 100ms).

Важно: CPU-лимит не убивает контейнер — он принудительно снижает доступное процессорное время.

Примеры манифестов: создание лимита по памяти

Аналогично задаётся лимит по памяти через resources.limits.memory:

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

Если контейнер превысит лимит памяти и на узле не будет избыточной памяти, kubelet/ядро пометит процесс как кандидат на завершение (OOM), и контейнер будет убит. Kubernetes затем может перезапустить контейнер в соответствии с политикой перезапуска.

Важно: лимит памяти — это защитный механизм, который позволяет сохранить целостность узла и других подов.

Эпhemeral storage: ограничение временного хранилища

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

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

Если суммарное использование всех контейнеров в поде превысит указанный лимит, под будет эвакуирован (evicted). При нескольких контейнерах в поде складывается суммарное использование всех контейнеров.

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

Запросы ресурсов (requests)

Запрос ресурса (requests) указывает минимальную ожидаемую потребность контейнера и влияет на решение планировщика, на каком узле разместить под. Примеры:

resources:
  requests:
    cpu: "0.1"
    memory: "256Mi"

Если сумма запросов на узле вместе с запросом нового пода превышает общую ёмкость узла, узел считается непригодным для размещения этого пода — даже если фактическое текущее использование ресурсов на узле низкое.

В отличие от лимита, request не мешает контейнеру потреблять больше ресурсов в runtime, если эти ресурсы свободны — но это возможно лишь до тех пор, пока не достигнуты лимиты и ресурсы не понадобятся другим контейнерам.

Requests vs Limits — как выбирать значения

Request влияет на планирование; limit — на поведение во время выполнения.
Низкий request повышает шансы на планирование, но может ухудшить прогнозируемость производительности.
Высокий limit защищает от неожиданных пиков, но может привести к неэффективному использованию кластера.

Рекомендации:

Для короткоживущих задач (Jobs, CronJob) ставьте conservative requests и адекватные limits.
Для stateful сервисов (базы данных) ставьте точные requests и conservative limits, ориентируясь на измеренные показатели подов в нагрузочных тестах.
Используйте инструмент профилирования и метрики (например, Prometheus) для уточнения реальных потребностей.

Политики качества (QoS)

Kubernetes присваивает подам класс QoS на основе наличия и равенства requests и limits:

Guaranteed: все контейнеры имеют одинаковые request и limit по каждому ресурсу.
Burstable: request указан, но limit выше (или не указан) — под может использовать лишние ресурсы, пока они есть.
BestEffort: нет ни request, ни limit — наименее защищённый класс.

Выбор QoS влияет на приоритет при выселении (eviction) и устойчивость приложения на узле под давлением ресурсов.

Ограничения на уровне проекта и кластера

LimitRange в namespace задаёт минимальные/максимальные значения request/limit по умолчанию для подов в namespace.
ResourceQuota ограничивает суммарное потребление ресурсов на namespace, защищая другие команды от чрезмерного использования.

Используйте оба механизма для контроля потребления в мультиарендных средах.

Практические приёмы и чеклисты

Чеклист для разработчика приложения:

Измерьте поведение приложения под нормальной и пиковй нагрузкой.
Установите request ≈ среднему использованию, limit ≈ пиковому использованию + запас.
Протестируйте поведение при троттлинге CPU и при OOM.
Добавьте наблюдаемость: метрики CPU, памяти, использования диска, логи OOM.

Чеклист для SRE/платформенной команды:

Настройте LimitRange и ResourceQuota для всех namespace.
Внедрите правило ревью манифестов (CI) для проверки requests/limits.
Настройте оповещения на высокое использование и частые OOM/eviction-события.
Автоматизируйте сбор исторических метрик для анализа тенденций.

Мини-методология для установки запросов и лимитов

Снимите метрики приложения в стабильно работающей среде (CPU, RAM, I/O) при разных нагрузках.
Определите p50/p90/p99 потребления для ключевых метрик.
Установите request близко к p50, limit — между p90 и п99 плюс безопасный запас.
Прогоните нагрузочные тесты и проверьте поведение при достижении лимитов.
Пересматривайте значения при изменениях кода или нагрузки.

Когда подход с requests/limits не срабатывает

Приложение имеет непредсказуемые всплески памяти и требует вертикального масштабирования — решение: Vertical Pod Autoscaler (VPA) или переработка приложения.
Неправильно настроенные filesystem quotas мешают точному учёту эпемерного хранилища — решение: включить project quota и LocalStorageCapacityIsolationFSQuotaMonitoring.
Частые OOM-перезапуски из-за слишком низких limits — уменьшите агрессивность лимитов или улучшите управление памятью в приложении.

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

Vertical Pod Autoscaler (VPA): автоматически предлагает или применяет новые requests/limits.
Horizontal Pod Autoscaler (HPA): масштабирует число реплик при росте нагрузки, что снижает потребности в увеличении лимитов на одиночный под.
LimitRange/ResourceQuota: политические/административные ограничения.

Пример runbook при массовых OOM/eviction

Оповещение: монитор зафиксировал рост OOM или массовые эвикты.
Проверить логи kubelet и событий пода: kubectl describe pod и kubectl get events.
Сравнить текущие requests/limits и фактическое использование (metrics server/Prometheus).
Если лимиты слишком низки — увеличить limits, протестировать, и продлить изменения.
Если узел перегружен — временно подвинуть поды на другие узлы или увеличить capacity.
Провести постинцидентный анализ и обновить рекомендации (SLO/Runbook).

Дерево принятия решения

flowchart TD
  A[Нужно ли защищать соседей от приложения?] -->|Да| B[Поставить лимиты памяти и CPU]
  A -->|Нет| C[Можно использовать только requests]
  B --> D{Пиковые всплески памяти?}
  D -->|Да| E[Установить жесткий memory limit и тестировать OOM]
  D -->|Нет| F[Оставить запас в limit]
  E --> G[Рассмотреть VPA или переработку приложения]
  C --> H[Низкие requests для лучшей планируемости]

Глоссарий в одну строку

request: запрашиваемое минимальное количество ресурса для планировщика.
limit: верхняя граница потребления ресурса во время выполнения.
QoS: политика качества обслуживания пода (Guaranteed, Burstable, BestEffort).
Eviction: выселение пода с узла из-за нехватки ресурсов.

Итог

Всегда указывайте хотя бы requests для CPU и памяти.
Для критичных сервисов задавайте и requests, и limits, чтобы получить предсказуемое поведение.
Используйте LimitRange и ResourceQuota для контроля в командах и средах с несколькими арендаторами.
Наблюдаемость и нагрузочное тестирование — ключ к корректному выбору значений.

Краткое заключение: грамотная настройка requests и limits обеспечивает устойчивость кластера и позволяет приложениям корректно сосуществовать без риска разового «поглощения» ресурсов одним контейнером.