Політики

• 1: Обмеження діапазонів
• 2: Квоти ресурсів
• 3: Обмеження та резервування ID процесів
• 4: Менеджери ресурсів вузлів

1 - Обмеження діапазонів

Типово контейнери запускаються з необмеженими обчислювальними ресурсами у кластері Kubernetes. Використовуючи квоти ресурсів Kubernetes, адміністратори (оператори кластера) можуть обмежити споживання та створення ресурсів кластера (таких як час ЦП, памʼять та постійне сховище) у визначеному namespace. У межах простору імен Pod може використовувати стільки ЦП та памʼяті, скільки дозволяють ResourceQuotas, що застосовуються до цього простору імен. Як оператору кластера або адміністратору на рівні простору імен вам також може бути важливо переконатися, що один обʼєкт не може монополізувати всі доступні ресурси у просторі імен.

LimitRange — це політика обмеження виділення ресурсів (ліміти та запити), яку можна вказати для кожного відповідного типу обʼєкта (такого як Pod або PersistentVolumeClaim) у просторі імен.

LimitRange надає обмеження, які можуть:

• Застосовувати мінімальні та максимальні витрати обчислювальних ресурсів на Pod або Контейнер у просторі імен.
• Застосовувати мінімальний та максимальний запит на сховище для PersistentVolumeClaim у просторі імен.
• Застосовувати співвідношення між запитом та лімітом для ресурсу у просторі імен.
• Встановлювати стандартний запит/ліміт для обчислювальних ресурсів у просторі імен та автоматично вставляти їх у контейнери під час виконання.

Kubernetes обмежує виділення ресурсів для Podʼів у певному просторі імен якщо у цьому просторі назв є хоча б один обʼєкт LimitRange.

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

Обмеження на ліміти ресурсів та запити

• Адміністратор створює обмеження діапазону у просторі імен.
• Користувачі створюють (або намагаються створити) обʼєкти у цьому просторі імен, такі як Podʼи або PersistentVolumeClaims.
• По-перше, контролер допуску LimitRange застосовує типове значення запиту та ліміту для всіх Podʼів (та їхніх контейнерів), які не встановлюють вимоги щодо обчислювальних ресурсів.
• По-друге, LimitRange відстежує використання, щоб забезпечити, що воно не перевищує мінімальне, максимальне та співвідношення ресурсів, визначених в будь-якому LimitRange, присутньому у просторі імен.
• Якщо ви намагаєтеся створити або оновити обʼєкт (Pod або PersistentVolumeClaim), який порушує обмеження LimitRange, ваш запит до сервера API буде відхилено з HTTP-кодом стану 403 Forbidden та повідомленням, що пояснює порушене обмеження.
• Якщо додати LimitRange в простір імен, який застосовується до обчислювальних ресурсів, таких як cpu та memory, необхідно вказати запити або ліміти для цих значень. В іншому випадку система може відхилити створення Podʼа.
• Перевірка LimitRange відбувається тільки на етапі надання дозволу Podʼу, а не на працюючих Podʼах. Якщо ви додаєте або змінюєте LimitRange, Podʼи, які вже існують у цьому просторі імен, залишаються без змін.
• Якщо у просторі імен існує два або більше обʼєкти LimitRange, то не визначено, яке типове значення буде застосовано.

LimitRange та перевірки допуску для Podʼів

LimitRange не перевіряє типово послідовність застосованих значень. Це означає, що стандартні значення для limit, встановлене LimitRange, може бути меншим за значення request, вказане для контейнера в специфікації, яку клієнт надсилає на сервер API. Якщо це станеться, Pod не буде запланованим.

Наприклад, ви визначаєте LimitRange цим маніфестом:

concepts/policy/limit-range/problematic-limit-range.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:3.8
    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, то цей новий Pod буде успішно запланований, навіть з тим самим 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:3.8
    resources:
      requests:
        cpu: 700m
      limits:
        cpu: 700m

Приклади обмежень ресурсів

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

