Requests и limits
Тема дорожной карты · Kubernetes
Запросы и лимиты ресурсов (Resource Requests and Limits) — механизм Kubernetes для объявления ожидаемого и максимального потребления CPU и памяти контейнером; используются kube-scheduler при принятии решений о размещении и kubelet для применения ограничений во время выполнения. resources.requests.cpu и resources.requests.memory определяют минимальные ресурсы, гарантированные контейнеру — планировщик размещает Pod только на узле с как минимум таким объёмом доступной выделяемой ёмкости, — тогда как resources.limits.cpu и resources.limits.memory определяют потолок, выше которого контейнер дросселируется (CPU) или завершается с OOMKill (память). Правильная установка requests и limits определяет класс QoS Pod'а: равные requests и limits дают Guaranteed, только requests или несоответствующие значения — Burstable, а полное отсутствие настроек — подверженный вытеснению класс BestEffort. VPA (Vertical Pod Autoscaler) может автоматически рекомендовать и применять правильно подобранные запросы и лимиты ресурсов, анализируя историческое использование из Prometheus или Metrics Server, снижая как избыточное провизирование, так и инциденты OOMKill. Объекты LimitRange на уровне пространства имён устанавливают requests и limits по умолчанию для Pod'ов, не задающих их, а объекты ResourceQuota ограничивают совокупные CPU, память и количество объектов на пространство имён для соблюдения границ мультитенантности.
Как это работает
Requests и limits обрабатывается scheduler Kubernetes — при создании pod scheduler выбирает ноду на основе resource requests, node labels, taints/tolerations, affinity/anti-affinity правил и priority class. Решение single-pass на pod и учитывает текущее состояние кластера; после scheduling pod остаётся на этой ноде до eviction или rescheduling.
Когда применять
Кастомизируйте Requests и limits, когда дефолтное scheduling даёт проблемы: нагрузки конкурируют за то же железо (используйте anti-affinity для разнесения), нагрузки требуют конкретное железо (nodeSelector или nodeAffinity для GPU-нод), или важен приоритет (PriorityClass, чтобы critical pods вытесняли background). Без кастомизации kube-scheduler нормально справляется в ~80% случаев.
Типичные ошибки
Scheduling-ловушки: правила affinity настолько жёсткие, что pods не могут schedule никуда (Pending навсегда); resource requests, не отражающие реальное использование (кластер либо over-commit и крашится, либо under-commit и сжигает деньги); игнорирование eviction (pods, выселяемые под нагрузкой ноды, выглядят как случайные крэши). Мониторьте метрики scheduler — pending pods — leading indicator проблем кластера.