`
## Одиниці виміру ресурсів в Kubernetes {#resource-units-in-kubernetes}
### Одиниці виміру ресурсів процесора {#meaning-of-cpu}
Обмеження та запити ресурсів процесора вимірюються в одиницях _cpu_. У Kubernetes 1 одиниця CPU еквівалентна **1 фізичному ядру процесора** або **1 віртуальному ядру**, залежно від того, чи є вузол фізичним хостом або віртуальною машиною, яка працює всередині фізичної машини.
Допускаються дробові запити. Коли ви визначаєте контейнер з `spec.containers[].resources.requests.cpu` встановленою на `0.5`, ви просите вдвічі менше часу CPU порівняно з тим, якщо ви запросили `1.0` CPU. Для одиниць ресурсів процесора вираз кількості `0.1` еквівалентний виразу `100m`, що може бути прочитано як "сто міліпроцесорів". Деякі люди кажуть "сто міліядер", і це розуміється так само.
Ресурс CPU завжди вказується як абсолютна кількість ресурсу, ніколи як відносна кількість. Наприклад, `500m` CPU представляє приблизно ту саму обчислювальну потужність, не важливо чи цей контейнер працює на одноядерній, двоядерній або 48-ядерній машині.
Примітка:
Kubernetes не дозволяє вказувати ресурси CPU з точністю вище 1m або 0.001 CPU. Щоб уникнути випадкового використання неприпустимої кількості CPU, корисно вказувати одиниці CPU, використовуючи форму міліCPU замість десяткової форми при використанні менше ніж 1 одиниця CPU.
Наприклад, у вас є Pod, який використовує 5m або 0.005 CPU, і ви хочете зменшити його ресурси CPU. Використовуючи десяткову форму, важко помітити, що 0.0005 CPU є неприпустимим значенням, тоді як використовуючи форму міліCPU, легше помітити, що 0.5m є неприпустимим значенням.
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.34 [beta](стандартно увімкнено)
Цю можливість можна увімкнути встановленням функціональної можливості [`PodLevelResources`](/docs/reference/command-line-tools-reference/feature-gates/#PodLevelResources). Наступний Pod має явний запит на 1 CPU та 100 MiB памʼяті, а також явний ліміт на 1 CPU та 200 MiB памʼяті. Контейнер `pod-resources-demo-ctr-1` має явні запити та обмеження. Однак, контейнер `pod-resources-demo-ctr-2` буде просто ділити ресурси, доступні в межах ресурсів Podʼа, оскільки він не має явних запитів і обмежень.
apiVersion: v1
kind: Pod
metadata:
name: pod-resources-demo
namespace: pod-resources-example
spec:
resources:
limits:
cpu: "1"
memory: "200Mi"
requests:
cpu: "1"
memory: "100Mi"
containers:
- name: pod-resources-demo-ctr-1
image: nginx
resources:
limits:
cpu: "0.5"
memory: "100Mi"
requests:
cpu: "0.5"
memory: "50Mi"
- name: pod-resources-demo-ctr-2
image: fedora
command:
- sleep
- inf
## Як Podʼи з запитаними ресурсами плануються {#how-pods-with-resource-requests-are-scheduled}
Коли ви створюєте Pod, планувальник Kubernetes вибирає вузол, на якому Pod буде запущено. Кожен вузол має максимальну місткість для кожного з типів ресурсів: кількість процесорних ядер (CPU) та обсяг памʼяті, які він може надати для Podʼів. Планувальник забезпечує, що для кожного типу ресурсів сума запитів ресурсів запланованих контейнерів буде менше, ніж місткість вузла. Зверніть увагу, що навіть якщо фактичне використання ресурсів CPU або памʼяті на вузлі дуже низьке, планувальник все одно відмовляється розміщувати Pod на вузлі, якщо перевірка місткості не пройшла успішно. Це захищає від нестачі ресурсів на вузлі, коли пізніше збільшується використання ресурсів, наприклад, під час денного піка запитів.
## Як Kubernetes застосовує запити на ресурси та обмеження{#how-pods-with-resource-limits-are-run}
Коли kubelet запускає контейнер як частину Podʼа, він передає запити та обмеження для памʼяті та CPU цього контейнера до середовища виконання контейнера.
У Linux середовище виконання контейнера зазвичай налаштовує контрольні групи (cgroups) ядра, які застосовують і виконують обмеження, що ви визначили.
- Обмеження CPU встановлює жорсткий ліміт на те, скільки часу процесора контейнер може використовувати. Протягом кожного інтервалу планування (часового відрізка) ядро Linux перевіряє, чи перевищується це обмеження; якщо так, ядро чекає, перш ніж дозволити цій групі продовжити виконання.
- Запит CPU зазвичай визначає вагу. Якщо кілька різних контейнерів (cgroups) хочуть працювати на конкуруючій системі, робочі навантаження з більшими запитами CPU отримують більше часу CPU, ніж робочі навантаження з малими запитами.
- Запит памʼяті в основному використовується під час планування Podʼа (Kubernetes). На вузлі, що використовує cgroups v2, середовище виконання контейнера може використовувати запит памʼяті як підказку для встановлення `memory.min` та `memory.low`.
- Обмеження памʼяті встановлює обмеження памʼяті для цієї контрольної групи. Якщо контейнер намагається виділити більше памʼяті, ніж це обмеження, підсистема управління памʼяттю Linux активується і, зазвичай, втручається, зупиняючи один з процесів у контейнері, який намагався виділити памʼять. Якщо цей процес є PID 1 контейнера, і контейнер позначений як можливий до перезапуску, Kubernetes перезапускає контейнер.
- Обмеження памʼяті для Podʼа або контейнера також може застосовуватися до сторінок в памʼяті, резервованих томами, як от `emptyDir`. Kubelet відстежує `tmpfs` томи `emptyDir` як використання памʼяті контейнера, а не як [локальне тимчасове сховище](/docs/concepts/storage/ephemeral-storage/). При використанні `emptyDir` в памʼяті, обовʼязково ознайомтеся з примітками [нижче](#memory-backed-emptydir).
Якщо контейнер перевищує свій запит на памʼять і вузол, на якому він працює, стикається з браком памʼяті взагалі, ймовірно, що Pod, якому належить цей контейнер, буде виселено.
Контейнер може або не може дозволяти перевищувати своє обмеження CPU протягом тривалого часу. Однак середовища виконання контейнерів не припиняють роботу Podʼа або контейнерів через надмірне використання CPU.
Щоб визначити, чи не можна розмістити контейнер або, чи його роботи примусово припиняється через обмеження ресурсів, див. [Налагодження](#troubleshooting).
### Зміна розміру ресурсів контейнера {#resizing-container-resources}
Після створення Podʼа може знадобитися налаштувати його ресурси CPU або памʼяті відповідно до фактичних моделей використання. Kubernetes пропонує два підходи до зміни розміру ресурсів Podʼа:
#### Зміна розміру на місці {#pod-resize-inplace}
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.35 [stable](стандартно увімкнено)
Ви можете змінити `requests` та `limits` CPU та памʼяті контейнерів у працюючому Podʼі без його повторного створення. Це називається _вертикальним масштабуванням Podʼа на місці_ або _зміною розміру Podʼа на місці_. Щоб виконати зміну розміру на місці, оновіть специфікації ресурсів контейнера за допомогою субресурсу Podʼа `/resize`. Ви можете контролювати, чи потрібно перезапускати контейнер, встановивши поле `resizePolicy` у специфікації контейнера.
#### Зміна розміру шляхом запуску Podʼів-замінників {#resizing-by-launching-replacement-pods}
Хмарний підхід до зміни ресурсів Podʼа полягає в оновленні шаблону Podʼа в обʼєкті робочого навантаження (такому як Deployment або StatefulSet) і дозволі контролеру робочого навантаження замінити Podʼи новими, що мають оновлені ресурси. Цей підхід працює з будь-якою версією Kubernetes і дозволяє змінювати будь-які специфікації Podʼів.
Детальніше про зміну розміру Pod див. [Зміна розміру Podʼа](/docs/concepts/workloads/pods/pod-lifecycle/#pod-resize). Детальні інструкції щодо зміни розміру на місці див. у розділі [Зміна розміру ресурсів CPU та памʼяті, призначених контейнерам](/docs/tasks/configure-pod-container/resize-container-resources/). Ви також можете використовувати [Vertical Pod Autoscaler](/docs/concepts/workloads/autoscaling/vertical-pod-autoscale/) для автоматичного управління рекомендаціями щодо ресурсів Podʼа.
### Моніторинг використання обчислювальних ресурсів та ресурсів памʼяті {#monitoring-compute-memory-resources-usage}
kubelet повідомляє про використання ресурсів Podʼа як частину статусу Podʼа.
Якщо в вашому кластері доступні [інструменти для моніторингу](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/), то використання ресурсів Podʼа можна отримати або безпосередньо з [Metrics API](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api), або з вашого інструменту моніторингу.
### Міркування щодо томів `emptyDir`, що зберігаються в памʼяті {#memory-backed-emptydir}
Увага:
Якщо ви не вказуєте sizeLimit для emptyDir тому, цей том може використовувати до граничного обсягу памʼяті цього Podʼа (Pod.spec.containers[].resources.limits.memory). Якщо ви не встановлюєте граничний обсяг памʼяті, Pod не має верхньої межі на споживання памʼяті і може використовувати всю доступну памʼять на вузлі. Kubernetes планує Podʼи на основі запитів на ресурси (Pod.spec.containers[].resources.requests) і не враховує використання памʼяті понад запит при вирішенні, чи може інший Pod розміститися на даному вузлі. Це може призвести до відмови в обслуговуванні та змусити ОС виконати обробку нестачі памʼяті (OOM). Можливо створити будь-яку кількість emptyDir, які потенційно можуть використовувати всю доступну памʼять на вузлі, що робить OOM більш ймовірним.
З точки зору управління памʼяттю, є деякі подібності між використанням памʼяті як робочої області процесу і використанням памʼяті для `emptyDir`, що зберігається в памʼяті. Але при використанні памʼяті як том, як у випадку з `emptyDir`, що зберігається в памʼяті, є додаткові моменти, на які слід звернути увагу:
- Файли, збережені в томі, що зберігається в памʼяті, майже повністю управляються застосунком користувча. На відміну від використання памʼяті як робочої області процесу, ви не можете покладатися на такі речі, як збір сміття на рівні мови програмування.
- Мета запису файлів в том полягає в збереженні даних або їх передачі між застосунками. Ні Kubernetes, ні ОС не можуть автоматично видаляти файли з тому, тому памʼять, яку займають ці файли, не може бути відновлена, коли система або Pod відчувають нестачу памʼяті.
- Томи `emptyDir`, що зберігаються в памʼяті, корисні через свою продуктивність, але памʼять зазвичай набагато менша за розміром і набагато дорожча за інші носії, такі як диски або SSD. Використання великої кількості памʼяті для томів `emptyDir` може вплинути на нормальну роботу вашого Podʼа або всього вузла, тому їх слід використовувати обережно.
Якщо ви адмініструєте кластер або простір імен, ви також можете встановити [ResourceQuota](/docs/concepts/policy/resource-quotas/), що обмежує використання памʼяті; також може бути корисно визначити [LimitRange](/docs/concepts/policy/limit-range/) для додаткового забезпечення обмежень. Якщо ви вказуєте `spec.containers[].resources.limits.memory` для кожного Podʼа, то максимальний розмір тому `emptyDir` буде дорівнювати граничному обсягу памʼяті Podʼа.
Як альтернатива, адміністратор кластера може забезпечити дотримання обмежень на розмір томів `emptyDir` в нових Podʼах, використовуючи механізм політики, такий як [ValidatingAdmissionPolicy](/docs/reference/access-authn-authz/validating-admission-policy).
## Локальне тимчасове сховище {#local-ephemeral-storage}
Щодо загальних концепцій про локальне тимчасове сховище та порад щодо налаштування запитів і/або обмежень локального тимчасового сховища для контейнера, дивіться сторінку [локальне тимчасове сховище](/docs/concepts/storage/ephemeral-storage/).
### Моніторинг ресурсів для локального тимчасового сховища {#resource-monitoring-for-local-ephemeral-storage}
Kubelet може вимірювати, скільки локального тимчасового сховища використовується. Він робить це, якщо ви ввімкнули ізоляцію ємності локального тимчасового сховища.
Kubernetes відстежує обсяг тимчасового сховища, яке використовує Pod, за допомогою таких даних:
- Записуючи в шар контейнера, доступний для запису (rootfs), образи контейнерів або в обидва.
- Записуючи в локальні томи `emptyDir`.
- Власні журнали Podʼа (зазвичай зберігаються в `/var/log/pods`).
- Системні файли, які керуються Kubernetes і які відображаються в Podʼі, наприклад `/etc/hosts`.
## Розширені ресурси {#extended-resources}
Розширені ресурси — це повністю кваліфіковані імена ресурсів поза доменом `kubernetes.io`. Вони дозволяють операторам кластера оголошувати, а користувачам використовувати ресурси, які не вбудовані в Kubernetes.
Щоб скористатися Розширеними ресурсами, потрібно виконати два кроки. По-перше, оператор кластера повинен оголошувати Розширений Ресурс. По-друге, користувачі повинні запитувати Розширений Ресурс в Podʼах.
### Керування розширеними ресурсами {#managing-extended-resources}
#### Ресурси на рівні вузла {#node-level-extended-resources}
Ресурси на рівні вузла повʼязані з вузлами.
##### Керовані ресурси втулків пристроїв {#device-plugin-managed-resources}
Дивіться [Втулок пристроїв](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) щодо того, як оголошувати ресурси, що керуються втулком пристроїв на кожному вузлі.
##### Інші ресурси {#other-resources}
Щоб оголошувати новий розширений ресурс на рівні вузла, оператор кластера може надіслати HTTP-запит типу `PATCH` до API-сервера, щоб вказати доступну кількість в полі `status.capacity` для вузла у кластері. Після цієї операції поле `status.capacity` вузла буде містити новий ресурс. Поле `status.allocatable` оновлюється автоматично з новим ресурсом асинхронно за допомогою kubelet.
Оскільки планувальник використовує значення `status.allocatable` вузла при оцінці придатності Podʼа, планувальник враховує нове значення лише після цього асинхронного оновлення. Між моментом зміни потужності вузла новим ресурсом і часом, коли перший Pod, який запитує ресурс, може бути запланований на цьому вузлі, може відбуватися коротка затримка.
**Приклад:**
Нижче наведено приклад використання `curl` для формування HTTP-запиту, який оголошує пʼять ресурсів "example.com/foo" на вузлі `k8s-node-1`, майстер якого `k8s-master`.
```shell
curl --header "Content-Type: application/json-patch+json" \
--request PATCH \
--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \
http://k8s-master:8080/api/v1/nodes/k8s-node-1/status
```
Примітка:
У запиті
~1 — це кодування символу
/ в шляху патча. Значення операційного шляху у JSON-Patch інтерпретується як JSON-вказівник. Для отримання докладнішої інформації дивіться
RFC 6901, розділ 3.
Примітка:
Розширені ресурси замінюють Opaque Integer Resources. Користувачі можуть використовувати будь-який префікс доменного імені, крім kubernetes.io, який зарезервований.
Щоб використовувати розширений ресурс у Podʼі, включіть імʼя ресурсу як ключ у масив `spec.containers[].resources.limits` у специфікації контейнера.
Примітка:
Розширені ресурси не можуть бути перевищені, тому запити та обмеження мають бути рівними, якщо обидва присутні у специфікації контейнера.
Pod є запланованим лише у випадку, якщо всі запити ресурсів задовольняються, включаючи CPU, памʼять та будь-які розширені ресурси. Pod залишається у стані `PENDING`, поки запит ресурсу не може бути задоволений.
**Приклад:**
Нижче наведено Pod, який запитує 2 CPU та 1 "example.com/foo" (розширений ресурс).
```yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: myimage
resources:
requests:
cpu: 2
example.com/foo: 1
limits:
example.com/foo: 1
```
## Обмеження PID {#pid-limiting}
Обмеження ідентифікаторів процесів (PID) дозволяють налаштувати kubelet для обмеження кількості PID, яку може використовувати певний Pod. Див. [Обмеження PID](/docs/concepts/policy/pid-limiting/) для отримання інформації.
### Усунення несправностей {#troubleshooting}
### Мої Podʼи знаходяться в стані очікування з повідомленням події `FailedScheduling` {#my-pods-are-pending-with-event-message-failedscheduling}
Якщо планувальник не може знайти жодного вузла, де може розмістити Pod, Pod залишається
незапланованим, поки не буде знайдено місце. Кожного разу, коли планувальник не може знайти місце для Podʼа, створюється [подія](/docs/reference/kubernetes-api/cluster-resources/event-v1/). Ви можете використовувати `kubectl` для перегляду подій Podʼа; наприклад:
```shell
kubectl describe pod frontend | grep -A 9999999999 Events
```
```none
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 23s default-scheduler 0/42 nodes available: insufficient cpu
```
У прикладі Pod під назвою "frontend" не вдалося запланувати через недостатній ресурс CPU на будь-якому вузлі. Схожі повідомлення про помилку також можуть вказувати на невдачу через недостатню памʼять (PodExceedsFreeMemory). Загалом, якщо Pod знаходиться в стані очікування з таким типом повідомлення, є кілька речей, які варто спробувати:
- Додайте більше вузлів у кластер.
- Завершіть непотрібні Podʼи, щоб звільнити місце для очікуваних Podʼів.
- Перевірте, що Pod не є більшим, ніж усі вузли. Наприклад, якщо всі вузли мають місткість `cpu: 1`, то Pod з запитом `cpu: 1.1` ніколи не буде запланованим.
- Перевірте наявність "taint" вузла. Якщо більшість ваших вузлів мають "taint", і новий Pod не толерує цей "taint", планувальник розглядає розміщення лише на решті вузлів, які не мають цього "taint".
Ви можете перевірити місткості вузлів та виділені обсяги ресурсів за допомогою команди `kubectl describe nodes`. Наприклад:
```shell
kubectl describe nodes e2e-test-node-pool-4lw4
```
```none
Name: e2e-test-node-pool-4lw4
[ ... lines removed for clarity ...]
Capacity:
cpu: 2
memory: 7679792Ki
pods: 110
Allocatable:
cpu: 1800m
memory: 7474992Ki
pods: 110
[ ... lines removed for clarity ...]
Non-terminated Pods: (5 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
--------- ---- ------------ ---------- --------------- -------------
kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%)
kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%)
kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%)
kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%)
kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi
(0%) 100Mi (1%)
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
CPU Requests CPU Limits Memory Requests Memory Limits
------------ ---------- --------------- -------------
680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%)
```
У виводі ви можете побачити, що якщо Pod запитує більше 1,120 CPU або більше 6,23 ГБ памʼяті, то цей Pod не поміститься на вузлі.
Дивлячись на розділ "Podʼи", ви можете побачити, які Podʼи займають місце на вузлі.
Обсяг ресурсів, доступних для Podʼів, менший за місткість вузла, оскільки системні служби використовують частину доступних ресурсів. У Kubernetes API, кожен вузол має поле `.status.allocatable` (див. [NodeStatus](/docs/reference/kubernetes-api/cluster-resources/node-v1/#NodeStatus) для деталей).
Поле `.status.allocatable` описує обсяг ресурсів, доступних для Podʼів на цьому вузлі (наприклад: 15 віртуальних ЦП та 7538 МіБ памʼяті). Для отримання додаткової інформації про виділені ресурси вузла в Kubernetes дивіться [Резервування обчислювальних ресурсів для системних служб](/docs/tasks/administer-cluster/reserve-compute-resources/).
Ви можете налаштувати [квоти ресурсів](/docs/concepts/policy/resource-quotas/) для обмеження загального обсягу ресурсів, який може споживати простір імен. Kubernetes забезпечує дотримання квот для обʼєктів в конкретному просторі імен, коли існує ResourceQuota в цьому просторі імен. Наприклад, якщо ви призначаєте конкретні простори імен різним командам, ви можете додавати ResourceQuotas в ці простори імен. Встановлення квот ресурсів допомагає запобігти використанню однією командою так багато будь-якого ресурсу, що це впливає на інші команди.
Вам також варто розглянути, який доступ ви надаєте в цьому просторі імен: **повний** дозвіл на запис у простір імен дозволяє тому, хто має такий доступ, видаляти будь-який ресурс, включаючи налаштований ResourceQuota.
### Робота мого контейнера завершується примусово {#my-container-is-terminated}
Робота вашого контейнера може бути завершена через нестачу ресурсів. Щоб перевірити, чи контейнер був завершений через досягнення обмеження ресурсів, викличте `kubectl describe pod` для цікавого вас Podʼа:
```shell
kubectl describe pod simmemleak-hra99
```
Вивід буде схожий на:
```none
Name: simmemleak-hra99
Namespace: default
Image(s): saadali/simmemleak
Node: kubernetes-node-tf0f/10.240.216.66
Labels: name=simmemleak
Status: Running
Reason:
Message:
IP: 10.244.2.75
Containers:
simmemleak:
Image: saadali/simmemleak:latest
Limits:
cpu: 100m
memory: 50Mi
State: Running
Started: Tue, 07 Jul 2019 12:54:41 -0700
Last State: Terminated
Reason: OOMKilled
Exit Code: 137
Started: Fri, 07 Jul 2019 12:54:30 -0700
Finished: Fri, 07 Jul 2019 12:54:33 -0700
Ready: False
Restart Count: 5
Conditions:
Type Status
Ready False
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 42s default-scheduler Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
Normal Pulled 41s kubelet Container image "saadali/simmemleak:latest" already present on machine
Normal Created 41s kubelet Created container simmemleak
Normal Started 40s kubelet Started container simmemleak
Normal Killing 32s kubelet Killing container with id ead3fb35-5cf5-44ed-9ae1-488115be66c6: Need to kill Pod
```
У прикладі `Restart Count: 5` вказує на те, що контейнер `simmemleak` у Podʼі був завершений та перезапущений пʼять разів (до цього моменту). Причина `OOMKilled` показує, що контейнер намагався використовувати більше памʼяті, ніж встановлений йому ліміт.
Наступним кроком може бути перевірка коду програми на витік памʼяті. Якщо ви виявите, що програма працює так, як очікувалося, розгляньте встановлення вищого ліміту памʼяті (і, можливо, запиту) для цього контейнера.
## Що далі
- Отримайте практичний досвід [призначення ресурсів памʼяті контейнерам та Podʼам](/docs/tasks/configure-pod-container/assign-memory-resource/).
- Отримайте практичний досвід [призначення ресурсів ЦП контейнерам та Podʼам](/docs/tasks/configure-pod-container/assign-cpu-resource/).
- Прочитайте, як API-довідка визначає [контейнер](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container) та його [вимоги до ресурсів](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)
- Прочитайте про [локальне тимчасове сховище](/docs/concepts/storage/ephemeral-storage/)
- Дізнайтеся більше про [конфігурацію планувальника kube-scheduler (v1)](/docs/reference/config-api/kube-scheduler-config.v1/)
- Дізнайтеся більше про [класи якості обслуговування для Podʼів](/docs/concepts/workloads/pods/pod-qos/)
- Дізнайтеся більше про [Розширене розподілення ресурсів через DRA](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#extended-resource)
