СТАН ФУНКЦІОНАЛУ:
| Назва ресурсу | Опис |
| ------------- | ---- |
| `requests.ephemeral-storage` | У всіх Podʼах у просторі імен, сума запитів на локальне тимчасове сховище не може перевищувати це значення. |
| `limits.ephemeral-storage` | У всіх Podʼах у просторі імен, сума лімітів на локальне тимчасове сховище не може перевищувати це значення. |
| `ephemeral-storage` | Те саме, що і `requests.ephemeral-storage`. |
Kubernetes v1.8 [alpha]
Примітка:
При використанні середовища виконання контейнерів CRI, логи контейнера будуть зараховуватися до квоти тимчасового сховища. Це може призвести до неочікуваного видалення Podʼів, які вичерпали свої квоти на сховище.
Дивіться Архітектура логів для деталей.
СТАН ФУНКЦІОНАЛУ:
Ви можете використовувати [область дії квоти](#quota-scopes) `CrossNamespacePodAffinity`, щоб обмежити, які простори імен можуть мати Podʼи з термінами спорідненості, які перетинають простори імен. Зокрема, вона контролює, яким Podʼам дозволено встановлювати поля `namespaces` або `namespaceSelector` у термінах спорідненості ([(anti)affinity terms](/docs/concepts/scheduling-eviction/assign-pod-node)).
Бажано уникати використання термінів спорідненості, які перетинають простори імен, оскільки Pod з обмеженнями анти-спорідненості може заблокувати Podʼи з усіх інших просторів імен від планування в області відмов.
За допомогою цієї області ви (як адміністратор кластера) можете запобігти певним просторам імен (наприклад, `foo-ns` у наведеному нижче прикладі) використання Podʼів, які використовують спорідненість між просторами імен. Ви можете налаштувати це, створивши обʼєкт ResourceQuota в цьому просторі імен з областю `CrossNamespacePodAffinity` та жорстким обмеженням 0:
```yaml
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` на шлях до наступного конфігураційного файлу:
```yaml
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 {#resource-quota-per-priorityclass}
Kubernetes v1.24 [stable]
СТАН ФУНКЦІОНАЛУ:
ResourceQuota з областю дії PriorityClass відповідає тільки тим Podʼам, які мають певний [клас пріоритету](/docs/concepts/scheduling-eviction/pod-priority-preemption), і тільки в тому випадку, якщо будь-який `scopeSelector` у специфікації квоти вибирає певний Pod.
Podʼи можуть бути створені з певним [пріоритетом](/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority). Ви можете контролювати споживання системних ресурсів подом на основі його пріоритету, використовуючи поле `scopeSelector` у специфікації квоти.
Коли квота обмежена для PriorityClass за допомогою поля `scopeSelector`, ResourceQuota може відстежувати (і обмежувати) тільки такі ресурси:
* `pods`
* `cpu`
* `memory`
* `ephemeral-storage`
* `limits.cpu`
* `limits.memory`
* `limits.ephemeral-storage`
* `requests.cpu`
* `requests.memory`
* `requests.ephemeral-storage`
#### Приклад {#quota-scope-priorityclass-example}
Цей приклад створює ResourceQuota, яка відповідає Podʼам з певними пріоритетами. Приклад працює наступним чином:
- Поди в кластері мають один з трьох [класів пріоритету](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass), "low", "medium", "high".
- Якщо ви хочете спробувати це, використовуйте тестовий кластер і налаштуйте ці три класи пріоритету перед продовженням.
- Один обʼєкт квоти створюється для кожного пріоритету.
Перегляньте цей набір ResourceQuotas:
Kubernetes v1.17 [stable]
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"]
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
apiVersion: v1
kind: ResourceQuota
metadata:
name: pods-cluster-services
spec:
scopeSelector:
matchExpressions:
- operator : In
scopeName: PriorityClass
values: ["cluster-services"]
СТАН ФУНКЦІОНАЛУ:
Ця область відстежує лише квоту, спожиту PersistentVolumeClaims.
PersistentVolumeClaims можуть бути створені з конкретним [VolumeAttributesClass](/docs/concepts/storage/volume-attributes-classes/), і можуть бути змінені після створення. Ви можете контролювати споживання PVC ресурсів на основі асоційованих VolumeAttributesClasses, використовуючи поле `scopeSelector` у специфікації квоти.
PVC посилається на асоційований VolumeAttributesClass за наступними полями:
* `spec.volumeAttributesClassName`
* `status.currentVolumeAttributesClassName`
* `status.modifyVolumeStatus.targetVolumeAttributesClassName`
Відповідна ResourceQuota підбирається і використовується тільки в тому випадку, якщо ResourceQuota має `scopeSelector`, який вибирає PVC.
Коли квота обмежена для класу атрибутів томів за допомогою поля `scopeSelector`, обʼєкт квоти обмежується лише відстеженням наступних ресурсів:
* `persistentvolumeclaims`
* `requests.storage`
Детальніше про це читайте в розділі [Обмеження використання сховища](/docs/tasks/administer-cluster/limit-storage-consumption/).
## Що далі
- Перегляньте [детальний приклад використання квоти ресурсів](/docs/tasks/administer-cluster/quota-api-object/).
- Прочитайте про [довідник API](/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) ResourceQuota.
- Дізнайтеся про [LimitRanges](/docs/concepts/policy/limit-range/)
- Ви можете прочитати історичний [ResourceQuota design document](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_resource_quota.md) для отримання додаткової інформації.
- Ви також можете ознайомитися з [Проєктним документом підтримки квот для класів пріоритетів](https://git.k8s.io/design-proposals-archive/scheduling/pod-priority-resourcequota.md).
Kubernetes v1.36 [stable](стандартно увімкнено)