• У кластері з 2 вузлами з місткістю 8 ГБ ОЗП та 16 ядрами обмежте Podʼи в просторі імен на роботу з 100m CPU з максимальним лімітом 500m для CPU та запит 200Mi для памʼяті з максимальним лімітом 600Mi для памʼяті.
• Визначте стандартний ліміт та запит CPU на 150m та стандартний запит памʼяті на 300Mi для контейнерів, що запускаються без запитів ЦП та памʼяті у своїх специфікаціях.

У випадку, коли загальні ліміти простору імен менше суми лімітів Podʼів/Контейнерів, може виникнути конфлікт для ресурсів. У цьому випадку контейнери або Podʼи не будуть створені.

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

Що далі

Для прикладів використання обмежень дивіться:

• як налаштувати мінімальні та максимальні обмеження CPU на простір імен.
• як налаштувати мінімальні та максимальні обмеження памʼяті на простір імен.
• як налаштувати стандартні запити та ліміти CPU на простір імен.
• як налаштувати стандартні запити та ліміти памʼяті на простір імен.
• як налаштувати мінімальні та максимальні обмеження використання сховища на простір імен.
• детальний приклад налаштування квот на простір імен.

Звертайтеся до документа проєкту LimitRanger для контексту та історичної інформації.

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

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

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

Квота ресурсів, визначена обʼєктом 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.

Квота обчислювальних ресурсів

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

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

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

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

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

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

• requests.nvidia.com/gpu: 4

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

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

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

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

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

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

У релізі 1.8, підтримка квоти для локального тимчасового сховища додана як альфа-функція:

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

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

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

Нижче наведено приклад набору ресурсів, які користувачі можуть хотіти обмежити квотою на кількість обʼєктів:

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

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

При використанні такої квоти ресурсів (практично для всіх видів обʼєктів), обʼєкт враховується у квоті, якщо вид обʼєкта існує (визначений) у панелі управління. Ці типи квот корисні для захисту від вичерпання ресурсів зберігання. Наприклад, ви можете хотіти обмежити кількість Secretʼів на сервері, враховуючи їх великий розмір. Занадто багато Secretʼів у кластері може фактично завадити запуску серверів і контролерів. Ви можете встановити квоту для Job, щоб захиститися від погано налаштованого CronJob. CronJobs, які створюють занадто багато Job у просторі імен, можуть призвести до заподіяння відмови в обслуговуванні.

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

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

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

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

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

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

Область BestEffort обмежує квоту відстеження наступним ресурсом:

• pods

Області Terminating, NotTerminating, NotBestEffort та PriorityClass обмежують квоту відстеження наступними ресурсами:

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

Зверніть увагу, що ви не можете вказати як Terminating, так і NotTerminating області в одній й тій же квоті, і ви також не можете вказати як BestEffort, так і NotBestEffort області в одній й тій же квоті.

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

• In
• NotIn
• Exists
• DoesNotExist

При використанні одного з наступних значень як scopeName при визначенні scopeSelector, оператор повинен бути Exists.

• Terminating
• NotTerminating
• BestEffort
• NotBestEffort

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

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

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

Квота ресурсів за PriorityClass

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

Квота має збіг та використовується лише якщо scopeSelector у специфікації квоти вибирає Pod.

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

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

У цьому прикладі створюється обʼєкт квоти та відповідною до нього підходить до Podʼів з певними пріоритетами. Приклад працює наступним чином:

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

Збережіть наступний YAML у файл quota.yaml.

policy/quota.yaml

apiVersion: v1
kind: List
items:
- 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 ./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

Створіть Pod із пріоритетом "high". Збережіть наступний YAML у файл high-priority-pod.yaml.

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

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

kubectl create -f ./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

Квота Pod Affinity між просторами імен

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

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

За допомогою цієї області оператори можуть запобігти певним просторам імен (наприклад, foo-ns у наведеному нижче прикладі) використання Podʼів, які використовують спорідненість між просторами імен, створивши обʼєкт квоти ресурсів в цьому просторі імен з областю 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ʼів, що використовують ці поля.

Квота ресурсів на VolumeAttributesClass

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

PVC посилається на асоційований клас атрибутів тома за допомогою наступних полів:

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

