☰

Гарантия ResourceQuota в пространстве имен

tag-icon • tag-icon kubernetes
Гарантия ResourceQuota в пространстве имен

Я использую кластер, который совместно используется несколькими командами, и хотел бы гарантировать каждой команде минимальный объем ресурсов, особенно памяти.

ПослеинструкцииЯ попробовал использовать следующее в их пространстве имен:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-quota
spec:
  hard:
    requests.memory: 8Gb

Однако, прочитав больше документов, выясняется, что это не гарантирует, что у них будет 8 ГБ памяти для их pod. Это просто означает, что сумма requests.memoryзначений их pod не может превышать 8 ГБ. Возможно, что у них может быть установлено 8 ГБ, как указано выше, они будут использовать только 4 ГБ и не смогут создать новый pod, если кластер был исчерпан в другом месте, а новый pod не может быть запланирован.

Также, например, я могу создать ResourceQuotaсо requests.memoryзначением 16Gi в кластере с общим объемом памяти всего 8Gi.

Можно ли как-то гарантировать команде фиксированный объем памяти для использования только ею?

решение1

Это просто означает, что сумма запросов их модулей памяти не может превышать 8 ГБ.

Да, это логика ResourceQuota.Понимание квот ресурсов:

Квоты ресурсов работают следующим образом:

  • Пользователи размещают запросы на вычислительные ресурсы на своих модулях.Сумма всех запросов ресурсов по всем модулям в одном пространстве имен не должна превышать жесткого ограничения ресурсов в любом документе квоты ресурсов для пространства имен.Обратите внимание, что мы использовали для проверки квоты ресурсов сумму ограничений ресурсов модулей, но это было изменено для использования запросов ресурсов. Обратная совместимость для ранее созданных модулей сохраняется, поскольку у модулей, которые указывают только ограничение ресурсов, запросы ресурсов по умолчанию соответствуют их определенным ограничениям. Пользователь платит только за ресурсы, которые он запрашивает в квоте ресурсов, а не за свои ограничения, поскольку запрос — это минимальный объем ресурсов, гарантированный кластером во время планирования. Для получения дополнительной информации о превышении лимита см. compute-resources.

  • Если создание модуля приведет к тому, что пространство имен превысит какие-либо ограничения, указанные в квоте ресурсов для этого пространства имен, то запрос завершится ошибкой с кодом состояния HTTP 403 FORBIDDEN.

  • Если квота включена в пространстве имен, а пользователь не указывает запросы в модуле для каждого из ресурсов, для которых включена квота, то POST-запрос модуля завершится ошибкой с кодом состояния HTTP 403 FORBIDDEN. Подсказка: используйте контроллер допуска LimitRange для принудительной установки значений лимитов по умолчанию (тогда запросы ресурсов будут равны лимитам по умолчанию, см. контроллер допуска) перед проверкой квоты, чтобы избежать этой проблемы.

Однако статья немного расширяет случаи, когда нужно разделять ресурсы по отдельности. И это не то, что уже реализовано..

Квота и емкость кластера: Иногда могут потребоваться более сложные политики, такие как:

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

Такие политики можно реализовать, используя ResourceQuota в качестве строительного блока, написав «контроллер», который следит за использованием квоты и корректирует жесткие ограничения квоты для каждого пространства имен в соответствии с другими сигналами.

Я предполагаю, что вам нужно написать собственную логику в собственном контроллере.

Пожалуйста, посмотрите также наКак заставить пространства имен Kubernetes иметь ResourceQuotas с помощью OPA

Связанный контент