Концепции Kubernetes — Политики — Ограниченная область применения

Ограниченный диапазон

По умолчанию Используя квоты ресурсов Kubernetes, администраторы (также известные как операторы кластера) могут ограничивать использование и создание ресурсов кластера в указанном пространстве имен. Внутри пространства имен под может использовать ЦП и память в объеме, определяемом квотами ресурсов пространства имен. Как оператор кластера или администратор уровня пространства имен вы также можете беспокоиться о том, чтобы один под не монополизировал все доступные ресурсы в пространстве имен.

LimitRange — это объект политики, который ограничивает объем выделяемых ресурсов (как лимит, так и запрос), который можно указать для каждого применимого класса объектов в пространстве имен (например, Pod или PersistentVolumeClaim).
 

Объект  LimitRange  предоставляет ограничения, которые могут:

• Установите минимальные и максимальные ограничения на использование ресурсов для каждого модуля или контейнера в пространстве имен.
• Установите ограничения на минимальный и максимальный размер хранилища, на которые может претендовать каждое PersistentVolumeClaim в пространстве имен.
• Реализует контроль над отношением запрошенного значения ресурса к его ограниченному значению в пространстве имен.
• Установите значение приложения/ограничения по умолчанию для вычислительных ресурсов в пространстве имен и автоматически внедрите его в несколько контейнеров во время выполнения.

Когда в пространстве имен есть объект LimitRange, ограничение LimitRange будет применяться в этом пространстве имен.

Имя LimitRange должно быть действительным субдоменом DNS.
 

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

• Администратор создает объект в пространстве имен  LimitRange .
• Пользователи создают (или пытаются создать) такие объекты, как Pod и PersistentVolumeClaims в этом пространстве имен.
• Во-первых, LimitRanger контроллер допуска устанавливает запрос по умолчанию и предельные значения для всех подов (и их контейнеров), для которых не установлены требования к вычислительным ресурсам.
• Во-вторых, его использование отслеживается, чтобы гарантировать, что оно не превышает  каких-либо установленных минимальных, максимальных значений использования ресурсов и коэффициентов использования, которые LimitRange существуют в пространстве имен  .LimitRange
• Если попытка создать или обновить объект (Pod и PersistentVolumeClaim) нарушает  LimitRange ограничение, запрос к серверу API завершается с ошибкой с кодом состояния HTTP  403 Forbidden и сообщением, описывающим, какое ограничение было нарушено.
• LimitRange Если вы добавляете и включаете ограничения для  cpu и  memory других связанных с вычислениями ресурсов в пространстве имен  , вы должны указать запрошенное использование и ограниченное использование этих значений. В противном случае система откажется создавать Pod.
• LimitRange Проверка выполняется только на этапе приема подов, а не для запущенных подов. Если вы добавите или измените LimitRange, существующие поды в пространстве имен останутся без изменений.
• LimitRange Не определено, какое значение по умолчанию применяется , если в пространстве имен существуют два или более объекта  .

Pod LimitRange и проверки допуска

LimitRange  Применяемые значения по умолчанию не проверяются на согласованность. Это означает, что  значение по умолчанию для LimitRange набора  ограничений может быть меньше, чем  значение запроса  , указанное для контейнера в спецификации, отправленной клиентом на сервер API  . Если это произойдет, в конечном итоге Pod не сможет запланировать.

Например, вы определяете его, используя следующий манифест  LimitRange:

 концепции/политика/лимит-диапазон/проблематический-лимит-диапазон.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default: # 此处定义默认限制值
      cpu: 500m
    defaultRequest: # 此处定义默认请求值
      cpu: 500m
    max: # max 和 min 定义限制范围
      cpu: "1"
    min:
      cpu: 100m
    type: Container

и Pod, который объявляет запрос ресурсов ЦП как,  700m но не объявляет ограничение:

 concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml​

apiVersion: v1
kind: Pod
metadata:
  name: example-conflict-with-limitrange-cpu
spec:
  containers:
  - name: demo
    image: registry.k8s.io/pause:2.0
    resources:
      requests:
        cpu: 700m

тогда Pod не будет запланирован и выйдет из строя с ошибкой, похожей на:

Pod "example-conflict-with-limitrange-cpu" is invalid: spec.containers[0].resources.requests: Invalid value: "700m": must be less than or equal to cpu limit

Если вы установите оба параметра  request и  , новые модули будут успешно запланированы limitдаже с одним и тем же параметром  :LimitRange

 ​concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml

apiVersion: v1
kind: Pod
metadata:
  name: example-no-conflict-with-limitrange-cpu
spec:
  containers:
  - name: demo
    image: registry.k8s.io/pause:2.0
    resources:
      requests:
        cpu: 700m
      limits:
        cpu: 700m

Пример ограничения ресурсов

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

• В кластере с двумя узлами, 8 гигабайтами памяти и 16 ядрами ограничьте количество подов пространства имен для 100 млн единиц с максимальным объемом ЦП 500 млн и подайте заявку на 200 Ми с максимальным объемом памяти 600 Ми.
• Определите лимит ЦП по умолчанию и значение потребности в 150 м и значение потребности в памяти по умолчанию 300Mi для контейнеров без значений потребности в ЦП и памяти в спецификации.

Конкуренция за ресурсы может возникнуть, если общее ограничение пространства имен меньше суммы ограничений Pod или Container. В этом случае ни контейнер, ни под не будут созданы.

Ни конфликты, ни изменения в LimitRange не повлияют на уже созданные ресурсы.