Квоти ресурсів

Коли декілька користувачів або команд спільно використовують кластер з фіксованою кількістю вузлів, є можливість, що одна команда може використовувати більше, ніж свою справедливу частку ресурсів.

Квоти ресурсів є інструментом для адміністраторів для розвʼязання цієї проблеми.

Квота ресурсів, визначена обʼєктом ResourceQuota, надає обмеження, які обмежують загальне споживання ресурсів у просторі імен. ResourceQuota також може обмежувати кількість обʼєктів, які можуть бути створені в просторі імен за типом API, так само як й загальний обсяг ресурсів інфраструктури які можуть бути спожиті обʼєктами API у цьому просторі імен.

Як працює ResourceQuotas в Kubernetes

ResourceQuotas працюють наступним чином:

• Різні команди працюють у різних просторах імен. Це може бути забезпечено з використанням RBAC або будь-яким іншим механізмом авторизації.

• Адміністратор кластера створює принаймні одну квоту ресурсів для кожного простору імен.

  • Щоб переконатися, що вимоги залишаються в силі, адміністратор кластера повинен також обмежити доступ до видалення або оновлення наприклад, визначивши ValidatingAdmissionPolicy.

• Користувачі створюють ресурси (Podʼи, Serviceʼи тощо) у просторі імен, і система квот відстежує використання, щоб забезпечити, що воно не перевищує жорсткі обмеження ресурсів, визначені в ResourceQuota.

  Ви можете застосувати діапазон до ResourceQuota, щоб обмежити сферу її застосування,

• Якщо створення або оновлення ресурсу порушує обмеження квоти, запит буде відхилено панеллю управління з HTTP кодом стану 403 Forbidden з повідомленням, яке пояснює обмеження, що було б порушено.

• Якщо квоти включені в простір імен для ресурсів, таких як cpu та memory, користувачі повинні вказати запити або ліміти для цих значень під час визначення Podʼів; інакше, система квот може відхилити створення Podʼа.

  Дивіться посібник по квотам ресурсів для прикладу того, як уникнути цієї проблеми.

Часто ви не створюєте Podʼи безпосередньо; наприклад, ви зазвичай створюєте обʼєкт керування робочим навантаженням, такий як Deployment. Якщо ви створюєте Deployment, який намагається використати більше ресурсів, ніж доступно, створення Deployment (або іншого обʼєкта керування робочим навантаженням) буде успішним, але Deployment може бути не в змозі отримати доступ до всіх керовані ним Podʼи для свого існування. У цьому випадку ви можете перевірити стан Deployment, наприклад, за допомогою kubectl describe, щоб дізнатися, що сталося.

• Для ресурсів cpu та memory, квоти ресурсів забезпечують, що кожен (новий) Pod у цьому просторі імен встановлює ліміт для цього ресурсу. Якщо ви встановлюєте квоту ресурсів у просторі імен для cpu або memory, ви, і інші клієнти, повинні вказати або requests, або limits для цього ресурсу, для кожного нового Podʼа, який ви створюєте. Якщо ви цього не робите, панель управління може відхилити допуск для цього Podʼа.
• Для інших ресурсів: ResourceQuota працює та ігнорує Podʼи в просторі імен, які не встановлюють ліміт або запит для цього ресурсу. Це означає, що ви можете створити новий Pod без обмеження/запиту тимчасового сховища, якщо квота ресурсів обмежує тимчасове сховище цього простору імен. Ви можете використовувати LimitRange для автоматичного встановлення стандартних запитів для цих ресурсів.

Назва обʼєкта ResourceQuota повинна бути дійсним піддоменом DNS.

Приклади політик, які можна створити за допомогою просторів імен та квот, такі:

• У кластері з місткістю 32 ГБ ОЗП та 16 ядрами, дозвольте команді A використовувати 20 ГБ та 10 ядер, дозвольте команді B використовувати 10 ГБ та 4 ядра, і залиште 2 ГБ та 2 ядра у резерві на майбутнє.
• Обмежте простір імен "testing" використанням 1 ядра та 1 ГБ ОЗП. Дозвольте простору імен "production" використовувати будь-який обсяг.

