# Резервування обчислювальних ресурсів для системних служб

LLMS index: [llms.txt](/llms.txt)

---

<!-- overview -->

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

`kubelet` надає можливість під назвою 'Node Allocatable', яка допомагає резервувати обчислювальні ресурси для системних служб. Kubernetes рекомендує адміністраторам кластера налаштовувати 'Node Allocatable' на основі щільності робочого навантаження на кожному вузлі.

## Перш ніж ви розпочнете

<p>Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою <a href="https://minikube.sigs.k8s.io/docs/tutorials/multi_node/">minikube</a> або використовувати одну з цих пісочниць:</p>
<ul>
<li><a href="https://labs.iximiuz.com/playgrounds?category=kubernetes&filter=all">iximiuz Labs</a></li>
<li><a href="https://killercoda.com/playgrounds/scenario/kubernetes">Killercoda</a></li>
<li><a href="https://kodekloud.com/public-playgrounds">KodeKloud</a></li>
</ul>


Ви можете налаштувати kubelet за допомогою [параметрів конфігурації](/docs/reference/config-api/kubelet-config.v1beta1/) використовуючи [конфігураційний файл kubelet](/docs/tasks/administer-cluster/kubelet-config-file/).

<!-- steps -->

## Node Allocatable

![ємність вузла](/images/docs/node-capacity.svg)

'Виділення' (Allocatable) на вузлі Kubernetes визначається як обсяг обчислювальних ресурсів, які доступні для Podʼів. Планувальник не надає перевищення обсягу 'Виділення'. Зараз підтримуються 'CPU', 'memory' та 'ephemeral-storage'.

Node Allocatable експонується як частина обʼєкта `v1.Node` в API та як частина `kubectl describe node` в CLI.

Ресурси можуть бути зарезервовані для двох категорій системних служб в `kubelet`.

### Увімкнення QoS та cgroups на рівні Pod {#enable-qos-and-pod-level-cgroups}

Для належного застосування обмежень на вузлі виділення ресурсів вузлові вам потрібно увімкнути нову ієрархію cgroup за допомогою параметру налаштувань `cgroupsPerQOS`. Цей параметр є типово увімкненим. Коли він увімкнений, `kubelet` буде розташовувати всі Podʼи кінцевих користувачів в ієрархії cgroup, керованій `kubelet`.

### Налаштування драйвера cgroup {#configure-a-cgroup-driver}

`kubelet` підтримує маніпулювання ієрархією cgroup на хості за допомогою драйвера cgroup. Драйвер налаштовується за допомогою параметра `cgroupDriver`.

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

* `cgroupfs` — це типовий драйвер, який виконує пряме маніпулювання файловою системою cgroup на хості для управління пісочницями cgroup.
* `systemd` — це альтернативний драйвер, який управляє пісочницями cgroup за допомогою тимчасових сегментів для ресурсів, які підтримуються цією системою ініціалізації.

Залежно від конфігурації відповідного контейнерного середовища, оператори можуть вибрати певний драйвер cgroup, щоб забезпечити належну роботу системи. Наприклад, якщо оператори використовують драйвер cgroup `systemd`, наданий контейнерним середовищем `containerd`, `kubelet` повинен бути налаштований на використання драйвера cgroup `systemd`.

### Kube Reserved

* **KubeletConfiguration Setting**: `kubeReserved: {}`. Приклад: `{cpu: 100m, memory: 100Mi, ephemeral-storage: 1Gi, pid=1000}`
* **KubeletConfiguration Setting**: `kubeReservedCgroup: ""`

`kubeReserved` призначено для захоплення резервування ресурсів для системних демонів Kubernetes, таких як `kubelet`, `container runtime` тощо. Він не призначений для резервування ресурсів для системних служб, які запускаються як Podʼи. `kubeReserved` зазвичай є функцією `pod density` на вузлах.

Крім `cpu`, `memory` та `ephemeral-storage`, можна вказати `pid`, щоб зарезервувати вказану кількість ідентифікаторів процесів для системних демонів Kubernetes.