Квота зіставляється і споживається тільки якщо scopeSelector в специфікації квоти вибирає PVC.

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

• persistentvolumeclaims
• requests.storage.

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

• PVC у кластері мають принаймні один з трьох класів атрибутів обсягу: "gold", "silver", "copper".
• Для кожного класу атрибутів тому створюється один обʼєкт квоти.

Збережіть наступний YAML-файл у файлі quota-vac.yaml.

policy/quota-vac.yaml

apiVersion: v1
kind: List
items:
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pvcs-gold
  spec:
    hard:
      requests.storage: "10Gi"
      persistentvolumeclaims: "10"
    scopeSelector:
      matchExpressions:
      - operator: In
        scopeName: VolumeAttributesClass
        values: ["gold"]
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pvcs-silver
  spec:
    hard:
      requests.storage: "20Gi"
      persistentvolumeclaims: "10"
    scopeSelector:
      matchExpressions:
      - operator: In
        scopeName: VolumeAttributesClass
        values: ["silver"]
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pvcs-copper
  spec:
    hard:
      requests.storage: "30Gi"
      persistentvolumeclaims: "10"
    scopeSelector:
      matchExpressions:
      - operator: In
        scopeName: VolumeAttributesClass
        values: ["copper"]

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

kubectl create -f ./quota-vac.yaml

resourcequota/pvcs-gold created
resourcequota/pvcs-silver created
resourcequota/pvcs-copper created

Переконайтесь, що Використана (Used) квота є 0 за допомогою kubectl describe quota.

kubectl describe quota

Name:                   pvcs-gold
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  0     10
requests.storage        0     10Gi


Name:                   pvcs-silver
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  0     10
requests.storage        0     20Gi


Name:                   pvcs-copper
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  0     10
requests.storage        0     30Gi

Створіть PVC з отрибутами класу тому "gold". Збережіть наступний YAML у файл gold-vac-pvc.yaml.

policy/gold-vac-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gold-vac-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
  storageClassName:  # змініть це на назву класу сховища, який ви хочете використовувати
  volumeAttributesClassName: gold

Застосуйте його командою kubectl create.

kubectl create -f ./gold-vac-pvc.yaml

Перевірте, що в "Used" вказано квоту отрибуту класу тому "gold", pvcs-gold змінився, а інші квоти залишились без змін.

kubectl describe quota

Name:                   pvcs-gold
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  1     10
requests.storage        2Gi   10Gi


Name:                   pvcs-silver
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  0     10
requests.storage        0     20Gi


Name:                   pvcs-copper
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  0     10
requests.storage        0     30Gi

Після того, як PVC привʼязано, можна змінювати бажаний клас атрибутів тому. Давайте змінимо його на "silver" за допомогою kubectl patch.

kubectl patch pvc gold-vac-pvc --type='merge' -p '{"spec":{"volumeAttributesClassName":"silver"}}'

Переконайтеся, що значення "Used" для "silver" атрибутів класу тома квоти, pvcs-silver змінилося, pvcs-copper не змінилося, а pvcs-gold може залишитися незмінним або бути вивільненим, що залежить від статусу PVC.

kubectl describe quota

Name:                   pvcs-gold
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  1     10
requests.storage        2Gi   10Gi


Name:                   pvcs-silver
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  1     10
requests.storage        2Gi   20Gi


Name:                   pvcs-copper
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  0     10
requests.storage        0     30Gi

Змінимо її на "copper" за допомогою kubectl patch.

kubectl patch pvc gold-vac-pvc --type='merge' -p '{"spec":{"volumeAttributesClassName":"copper"}}'

Перевіримо, що значення "Used" для "copper" атрибутів класу тома квоти, pvcs-copper змінилося, pvcs-silver та pvcs-gold можуть залишитися незмінним або бути вивільненими, що залежить від статусу PVC.

kubectl describe quota

Name:                   pvcs-gold
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  1     10
requests.storage        2Gi   10Gi


Name:                   pvcs-silver
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  1     10
requests.storage        2Gi   20Gi


Name:                   pvcs-copper
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  1     10
requests.storage        2Gi   30Gi