У випадку, коли загальна місткість кластера менше суми квот просторів імен, може виникнути конфлікт за ресурси. Це обробляється за принципом "хто перший прийшов, той і молотить" (FIFO).

Увімкнення квоти ресурсів

Підтримка квоти ресурсів є типово увімкненою для багатьох дистрибутивів Kubernetes. Вона увімкнена, коли прапорець --enable-admission-plugins= API serverʼа має ResourceQuota серед своїх аргументів.

Квота ресурсів застосовується в певному просторі імен, коли у цьому просторі імен є ResourceQuota.

Типи квот на ресурси

Механізм ResourceQuota дозволяє застосовувати різні види обмежень. У цьому розділі описано типи обмежень, які можна застосовувати.

Квота на інфраструктурні ресурси

Ви можете обмежити загальну суму обчислювальних ресурсів, які можуть бути запитані в певному просторі імен.

Підтримуються наступні типи ресурсів:

Квота для розширених ресурсів

Крім ресурсів, згаданих вище, в релізі 1.10 було додано підтримку квоти для розширених ресурсів.

Оскільки перевищення не дозволяється для розширених ресурсів, немає сенсу вказувати як requests, так і limits для одного й того ж розширеного ресурсу у квоті. Таким чином, для розширених ресурсів дозволяються лише елементи квоти з префіксом requests..

Візьмімо ресурс GPU як приклад. Якщо імʼя ресурсу — nvidia.com/gpu, і ви хочете обмежити загальну кількість запитаних GPU в просторі імен до 4, ви можете визначити квоту так:

• requests.nvidia.com/gpu: 4

Дивіться Перегляд та встановлення квот для більш детальної інформації.

Квота для запитів на ресурси DRA

Запити на ресурси DRA (Dynamic Resource Allocation) можуть запитувати ресурси DRA за класом пристроїв. Наприклад, для класу пристроїв з назвою examplegpu, якщо ви хочете обмежити загальну кількість GPU, запитуваних в просторі імен, до 4, ви можете визначити квоту наступним чином:

• examplegpu.deviceclass.resource.k8s.io/devices: 4

Коли увімкнено Розширений розподіл ресурсів за допомогою DRA, той самий клас пристроїв із назвою examplegpu можна запитувати через розширений ресурс або явно, коли вказано поле ExtendedResourceName класу пристроїв, наприклад, example.com/gpu, тоді ви можете визначити квоту таким чином:

• requests.example.com/gpu: 4

або неявно, використовуючи похідне імʼя розширеного ресурсу від імені класу пристрою examplegpu, ви можете визначити квоту наступним чином:

• requests.deviceclass.resource.kubernetes.io/examplegpu: 4

Усі пристрої, запитувані з вимог до ресурсів або розширених ресурсів, враховуються у всіх трьох квотах, перелічених вище. Квота розширеного ресурсу, наприклад requests.example.com/gpu: 4, також враховує пристрої, надані втулком пристрою.

Дивіться Перегляд та встановлення квот для більш детальної інформації.

Квота ресурсів зберігання

Ви можете обмежити загальну суму ресурсів зберігання, які можуть бути запитані в певному просторі імен.

Крім того, ви можете обмежити споживання ресурсів зберігання на основі повʼязаного StorageClass.

Наприклад ви хочете обмежити зберігання з StorageClass gold окремо від StorageClass bronze, ви можете визначити квоту так:

• gold.storageclass.storage.k8s.io/requests.storage: 500Gi
• bronze.storageclass.storage.k8s.io/requests.storage: 100Gi

Квота для локального тимчасового зберігання

Квота на кількість обʼєктів

Ви можете встановити квоту на загальну кількість одного конкретного типу ресурса у API Kubernetes, використовуючи наступний синтаксис:

• count/<resource>.<group> для ресурсів API з груп non-core
• count/<resource> для ресурсів API з групи core

Наприклад, PodTemplate API входить до групи основних API, тому якщо ви хочете обмежити кількість обʼєктів PodTemplate в просторі імен, використовуйте count/podtemplates.

