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

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

На Linux-вузлах використовуються cgroups як межа Podʼа для керування ресурсами. Контейнери створюються в межах цих груп для ізоляції мережі, процесів та файлової системи. API cgroup для Linux може використовуватися для збору статистики використання процесора, введення/виведення та памʼяті.

Натомість, у Windows використовується job object на кожен контейнер з фільтром системного простору імен, щоб обмежити всі процеси в контейнері та забезпечити логічну ізоляцію від хоста. (Обʼєкти завдань є механізмом ізоляції процесів Windows і відрізняються від того, що Kubernetes називає завданням).

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

Управління памʼяттю

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

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

Управління CPU

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

У Windows kubelet підтримує прапорець командного рядка для встановлення пріоритету планування процесу kubelet: --windows-priorityclass. Цей прапорець дозволяє процесу kubelet отримувати більше часових квантів CPU порівняно з іншими процесами, які виконуються на хості Windows. Додаткову інформацію про допустимі значення та їхнє тлумачення можна знайти за посиланням Класи пріоритетів Windows. Щоб гарантувати, що запущені Podʼи не позбавлять kubelet циклів CPU, встановіть цей прапорець на ABOVE_NORMAL_PRIORITY_CLASS або вище.

Резервування ресурсів

Щоб врахувати памʼять і CPU, які використовуються операційною системою, середовищем виконання контейнерів і процесами хоста Kubernetes, такими як kubelet, ви можете (і повинні) зарезервувати ресурси памʼяті та CPU за допомогою прапорців kubelet --kube-reserved та/або --system-reserved. У Windows ці значення використовуються лише для розрахунку доступних для розподілу (allocatable) ресурсів вузла.

Увага:

При розгортанні навантажень встановлюйте ліміти ресурсів памʼяті та процесора для контейнерів. Це також віднімає від NodeAllocatable та допомагає загальнокластерному планувальнику кластера визначити, які Podʼи розмістити на яких вузлах.

Планування Podʼів без лімітів може надмірно виділити ресурси на вузлах Windows, і в крайніх випадках може призвести до того, що вузли стануть несправними.

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

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

Востаннє змінено July 15, 2026 at 12:45 AM PST: [uk] Ukrainian translation (all-in-one) (193b0d4ea4)