Для необовʼязкового застосування `kubeReserved` до системних демонів Kubernetes вкажіть батьківську контрольну групу для демонів kube як значення параметра `kubeReservedCgroup` та [додайте `kube-reserved` до `enforceNodeAllocatable`](#enforcing-node-allocatable).

Рекомендується розміщувати системні демони Kubernetes під верхньою контрольною групою (`runtime.slice` на машинах з systemd, наприклад). Кожен системний демон повинен ідеально працювати у власній дочірній контрольній групі. Докладнішу інформацію про рекомендовану ієрархію контрольних груп дивіться у [пропозиції дизайну](https://git.k8s.io/design-proposals-archive/node/node-allocatable.md#recommended-cgroups-setup).

Зверніть увагу, що Kubelet **не створює** `kubeReservedCgroup`, якщо він не існує. Kubelet не запуститься, якщо вказано недійсну контрольну групу. З драйвером cgroup `systemd` вам слід дотримуватися певного шаблону для імені контрольної групи, яку ви визначаєте: імʼя повинно бути значенням, яке ви встановлюєте для `kubeReservedCgroupp`, з додаванням `.slice`.

### System Reserved

* **KubeletConfiguration Setting**: `systemReserved: {}`. Приклад: `{cpu: 100m, memory: 100Mi, ephemeral-storage: 1Gi, pid=1000}`
* **KubeletConfiguration Setting**: `systemReservedCgroup: ""`

`systemReserved` призначено для захоплення резервування ресурсів для системних служб операційної системи, таких як `sshd`, `udev` і т. д. `systemReserved` повинно резервувати `memory` для `kernel`, оскільки памʼять `kernel` наразі не враховується для Podʼів у Kubernetes. Рекомендується також резервувати ресурси для сеансів входу користувача (`user.slice` у світі systemd).

Крім `cpu`, `memory` та `ephemeral-storage`, можна вказати `pid`, щоб зарезервувати вказану кількість ідентифікаторів процесів для системних служб операційної системи.

Для необовʼязкового застосування `systemReserved` до системних служб вкажіть батьківську контрольну групу для системних служб операційної системи як значення параметра `systemReservedCgroup` та [додайте `system-reserved` до `enforceNodeAllocatable`](#enforcing-node-allocatable).

Рекомендується розміщувати системні служби операційної системи під верхньою контрольною групою (`system.slice` на машинах з systemd, наприклад).

Зверніть увагу, що `kubelet` **не створює** `systemReservedCgroup`, якщо він не існує. `kubelet` відмовить у запуску, якщо вказано недійсну контрольну групу. З драйвером cgroup `systemd` вам слід дотримуватися певного шаблону для імені контрольної групи, яку ви визначаєте: імʼя повинно бути значенням, яке ви встановлюєте для `systemReservedCgroup`, з додаванням `.slice`.

### Явно зарезервований список CPU {#explicitly-reserved-cpu-list}








  <div class="feature-state-notice feature-stable">
      <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span>
      <code>Kubernetes v1.17 [stable]</code>
    </div>
  



**KubeletConfiguration Setting**: `reservedSystemCPUs:`. Приклад: `0-3`

`reservedSystemCPUs` призначено для визначення явного набору CPU для системних служб операційної системи та системних служб Kubernetes. `reservedSystemCPUs` призначений для систем, які не мають наміру визначати окремі верхні рівні контрольні групи для системних служб операційної системи та системних служб Kubernetes з урахуванням ресурсу cpuset. Якщо Kubelet **не має** `kubeReservedCgroup` та `systemReservedCgroup`, явний набір cpuset, наданий `reservedSystemCPUs`, переважатиме над CPU, визначеними параметрами `kubeReservedCgroup` та `systemReservedCgroup`.

Ця опція спеціально розроблена для випадків використання в телекомунікаціях/NFV, де неконтрольовані переривання/таймери можуть впливати на продуктивність робочого навантаження. Ви можете використовувати цю опцію для визначення явного набору cpuset для системних/кластерних служб та переривань/таймерів, щоб решта процесорів у системі могли використовуватися виключно для робочих навантажень, з меншим впливом неконтрольованих переривань/таймерів. Щоб перенести системні служби, системні служби Kubernetes та переривання/таймери до явного набору cpuset, визначеного цією опцією, слід використовувати інші механізми поза Kubernetes. Наприклад: у CentOS це можна зробити за допомогою інструменту tuned.

### Пороги виселення {#eviction-thresholds}

**KubeletConfiguration Setting**: `evictionHard: {memory.available: "100Mi", nodefs.available: "10%", nodefs.inodesFree: "5%", imagefs.available: "15%"}`. Наприклад: `{memory.available: "<500Mi"}`

Нестача памʼяті на рівні вузла призводить до System OOMs, що впливає на весь вузол та всі Podʼи, що працюють на ньому. Вузли можуть тимчасово вийти з ладу, поки памʼять не буде відновлена. Щоб уникнути (або зменшити ймовірність) System OOMs, kubelet надає [управління ресурсами](/docs/concepts/scheduling-eviction/node-pressure-eviction/). Виселення підтримується тільки для `memory` та `ephemeral-storage`. Резервуючи певний обсяг памʼяті за допомогою параметра `evictionHard`, `kubelet` намагається виселити Podʼи, коли доступність памʼяті на вузлі впаде нижче зарезервованого значення. Гіпотетично, якщо системні служби не існують на вузлі, Podʼи не можуть використовувати більше, ніж `capacity - eviction-hard`. З цієї причини ресурси, зарезервовані для виселень, не доступні для Podʼів.

### Примусове застосування Node Allocatable {#enforcing-node-allocatable}

**KubeletConfiguration Setting**: `enforceNodeAllocatable: [pods]`. Наприклад: `[pods,system-reserved,kube-reserved]`

Планувальник розглядає 'Allocatable' як доступну `capacity` для Podʼів.

`kubelet` типово застосовує 'Allocatable' на всіх Podʼах. Застосування виконується шляхом видалення Podʼів, коли загальне використання у всіх Podʼах перевищує 'Allocatable'. Додаткові відомості про політику виселення можна знайти на сторінці [Виселення внаслідок тиску на вузол](/docs/concepts/scheduling-eviction/node-pressure-eviction/). Це застосування контролюється, вказуючи значення `pods` для параметра `enforceNodeAllocatable`.

Опціонально, `kubelet` можна налаштувати на примусове застосування `kubeReserved` та `systemReserved`, вказавши значення `kube-reserved` та `system-reserved` в тих самих налаштуваннях. Крім того, примусове застосування можуть мати лише ресурси, що піддаються стисненню, шляхом вказання `kube-reserved-compressible` та `system-reserved compressible`. Зверніть увагу, що для примусового застосування `kubeReserved` або `systemReserved` необхідно вказати відповідно `kubeReservedCgroup` або `systemReservedCgroup`.

## Загальні настанови {#general-guidelines}

Очікується, що системні служби будуть оброблятися аналогічно [гарантованим Podʼам](/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed). Системні служби можуть розширюватися в межах своїх обмежувальних контрольних груп, і цією поведінкою потрібно керувати як частиною розгортань Kubernetes. Наприклад, `kubelet` повинен мати свою власну контрольну групу і ділити ресурси `kubeReserved` з контейнерним середовищем. Однак Kubelet не може розширюватися і використовувати всі доступні ресурси вузла, якщо застосовується `kubeReserved`.

Будьте особливо обережні при застосуванні резервування `systemReserved`, оскільки це може призвести до нестачі ресурсів CPU для критичних системних служб, припинення роботи через нестачу памʼяті (OOM) або неможливості форка на вузлі. Рекомендація полягає в застосуванні `systemReserved` лише у випадку, якщо користувач детально проаналізував свої вузли, щоб надати точні оцінки та має впевненість у своїй здатності відновитися, якщо будь-який процес у цій групі буде примусово завершений через брак памʼяті.

Застосування тільки ресурсів, що піддаються стисненню, для `kubeReserved` і `systemReserved` з меншою ймовірністю спричинить порушення роботи, одночасно забезпечуючи належний розподіл ресурсів у разі конфлікту.

* Спочатку застосовуйте 'Allocatable' на `Pod`.
* Після встановлення належного моніторингу та оповіщення для відстеження kube та системних демонів, спробуйте застосувати ресурси, що піддаються стисненню, на `kubeReserved` та `systemReserved`.
* Спробуйте застосувати ресурси `kubeReserved`, що не піддаються стисненню, на основі евристики використання.
* Якщо це абсолютно необхідно, застосуйте ресурси `systemReserved`, що не піддаються стисненню, з часом.

Вимоги до ресурсів системних служб kube можуть зростати з часом з введенням все більшої кількості функцій. З часом проєкт Kubernetes буде намагатися знизити використання системних служб вузла, але зараз це не пріоритет. Так що очікуйте зниження доступної місткості `Allocatable` у майбутніх версіях.

<!-- discussion -->

## Приклад сценарію {#example-scenario}

Ось приклад для ілюстрації обчислення виділення ресурсів вузла:

* Вузол має `32Гб` памʼяті, `16 ЦП` і `100Гб` сховища
* `kubeReserved` встановлено у `{cpu: 1000m, memory: 2Gi, ephemeral-storage: 1Gi}`
* `systemReserved` встановлено у `{cpu: 500m, memory: 1Gi, ephemeral-storage: 1Gi}`
* `evictionHard` встановлено у `{memory.available: "<500Mi", nodefs.available: "<10%"}`

У цьому сценарії "Allocatable" складатиме 14,5 ЦП, 28,5Гб памʼяті та `88Гб` локального сховища. Планувальник забезпечує, що загальна памʼять `запитів` у всіх Podʼів на цьому вузлі не перевищує 28,5Гб, а сховище не перевищує 88Гб. Kubelet виселяє Podʼи, коли загальне використання памʼяті у всіх Podʼах перевищує 28,5Гб, або якщо загальне використання диска перевищує 88Гб. Якщо всі процеси на вузлі використовують як можна більше ЦП, Podʼи разом не можуть використовувати більше ніж 14,5 ЦП.

Якщо `kubeReserved` та/або `systemReserved` не застосовується, і системні служби перевищують своє резервування, `kubelet` виводить Podʼи, коли загальне використання памʼяті вузла вище 31,5Гб або `storage` перевищує 90Гб.