Виведіть маніфест PVC за допомогою наступної команди:

kubectl get pvc gold-vac-pvc -o yaml

Результат може бути наступним:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gold-vac-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
  storageClassName: default
  volumeAttributesClassName: copper
status:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 2Gi
  currentVolumeAttributesClassName: gold
  phase: Bound
  modifyVolumeStatus:
    status: InProgress
    targetVolumeAttributesClassName: silver
  storageClassName: default

Зачекайте, поки зміни тому завершаться, а потім перевірте квоту ще раз.

kubectl describe quota

Name:                   pvcs-gold
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  0     10
requests.storage        0     10Gi


Name:                   pvcs-silver
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  0     10
requests.storage        0     20Gi


Name:                   pvcs-copper
Namespace:              default
Resource                Used  Hard
--------                ----  ----
persistentvolumeclaims  1     10
requests.storage        2Gi   30Gi

Запити у порівнянні з лімітами

При розподілі обчислювальних ресурсів кожен контейнер може вказати значення запиту та ліміту для CPU або памʼяті. Квоту можна налаштувати для обмеження будь-якого значення.

Якщо для квоти вказано значення для requests.cpu або requests.memory, то це вимагає, щоб кожен вхідний контейнер явно вказував запити для цих ресурсів. Якщо для квоти вказано значення для limits.cpu або limits.memory, то це вимагає, щоб кожен вхідний контейнер вказував явний ліміт для цих ресурсів.

Перегляд і налаштування квот

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ʼи з кількох просторів імен можуть працювати на одному вузлі.

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

Може бути бажаним, щоб 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.

Що далі

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

3 - Обмеження та резервування ID процесів

Kubernetes дозволяє обмежувати кількість ідентифікаторів процесів (PID), які може використовувати Pod. Також можна зарезервувати певну кількість доступних PID для кожного вузла для використання операційною системою та службами (на відміну від Podʼів).

Ідентифікатори процесів (PID) є фундаментальним ресурсом на вузлах. Досить легко досягти обмеження на кількість завдань без досягнення будь-яких інших обмежень ресурсів, що може призвести до нестабільності роботи хосту.

Адміністраторам кластерів потрібні механізми, щоб гарантувати, що Podʼи, що працюють у кластері, не зможуть спричинити вичерпання PID, що перешкоджає роботі системних служб (таких як kubelet або kube-proxy), а також, можливо, і контейнерного середовища. Крім того, важливо забезпечити обмеження PID серед Podʼів, щоб гарантувати, що вони мають обмежений вплив на інші робочі навантаження на тому ж вузлі.

Ви можете налаштувати kubelet для обмеження кількості PID, які може споживати конкретний Pod. Наприклад, якщо ОС вашого вузла налаштовано на використання максимуму 262144 PID та очікується, що буде зберігатися менше 250 Podʼів, кожному Podʼу можна надати бюджет в розмірі 1000 PID, щоб запобігти використанню загальної кількості доступних PID на вузлі. Якщо адміністратор хоче надати можливість перевищення ліміту PID, схожий на CPU чи памʼять, він може зробити це, але з певними додатковими ризиками. У будь-якому випадку, одиничний Pod не зможе зруйнувати весь вузол. Цей вид обмеження ресурсів допомагає запобігти простим форк-бомбам впливати на роботу всього кластера.

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

Ви також можете зарезервувати певну кількість PID для накладних витрат вузла, окремо від виділених для Podʼів. Це аналогічно тому, як ви можете резервувати CPU, памʼять чи інші ресурси для використання операційною системою та іншими засобами поза Podʼами та їх контейнерами.

Обмеження PID є важливим компонентом наряду з ресурсами обчислення. Однак ви вказуєте його по-іншому: замість визначення ліміту ресурсу для Podʼів у .spec для Pod, ви налаштовуєте ліміт як параметр kubelet. Обмеження PID, визначене на рівні Podʼа, наразі не підтримується.

Обмеження PID вузла

