# Управління ресурсами для вузлів Windows

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

---

<!-- overview -->

Ця сторінка описує відмінності у способах управління ресурсами між Linux та Windows.

<!-- body -->

На Linux-вузлах використовуються <a class='glossary-tooltip' title='Група процесів в середовищі Linux із можливістю ізоляції, обліку та встановлення обмежень ресурсів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/glossary/?all=true#term-cgroup' target='_blank' aria-label='cgroups'>cgroups</a> як межа Podʼа для керування ресурсами. Контейнери створюються в межах цих груп для ізоляції мережі, процесів та файлової системи. API cgroup для Linux може використовуватися для збору статистики використання процесора, введення/виведення та памʼяті.

Натомість, у Windows використовується [_job object_](https://docs.microsoft.com/windows/win32/procthread/job-objects) на кожен контейнер з фільтром системного простору імен, щоб обмежити всі процеси в контейнері та забезпечити логічну ізоляцію від хоста. (Обʼєкти завдань є механізмом ізоляції процесів Windows і відрізняються від того, що Kubernetes називає <a class='glossary-tooltip' title='Скінченне або пакетне завдання, яке виконується до завершення.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/workloads/controllers/job/' target='_blank' aria-label='завданням'>завданням</a>).

Не існує можливості запуску контейнера Windows без фільтрації простору імен. Це означає, що системні привілеї не можуть бути заявлені в контексті хоста, і, отже, привілейовані контейнери недоступні в Windows. Контейнери не можуть набувати ідентичності хоста, оскільки менеджер облікових записів безпеки (Security Account Manager, SAM) є окремим.

## Управління памʼяттю {#resource-management-memory}

Windows не має OOM-завершувача процесів (out-of-memory process killer), як у Linux. Windows завжди розглядає всі виділення памʼяті в режимі користувача як віртуальні, і сторінкові файли є обовʼязковими.

Вузли Windows не надмірно виділяють памʼять для процесів. Кінцевий результат полягає в тому, що Windows не досягне умов нестачі памʼяті так само як Linux, і процеси вивантажуються на диск замість припинення через нестачу памʼяті (OOM). Якщо памʼять надмірно виділена, і всю фізичну памʼять вичерпано, то сторінковий обмін може знизити продуктивність.

## Управління CPU {#resource-management-cpu}

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

У Windows kubelet підтримує прапорець командного рядка для встановлення [пріоритету планування](https://docs.microsoft.com/windows/win32/procthread/scheduling-priorities) процесу kubelet: `--windows-priorityclass`. Цей прапорець дозволяє процесу kubelet отримувати більше часових квантів CPU порівняно з іншими процесами, які виконуються на хості Windows. Додаткову інформацію про допустимі значення та їхнє тлумачення можна знайти за посиланням [Класи пріоритетів Windows](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class). Щоб гарантувати, що запущені Podʼи не позбавлять kubelet циклів CPU, встановіть цей прапорець на `ABOVE_NORMAL_PRIORITY_CLASS` або вище.

## Резервування ресурсів {#resource-reservation}

Щоб врахувати памʼять і CPU, які використовуються операційною системою, середовищем виконання контейнерів і процесами хоста Kubernetes, такими як kubelet, ви можете (і повинні) зарезервувати ресурси памʼяті та CPU за допомогою прапорців kubelet `--kube-reserved` та/або `--system-reserved`. У Windows ці значення використовуються лише для розрахунку [доступних для розподілу (allocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) ресурсів вузла.

<div class="alert alert-caution" role="note"><h4 class="alert-heading">Увага:</h4><p>При розгортанні навантажень встановлюйте ліміти ресурсів памʼяті та процесора для контейнерів. Це також віднімає від <code>NodeAllocatable</code> та допомагає загальнокластерному планувальнику кластера визначити, які Podʼи розмістити на яких вузлах.</p>
<p>Планування Podʼів без лімітів може надмірно виділити ресурси на вузлах Windows, і в крайніх випадках може призвести до того, що вузли стануть несправними.</p>
</div>


У Windows доброю практикою є резервування принаймні 2ГіБ памʼяті.

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