Зачем нужны ResourceQuota и LimitRange на уровне namespace, и чем они отличаются друг от друга?

Короткий ответ

ResourceQuota ограничивает суммарное потребление ресурсов (CPU, память, число объектов определённого типа) всем namespace целиком, а LimitRange задаёт ограничения и значения по умолчанию для отдельных Pod/контейнеров внутри namespace (минимум, максимум, значения requests/limits по умолчанию, если они не указаны явно) — это защита от разных проблем: ResourceQuota от исчерпания ресурсов кластера одной командой, LimitRange от подов без явных requests/limits.

Как это работает подробнее

если в namespace установлена ResourceQuota с лимитом на суммарные requests.cpu, то любое создание Pod, которое привело бы к превышению этой суммы, будет отклонено API сервером ещё на этапе создания объекта, независимо от реальной свободной ёмкости кластера. LimitRange, в свою очередь, применяется к каждому отдельному Pod/контейнеру при его создании: если в манифесте нет resources, LimitRange может подставить значение по умолчанию, а также заблокировать создание объекта, если указанные значения выходят за допустимый диапазон (min/max).

Пример кода

manifest.yamlКопировать

apiVersion: v1
kind: ResourceQuota
metadata: { name: team-quota, namespace: team-a }
spec:
  hard: { requests.cpu: "10", requests.memory: 20Gi, pods: "50" }

Что использовать на практике

• Практика. ResourceQuota обычно настраивают при выделении namespace под команду или проект в мультиарендном кластере, чтобы одна команда не могла случайно (или намеренно) занять все ресурсы кластера; LimitRange дополняет это, гарантируя, что в принципе каждый под будет иметь хоть какие-то requests/limits, даже если разработчик забыл их указать — это снижает риск появления "незапланированных" BestEffort-подов в namespace с квотами.

Подводные камни

• Риски. устанавливать ResourceQuota без LimitRange, из-за чего при отсутствии явных requests в манифестах Pod квота по requests.cpu/requests.memory может быть внезапно исчерпана несколькими "незаметными" объектами, если квота считает по другим полям, или наоборот — поды без requests вовсе не создадутся, если ResourceQuota требует явного указания ресурсов; устанавливать значения LimitRange по умолчанию, не соответствующие реальным потребностям большинства приложений namespace, что приводит к массовым OOMKilled после включения политики.