Kubernetes дозволяє зарезервувати певну кількість ідентифікаторів процесів для системного використання. Для налаштування резервування використовуйте параметр pid=<кількість> у командних параметрах --system-reserved та --kube-reserved для kubelet. Зазначена вами кількість ідентифікаторів процесів оголошує, що вказана кількість ідентифікаторів процесів буде зарезервована для системи в цілому та для служб Kubernetes відповідно.

Обмеження PID на рівні Podʼа

Kubernetes дозволяє обмежити кількість процесів, які запущені в Podʼі. Ви вказуєте це обмеження на рівні вузла, а не налаштовуєте його як обмеження ресурсів для певного Podʼа. Кожен вузол може мати власний ліміт PID. Для налаштування ліміту ви можете вказати параметр командного рядка --pod-max-pids для kubelet або встановити PodPidsLimit в конфігураційному файлі kubelet.

Виселення на основі PID

Ви можете налаштувати kubelet для початку завершення роботи Podʼа, коли він працює некоректно та споживає аномальну кількість ресурсів. Ця функція називається виселення (eviction). Ви можете Налаштувати обробку випадків нестачі ресурсів для різних сигналів виселення. Використовуйте сигнал виселення pid.available, щоб налаштувати поріг кількості PID, використаних Podʼом. Ви можете встановити мʼякі та жорсткі політики виселення. Однак навіть з жорсткою політикою виселення, якщо кількість PID швидко зростає, вузол все ще може потрапити в нестабільний стан через досягнення обмеження PID вузла. Значення сигналу виселення обчислюється періодично і НЕ забезпечує його виконання.

Обмеження PID — на рівні Podʼа і вузла встановлює жорсткий ліміт. Як тільки ліміт буде досягнуто, робота почне стикатись з помилками при спробі отримати новий PID. Це може або не може призвести до перепланування Pod, залежно від того, як робоче навантаження реагує на ці помилки та як налаштовано проби на працездатність та готовність для Podʼа. Однак, якщо ліміти були налаштовані правильно, ви можете гарантувати, що інші робочі навантаження Podʼів та системні процеси не будуть вичерпувати PID, коли один Pod працює некоректно.

Що далі

• Дивіться Покращеннями обмеження використання PID для отримання додаткової інформації.
• Для історичного контексту прочитайте Обмеження PID для покращення стабільності у Kubernetes 1.14.
• Прочитайте Управління ресурсами для контейнерів.
• Дізнайтеся, як Налаштувати обробку випадків нестачі ресурсів.

4 - Менеджери ресурсів вузлів

Для підтримки критичних до затримки та високопродуктивних робочих навантажень Kubernetes пропонує набір менеджерів ресурсів. Менеджери прагнуть координувати та оптимізувати вирівнювання ресурсів вузла для Podʼів, налаштованих з конкретною вимогою до ресурсів процесорів, пристроїв та памʼяті (величезних сторінок).

Політики вирівнювання топології апаратного забезпечення

Topology Manager — це компонент kubelet, який прагне координувати набір компонентів, відповідальних за ці оптимізації. Загальний процес управління ресурсами регулюється за допомогою політики, яку ви вказуєте. Щоб дізнатися більше, прочитайте Контроль політик управління топологією на вузлі.

Політики призначення CPU для Podʼів

Після привʼязки Podʼа до вузла, kubelet на цьому вузлі може або мультиплексувати наявне апаратне забезпечення (наприклад, розподіляти процесори між кількома Podʼами), або виділяти апаратне забезпечення, присвячуючи деякі ресурси (наприклад, призначаючи один або більше процесорів для виключного використання Pod).

Стандартно kubelet використовує CFS квоту для забезпечення обмежень на використання процесорів Podʼом. Коли вузол запускає багато Podʼів, що вимагають процесорних ресурсів, робоче навантаження може переміщатися на різні ядра процесора залежно від того, чи обмежено Pod і які ядра процесора доступні на момент планування. Багато робочих навантажень не чутливі до цієї міграції й тому працюють нормально без будь-якого втручання.

Однак у робочих навантаженнях, де спорідненість кешу процесора та затримка планування значно впливають на продуктивність, kubelet дозволяє використовувати альтернативні політики управління процесорами для визначення деяких переваг розміщення на вузлі. Це реалізовано за допомогою CPU Manager та його політики. Є дві доступні політики:

• none: політика none явно включає стандартну наявну схему спорідненості процесорів, не надаючи додаткової спорідненості, крім того, що автоматично робить планувальник ОС. Обмеження на використання процесорів для Гарантованих Podʼів та Podʼів Burstable забезпечуються за допомогою CFS квоти.
• static: політика static дозволяє контейнерам у Гарантованих Podʼах з цілими числами requests доступ до ексклюзивних процесорів на вузлі. Ця ексклюзивність забезпечується за допомогою контролера cpuset cgroup.

CPU Manager не підтримує відключення та включення процесорів під час виконання.

Статична політика

Статична політика дозволяє більш детальне управління процесорами та ексклюзивне призначення процесорів. Ця політика керує спільним пулом процесорів, який спочатку містить усі процесори на вузлі. Кількість ексклюзивно виділених процесорів дорівнює загальній кількості процесорів на вузлі мінус будь-які резерви процесорів, встановлені конфігурацією kubelet. Процесори, зарезервовані цими параметрами, беруться, у цілому числі, з початкового спільного пулу у висхідному порядку за фізичним ідентифікатором ядра. Цей спільний пул є набором процесорів, на яких працюють будь-які контейнери у BestEffort та Burstable Pod. Контейнери у Guaranteed Podʼах з дробовими requests також працюють на процесорах у спільному пулі. Лише контейнери, які є частиною Guaranteed Podʼа і мають цілі числа requests процесорів, призначаються ексклюзивні процесори.

Коли Гарантовані Podʼи, контейнери яких відповідають вимогам для статичного призначення, плануються на вузол, процесори видаляються зі спільного пулу та розміщуються у cpuset для контейнера. CFS квота не використовується для обмеження використання процесорів цими контейнерами, оскільки їх використання обмежується самим доменом планування. Іншими словами, кількість процесорів у cpuset контейнера дорівнює цілому числу limit процесорів, зазначеному у специфікації Pod. Це статичне призначення збільшує спорідненість процесорів та зменшує кількість перемикань контексту через обмеження для робочого навантаження, що вимагає процесорних ресурсів.

Розглянемо контейнери у наступних специфікаціях Pod:

spec:
  containers:
  - name: nginx
    image: nginx

Pod вище працює у класі QoS BestEffort, оскільки не вказано жодних requests або limits ресурсів. Він працює у спільному пулі.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

Pod вище працює у класі QoS Burstable, оскільки requests ресурсів не дорівнюють limits і кількість cpu не вказана. Він працює у спільному пулі.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "100Mi"
        cpu: "1"

Pod вище працює у класі QoS Burstable, оскільки requests ресурсів не дорівнюють limits. Він працює у спільному пулі.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "200Mi"
        cpu: "2"

Pod вище працює у класі QoS Гарантований, оскільки requests дорівнюють limits. І обмеження ресурсу контейнера для процесора є цілим числом, більшим або дорівнює одному. Контейнер nginx отримує 2 ексклюзивні процесори.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "1.5"
      requests:
        memory: "200Mi"
        cpu: "1.5"

Pod вище працює у класі QoS Гарантований, оскільки requests дорівнюють limits. Але обмеження ресурсу контейнера для процесора є дробовим числом. Він працює у спільному пулі.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"

Pod вище працює у класі QoS Гарантований, оскільки вказані лише limits і requests встановлюються рівними limits, коли не вказані явно. І обмеження ресурсу контейнера для процесора є цілим числом, більшим або дорівнює одному. Контейнер nginx отримує 2 ексклюзивні процесори.

Опції статичної політики

Нижче наведено доступні варіанти політики статичного керування процесором, перелічені в алфавітному порядку:

align-by-socket (alpha, стандартно приховано)

Вирівнювання процесорів за фізичним пакетом / межами сокета, а не за логічними межами NUMA (доступно з Kubernetes v1.25)

distribute-cpus-across-cores (alpha, стандартно приховано)

Розподіл віртуальних ядер, іноді званих апаратними потоками, між різними фізичними ядрами (доступно з Kubernetes v1.31)