Такі типи квот корисні для захисту від вичерпання сховища панелі управління. Наприклад, ви можете обмежити кількість Secrets на сервері, враховуючи їх великий розмір. Занадто багато Secrets у кластері можуть фактично заважати запуску серверів і контролерів. Ви можете встановити квоту для Jobs, щоб захиститися від неправильно налаштованого CronJob. CronJobs, які створюють занадто багато завдань в просторі імен, можуть призвести до відмови в обслуговуванні.

Якщо ви визначаєте квоту таким чином, вона застосовується до API Kubernetes, які є частиною API-сервера, та до будь-яких власних ресурсів, що підтримуються CustomResourceDefinition. Наприклад, щоб створити квоту на власний ресурс widgets в API-групі example.com, використовуйте count/widgets.example.com. Якщо ви використовуєте агрегацію API для додавання додаткових власних API, які не визначені як CustomResourceDefinitions, основна панель управління Kubernetes не застосовує квоту для агрегованого API. Очікується, що сервер розширення API забезпечить застосування квоти, якщо це доречно для власного API користувача.

Загальний синтаксис

Це список загальних прикладів типів обʼєктів, які ви можете захотіти підпорядкувати квоті на кількість обʼєктів, перелічені рядками конфігурації, які ви будете використовувати.

• count/pods
• count/persistentvolumeclaims
• count/services
• count/secrets
• count/configmaps
• count/deployments.apps
• count/replicasets.apps
• count/statefulsets.apps
• count/jobs.batch
• count/cronjobs.batch

Спеціалізований синтаксис

Існує інший синтаксис, який дозволяє встановити такий же тип квоти для певних ресурсів.

Підтримуються наступні типи:

Наприклад, квота pods рахує та обмежує максимальну кількість Podʼів, створених у одному просторі імен, що не перебувають в стані завершення роботи. Ви можете встановити квоту pods у просторі імен, щоб уникнути випадку, коли користувач створює багато невеликих Podʼів і вичерпує запаси IP-адрес Podʼів кластері.

Ви можете знайти більше прикладів у розділі Перегляд і налаштування квот.

Перегляд та встановлення квот

kubectl підтримує створення, оновлення та перегляд квот:

kubectl create namespace myspace

cat <<EOF > compute-resources.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    requests.cpu: "1"
    requests.memory: "1Gi"
    limits.cpu: "2"
    limits.memory: "2Gi"
    requests.nvidia.com/gpu: 4
EOF

kubectl create -f ./compute-resources.yaml --namespace=myspace

cat <<EOF > object-counts.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
spec:
  hard:
    configmaps: "10"
    persistentvolumeclaims: "4"
    pods: "4"
    replicationcontrollers: "20"
    secrets: "10"
    services: "10"
    services.loadbalancers: "2"
EOF

kubectl create -f ./object-counts.yaml --namespace=myspace

kubectl get quota --namespace=myspace

NAME                    AGE
compute-resources       30s
object-counts           32s

kubectl describe quota compute-resources --namespace=myspace

Name:                    compute-resources
Namespace:               myspace
Resource                 Used  Hard
--------                 ----  ----
limits.cpu               0     2
limits.memory            0     2Gi
requests.cpu             0     1
requests.memory          0     1Gi
requests.nvidia.com/gpu  0     4

kubectl describe quota object-counts --namespace=myspace

Name:                   object-counts
Namespace:              myspace
Resource                Used    Hard
--------                ----    ----
configmaps              0       10
persistentvolumeclaims  0       4
pods                    0       4
replicationcontrollers  0       20
secrets                 1       10
services                0       10
services.loadbalancers  0       2

kubectl також підтримує квоту кількості обʼєктів для всіх стандартних ресурсів з простором імен, використовуючи синтаксис count/<resource>.<group>:

kubectl create namespace myspace

kubectl create quota test --hard=count/deployments.apps=2,count/replicasets.apps=4,count/pods=3,count/secrets=4 --namespace=myspace

kubectl create deployment nginx --image=nginx --namespace=myspace --replicas=2

kubectl describe quota --namespace=myspace

Name:                         test
Namespace:                    myspace
Resource                      Used  Hard
--------                      ----  ----
count/deployments.apps        1     2
count/pods                    2     3
count/replicasets.apps        1     4
count/secrets                 1     4

Квота та ємність кластера

ResourceQuotas не залежать від ємності кластера. Вони виражаються в абсолютних одиницях. Отже, якщо ви додаєте вузли до свого кластера, це не означає, що кожен простір імен автоматично отримує можливість споживати більше ресурсів.

Іноді можуть знадобитися більш складні політики, такі як:

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

Такі політики можуть бути реалізовані за допомогою ResourceQuotas як будівельних блоків, шляхом написання "контролера", який спостерігає за використанням квот і коригує жорсткі ліміти кожного простору імен відповідно до інших сигналів.

Зверніть увагу, що квота ресурсів ділить загальні ресурси кластера, але не створює обмежень навколо вузлів: Podʼи з кількох просторів імен можуть працювати на одному й тому ж вузлі.

Області дії квоти

Кожна квота може мати повʼязаний набір scopes. Квота вимірюватиме використання ресурсу лише в тому випадку, якщо вона відповідає перетину перерахованих областей.

Коли до квоти додається область, вона обмежує кількість ресурсів, які вона підтримує, тими, які стосуються цієї області. Ресурси, вказані у квоті поза дозволеним набором, призводять до помилки перевірки.

Kubernetes 1.35 підтримує наступні області дії квоти:

ResourceQuotas з набором областей дії також можуть мати опціональне поле scopeSelector. Ви визначаєте один або декілька виразів відповідності, які вказують operators і, якщо це доречно, набір values для відповідності. Наприклад:

  scopeSelector:
    matchExpressions:
      - scopeName: BestEffort # Відповідає podʼам, які мають найкращу якість обслуговування
        operator: Exists # опціонально; "Exists" мається на увазі для області BestEffort

scopeSelector підтримує наступні значення у полі operator:

• In
• NotIn
• Exists
• DoesNotExist

Якщо оператором є In або NotIn, поле values повинно мати щонайменше одне значення. Наприклад:

  scopeSelector:
    matchExpressions:
      - scopeName: PriorityClass
        operator: In
        values:
          - middle

Якщо оператором є Exists або DoesNotExist, поле values НЕ повинно бути вказане.

Область дії для Podʼів Best effort

Ця область дії відстежує лише квоту, спожиту Podʼами. Вона відповідає лише Podʼам, які мають QoS клас Best effort.

operator для scopeSelector повинен бути Exists.

Область дії для Podʼів Not-best-effort

Ця область дії відстежує лише квоту, спожиту Podʼами. Вона відповідає лише Podʼам, які мають QoS клас Guaranteed або Burstable.

operator для scopeSelector повинен бути Exists.

Область дії для Podʼів Non-terminating

Ця область дії відстежує лише квоту, спожиту Podʼами, які не завершуються. operator для scopeSelector повинен бути Exists.

Pod не вважається завершеним, якщо поле .spec.activeDeadlineSeconds не встановлено.

Ви можете використовувати ResourceQuota з цією областю дії для управління наступними ресурсами:

• count.pods
• pods
• cpu
• memory
• requests.cpu
• requests.memory
• limits.cpu
• limits.memory

Область дії Podʼів Terminating

Ця область дії відстежує лише квоту, спожиту Podʼами, які завершуються. operator для scopeSelector повинен бути Exists.

Pod вважається завершеним, якщо поле .spec.activeDeadlineSeconds встановлено на будь-яке число.

Ви можете використовувати ResourceQuota з цією областю дії для управління наступними ресурсами:

• count.pods
• pods
• cpu
• memory
• requests.cpu
• requests.memory
• limits.cpu
• limits.memory

Область дії перехресних термінів спорідненості між просторами імен