distribute-cpus-across-numa (beta, стандартно видно)

Розподіл процесорів між різними доменами NUMA, прагнучи до рівномірного балансу між вибраними доменами (доступно з Kubernetes v1.23)

full-pcpus-only (GA, стандартно видно)

Завжди виділяти повні фізичні ядра (доступно з Kubernetes v1.22)

strict-cpu-reservation (beta, стандартно видно)

Запобігання всім Pod, незалежно від їх класу якості обслуговування, працювати на зарезервованих процесорах (доступно з Kubernetes v1.32)

prefer-align-cpus-by-uncorecache (alpha, стандартно приховано)

Вирівнювання процесорів за межами кешу uncore (останнього рівня) на основі найкращих зусиль (доступно з Kubernetes v1.32)

Ви можете вмикати та вимикати групи опцій на основі їх рівня зрілості за допомогою наступних воріт функцій:

• CPUManagerPolicyBetaOptions (стандартно увімкнено). Вимкніть, щоб приховати опції рівня бета.
• CPUManagerPolicyAlphaOptions (стандартно вимкнено). Увімкніть, щоб показати опції рівня альфа. Ви все одно повинні увімкнути кожну опцію за допомогою поля cpuManagerPolicyOptions у файлі конфігурації kubelet.

Для отримання більш детальної інформації про окремі опції, які ви можете налаштувати, читайте далі.

full-pcpus-only

Якщо вказано опцію політики full-pcpus-only, статична політика завжди виділятиме повні фізичні ядра. Стандартно, без цієї опції, статична політика виділяє процесори, використовуючи топологічно обізнане найкраще підходяще розміщення. На системах з увімкненим SMT політика може виділяти окремі віртуальні ядра, які відповідають апаратним потокам. Це може призвести до того, що різні контейнери будуть ділити одні й ті ж фізичні ядра; ця поведінка, своєю чергою, сприяє проблемі шумних сусідів. З увімкненою опцією kubelet прийме Pod лише якщо запит на процесори всіх його контейнерів може бути виконаний шляхом виділення повних фізичних ядер. Якщо Pod не пройде допуску, він буде переведений у стан Failed з повідомленням SMTAlignmentError.

distribute-cpus-across-numa

Якщо вказано опцію політики distribute-cpus-across-numa, статична політика рівномірно розподілятиме процесори між вузлами NUMA у випадках, коли більше ніж один вузол NUMA потрібен для задоволення виділення. Стандартно, CPUManager буде пакувати процесори на один вузол NUMA, поки він не буде заповнений, з будь-якими залишковими процесорами, що просто переходять на наступний вузол NUMA. Це може спричинити небажані вузькі місця у паралельному коді, що покладається на барʼєри (та подібні примітиви синхронізації), оскільки цей тип коду зазвичай працює лише так швидко, як його найповільніший робітник (який сповільнюється через те, що на принаймні одному вузлі NUMA доступно менше процесорів). Розподіляючи процесори рівномірно між вузлами NUMA, розробники застосунків можуть легше забезпечити, що жоден робітник не страждає від ефектів NUMA більше, ніж будь-який інший, покращуючи загальну продуктивність таких типів застосунків.

align-by-socket

Якщо вказано опцію політики align-by-socket, процесори будуть вважатися вирівняними на межі сокета при вирішенні, як виділяти процесори для контейнера. Стандартно, CPUManager вирівнює виділення процесорів на межі NUMA, що може призвести до зниження продуктивності, якщо процесори потрібно буде взяти з більш ніж одного вузла NUMA для задоволення виділення. Хоча він намагається забезпечити, щоб усі процесори були виділені з мінімальної кількості вузлів NUMA, немає гарантії, що ці вузли NUMA будуть на одному сокеті. Спрямовуючи CPUManager явно вирівнювати процесори на межі сокета замість межі NUMA, ми можемо уникнути таких проблем. Зверніть увагу, що ця опція політики не сумісна з політикою TopologyManager single-numa-node і не застосовується до апаратного забезпечення, де кількість сокетів більша ніж кількість вузлів NUMA.