Ви можете використовувати область дії квоти CrossNamespacePodAffinity, щоб обмежити, які простори імен можуть мати Podʼи з термінами спорідненості, які перетинають простори імен. Зокрема, вона контролює, яким Podʼам дозволено встановлювати поля namespaces або namespaceSelector у термінах спорідненості ((anti)affinity terms).

Бажано уникати використання термінів спорідненості, які перетинають простори імен, оскільки Pod з обмеженнями анти-спорідненості може заблокувати Podʼи з усіх інших просторів імен від планування в області відмов.

За допомогою цієї області ви (як адміністратор кластера) можете запобігти певним просторам імен (наприклад, foo-ns у наведеному нижче прикладі) використання Podʼів, які використовують спорідненість між просторами імен. Ви можете налаштувати це, створивши обʼєкт ResourceQuota в цьому просторі імен з областю CrossNamespacePodAffinity та жорстким обмеженням 0:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: disable-cross-namespace-affinity
  namespace: foo-ns
spec:
  hard:
    pods: "0"
  scopeSelector:
    matchExpressions:
    - scopeName: CrossNamespacePodAffinity
      operator: Exists

Якщо ви хочете заборонити стандартне використання namespaces та namespaceSelector, і дозволити це лише для певних просторів імен, ви можете налаштувати CrossNamespacePodAffinity як обмежений ресурс, встановивши прапорець kube-apiserver --admission-control-config-file на шлях до наступного конфігураційного файлу:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: "ResourceQuota"
  configuration:
    apiVersion: apiserver.config.k8s.io/v1
    kind: ResourceQuotaConfiguration
    limitedResources:
    - resource: pods
      matchScopes:
      - scopeName: CrossNamespacePodAffinity
        operator: Exists

За такої конфігурації Podʼи можуть використовувати namespaces та namespaceSelector у термінах спорідненості тільки якщо простір імен, в якому вони створені, має обʼєкт квоти ресурсів з областю CrossNamespacePodAffinity та жорстким обмеженням, більшим або рівним кількості Podʼів, що використовують ці поля.

Область дії PriorityClass

ResourceQuota з областю дії PriorityClass відповідає тільки тим Podʼам, які мають певний клас пріоритету, і тільки в тому випадку, якщо будь-який scopeSelector у специфікації квоти вибирає певний Pod.

Поди можуть бути створені з певним пріоритетом. Ви можете контролювати споживання системних ресурсів подом на основі його пріоритету, використовуючи поле scopeSelector у специфікації квоти.

Коли квота обмежена для PriorityClass за допомогою поля scopeSelector, ResourceQuota може відстежувати (і обмежувати) тільки такі ресурси:

• pods
• cpu
• memory
• ephemeral-storage
• limits.cpu
• limits.memory
• limits.ephemeral-storage
• requests.cpu
• requests.memory
• requests.ephemeral-storage

Приклад

Цей приклад створює ResourceQuota, яка відповідає Podʼам з певними пріоритетами. Приклад працює наступним чином:

• Поди в кластері мають один з трьох класів пріоритету, "low", "medium", "high".
  • Якщо ви хочете спробувати це, використовуйте тестовий кластер і налаштуйте ці три класи пріоритету перед продовженням.
• Один обʼєкт квоти створюється для кожного пріоритету.

Перегляньте цей набір ResourceQuotas:

policy/quota.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-high
spec:
  hard:
    cpu: "1000"
    memory: "200Gi"
    pods: "10"
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values: ["high"]
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-medium
spec:
  hard:
    cpu: "10"
    memory: "20Gi"
    pods: "10"
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values: ["medium"]
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-low
spec:
  hard:
    cpu: "5"
    memory: "10Gi"
    pods: "10"
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values: ["low"]

Застосуйте YAML за допомогою kubectl create.

kubectl create -f https://k8s.io/examples/policy/quota.yaml

resourcequota/pods-high created
resourcequota/pods-medium created
resourcequota/pods-low created

Перевірте, що квота Used дорівнює 0 , за допомогою команди kubectl describe quota.

kubectl describe quota

Name:       pods-high
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     1k
memory      0     200Gi
pods        0     10


Name:       pods-low
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     5
memory      0     10Gi
pods        0     10


Name:       pods-medium
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     10
memory      0     20Gi
pods        0     10

Створіть под з пріоритетом "high".

policy/high-priority-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: high-priority
spec:
  containers:
  - name: high-priority
    image: ubuntu
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo hello; sleep 10;done"]
    resources:
      requests:
        memory: "10Gi"
        cpu: "500m"
      limits:
        memory: "10Gi"
        cpu: "500m"
  priorityClassName: high

Створіть Pod:

kubectl create -f https://k8s.io/examples/policy/high-priority-pod.yaml

Перевірте чи змінився статус "Used" для квоти "high" пріоритету, pods-high, і чи залишилися інші дві квоти незмінними.

kubectl describe quota

Name:       pods-high
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         500m  1k
memory      10Gi  200Gi
pods        1     10


Name:       pods-low
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     5
memory      0     10Gi
pods        0     10


Name:       pods-medium
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     10
memory      0     20Gi
pods        0     10

Типове обмеження споживання PriorityClass

Може бути бажаним, щоб Podʼи з певного пріоритету, наприклад, "cluster-services", дозволялися в просторі імен, лише якщо існує відповідний обʼєкт квоти.

За допомогою цього механізму оператори можуть обмежувати використання певних високопріоритетних класів до обмеженої кількості просторів імен, і не кожний простір імен зможе стандартно споживати ці класи пріоритету.

Для цього потрібно використовувати прапорець --admission-control-config-file kube-apiserver для передачі шляху до наступного конфігураційного файлу:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: "ResourceQuota"
  configuration:
    apiVersion: apiserver.config.k8s.io/v1
    kind: ResourceQuotaConfiguration
    limitedResources:
    - resource: pods
      matchScopes:
      - scopeName: PriorityClass
        operator: In
        values: ["cluster-services"]

Потім створіть обʼєкт квоти ресурсів у просторі імен kube-system:

policy/priority-class-resourcequota.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-cluster-services
spec:
  scopeSelector:
    matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["cluster-services"]

kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system

resourcequota/pods-cluster-services created

У цьому випадку створення Podʼа буде дозволено, якщо:

1. Параметр priorityClassName Podʼа не вказано.
2. Параметр priorityClassName Podʼа вказано на значення, відмінне від cluster-services.
3. Параметр priorityClassName Podʼа встановлено на cluster-services, він має бути створений в просторі імен kube-system і пройти перевірку обмеження ресурсів.

Запит на створення Podʼа буде відхилено, якщо його priorityClassName встановлено на cluster-services і він має бути створений в просторі імен, відмінному від kube-system.

Область дії VolumeAttributesClass

Ця область діє лише на квоти, спожиті PersistentVolumeClaims.

PersistentVolumeClaims можуть бути створені з конкретним VolumeAttributesClass, і можуть бути змінені після створення. Ви можете контролювати споживання PVC ресурсів на основі асоційованих VolumeAttributesClasses, використовуючи поле scopeSelector у специфікації квоти.

PVC посилається на асоційований VolumeAttributesClass за наступними полями:

• spec.volumeAttributesClassName
• status.currentVolumeAttributesClassName
• status.modifyVolumeStatus.targetVolumeAttributesClassName

Відповідна ResourceQuota підбирається і використовується тільки в тому випадку, якщо ResourceQuota має scopeSelector, який вибирає PVC.

Коли квота обмежена для класу атрибутів томів за допомогою поля scopeSelector, обʼєкт квоти обмежується лише відстеженням наступних ресурсів:

• persistentvolumeclaims
• requests.storage

Детальніше про це читайте в розділі Обмеження використання сховища.

Що далі

• Перегляньте детальний приклад використання квоти ресурсів.
• Прочитайте про довідник API ResourceQuota.
• Дізнайтеся про LimitRanges
• Ви можете прочитати історичний ResourceQuota design document для отримання додаткової інформації.
• Ви також можете ознайомитися з Проєктним документом підтримки квот для класів пріоритетів.