distribute-cpus-across-cores

Якщо вказано опцію політики distribute-cpus-across-cores, статична політика спробує виділити віртуальні ядра (апаратні потоки) між різними фізичними ядрами. Стандартно, CPUManager має тенденцію пакувати CPU на якомога меншу кількість фізичних ядер, що може призвести до конфліктів між CPU на одному фізичному ядрі та спричинити вузькі місця продуктивності. Увімкнувши опцію політики distribute-cpus-across-cores, статична політика забезпечує, що процесори розподіляються між якомога більшою кількістю фізичних ядер, зменшуючи конфлікти на одному фізичному ядрі та тим самим покращуючи загальну продуктивність. Однак важливо зазначити, що ця стратегія може бути менш ефективною, коли система сильно завантажена. За таких умов користь від зменшення конфліктів зменшується. Навпаки, стандартна поведінка може допомогти зменшити накладні витрати на міжядерну комунікацію, потенційно забезпечуючи кращу продуктивність за умов високого навантаження.

strict-cpu-reservation

Параметр reservedSystemCPUs у KubeletConfiguration, або застарілий параметр командного рядка kubelet --reserved-cpus, визначає явний набір процесорів для системних демонів ОС та системних демонів kubernetes. Більш детальну інформацію про цей параметр можна знайти на сторінці Явно зарезервований список процесорів. Стандартно ця ізоляція реалізована лише для гарантованих podʼів з цілочисельними запитами на CPU, але не для podʼів burstable та best-effort (а також гарантованих podʼів з дробовими запитами на CPU). Допуск полягає лише у порівнянні запитів на CPU з виділеним CPU. Оскільки ліміт CPU вищий за кількість запитів, стандартна поведінка дозволяє podʼам burstable та best-effort використати весь потенціал зарезервованих системних процесорів reservedSystemCPUs, що призводить до «голодування» служб ОС у реальних умовах розгортання. Якщо увімкнено параметр політики strict-cpu-reservation, статична політика не дозволить будь-якому робочому навантаженню використовувати ядра процесора, вказані у reservedSystemCPUs.

prefer-align-cpus-by-uncorecache

Якщо вказано політику prefer-align-cpus-by-uncorecache, статична політика розподілятиме ресурси процесора для окремих контейнерів таким чином, щоб усі процесори, призначені для контейнера, використовували один і той самий блок кешу ядра (також відомий як кеш останнього рівня або LLC). Стандартно CPUManager щільно пакує призначення CPU, що може призвести до того, що контейнерам буде призначено процесори з декількох кешів основного ядра. Цей параметр дозволяє CPUManager розподіляти процесори таким чином, щоб максимально ефективно використовувати кеш-памʼять ядра. Розподіл виконується за принципом best-effort, з метою привʼязки якомога більшої кількості процесорів до одного і того ж кешу. Якщо потреба контейнера у процесорах перевищує потужність одного кешу, CPUManager мінімізує кількість використовуваних кешів, щоб підтримувати оптимальне вирівнювання кешів. Конкретні робочі навантаження можуть виграти у продуктивності завдяки зменшенню міжкешових затримок та шумних сусідів на рівні кешу. Якщо CPUManager не може вирівняти оптимально, хоча вузол має достатньо ресурсів, контейнер все одно буде прийнято з використанням стандартної поведінки пакування.

Політики керування памʼяттю

Менеджер памʼяті Kubernetes Memory Manager уможливлює функцію гарантованого виділення памʼяті (та hugepages) для podʼів у класі Guaranteed QoS class.

Диспетчер памʼяті використовує протокол генерації підказок, щоб отримати найбільш відповідну спорідненість NUMA для кожного з podʼів. Менеджер памʼяті передає ці підказки центральному менеджеру (Topology Manager). На основі підказок і політики менеджера топології, pod відхиляється або приймається до вузла.

Крім того, менеджер пам'яті гарантує, що пам'ять, яку запитує вузол виділяється з мінімальної кількості вузлів NUMA.

Інші менеджери ресурсів

Налаштування окремих менеджерів описано у окремих документах:

• Менеджер пристроїв