# Налаштування політик керування ЦП на вузлі
LLMS index: [llms.txt](/llms.txt)
---
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.26 [stable]
Kubernetes зберігає багато аспектів того, як Podʼи виконуються на вузлах, абстрагованими від користувача. Це зроблено навмисно. Проте деякі завдання вимагають більших гарантій з погляду часу реакції та/або продуктивності, щоб працювати задовільно. Kubelet надає методи для включення складніших політик розміщення завдань, зберігаючи абстракцію вільною від явних директив розміщення.
Для отримання докладної інформації щодо управління ресурсами, будь ласка, зверніться до документації [Управління ресурсами для Podʼів та контейнерів](/docs/concepts/configuration/manage-resources-containers).
Для отримання детальної інформації про те, як у kubelet реалізовано управління ресурсами, зверніться до документації [Node ResourceManagers](/docs/concepts/policy/node-resource-managers).
## Перш ніж ви розпочнете
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Версія вашого Kubernetes сервера має бути не старішою ніж v1.26.
Для перевірки версії введіть kubectl version.
Якщо ви використовуєте старішу версію Kubernetes, будь ласка, перегляньте документацію для версії, яку ви фактично використовуєте.
## Налаштування політик керування CPU {#configuring-cpu-management-policies}
Стандартно, kubelet використовує [квоту CFS](https://en.wikipedia.org/wiki/Completely_Fair_Scheduler), щоб обмежувати ЦП для Podʼів. Коли вузол виконує багато Podʼів, залежних від ЦП, навантаження може переміщуватися на різні ядра ЦП залежно від того, чи обмежений Pod, і які ядра ЦП доступні на момент планування. Багато завдань не чутливі до цього переміщення і, отже, працюють нормально без будь-якого втручання.
Проте, в завданнях, де спорідненість кешу ЦП та затримка планування значно впливають на продуктивність робочого завдання, kubelet дозволяє використовувати альтернативні політики керування ЦП для визначення деяких вподобань розміщення на вузлі.
## Підтримка Windows {#windows-support}
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.32 [alpha](стандартно вимкнено)
Підтримку диспетчера процесорів можна увімкнути у Windows за допомогою `WindowsCPUAndMemoryAffinity`, і вона потребує підтримки під час виконання контейнера. Після увімкнення функціональної можливості виконайте наведені нижче кроки для налаштування [політики диспетчера CPU](#configuration).
## Налаштування {#configuration}
Політика керування ЦП встановлюється прапорцем kubelet `--cpu-manager-policy` або полем `cpuManagerPolicy` в [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/). Підтримуються дві політики:
* [`none`](#none-policy): стандартна політика.
* [`static`](#static-policy): дозволяє контейнерам з певними характеристиками ресурсів отримувати збільшену спорідненість ЦП та ексклюзивність на вузлі.
Керування ЦП періодично записує оновлення ресурсів через CRI, щоб звести до мінімуму проблеми сумісності памʼяті та виправити їх. Частота зведення встановлюється за допомогою нового значення конфігурації Kubelet `--cpu-manager-reconcile-period`. Якщо вона не вказана, стандартно вона дорівнює тому ж часу, що й `--node-status-update-frequency`.
Поведінку статичної політики можна налаштувати за допомогою прапорця `--cpu-manager-policy-options`. Прапорець приймає список параметрів політики у вигляді `ключ=значення`. Якщо ви вимкнули [функціональну можливість](/docs/reference/command-line-tools-reference/feature-gates/) `CPUManagerPolicyOptions`, то ви не зможете налаштувати параметри політик керування ЦП. У цьому випадку керування ЦП працюватиме лише зі своїми стандартними налаштуваннями.
Окрім верхнього рівня `CPUManagerPolicyOptions`, параметри політики розділені на дві групи: якість альфа (типово прихована) та якість бета (типово видима). На відміну від стандарту Kubernetes, ці feature gate захищають групи параметрів, оскільки було б надто складно додати feature gate для кожного окремого параметра.
## Зміна політики керування ЦП {#changing-the-cpu-management-policy}
Оскільки політику керування ЦП можна застосовувати лише коли kubelet створює нові Podʼи, просте змінення з "none" на "static" не застосується до наявних Podʼів. Тому, щоб правильно змінити політику керування ЦП на вузлі, виконайте наступні кроки:
1. [Виведіть з експлуатації](/docs/tasks/administer-cluster/safely-drain-node) вузол.
2. Зупиніть kubelet.
3. Видаліть старий файл стану керування ЦП. Типовий шлях до цього файлу `/var/lib/kubelet/cpu_manager_state`. Це очищує стан, що зберігається CPUManager, щоб множини ЦП, налаштовані за новою політикою, не конфліктували з нею.
4. Відредагуйте конфігурацію kubelet, щоб змінити політику керування ЦП на потрібне значення.
5. Запустіть kubelet.
Повторіть цей процес для кожного вузла, який потребує зміни політики керування ЦП. Пропуск цього процесу призведе до постійної аварійної роботи kubelet з такою помилкою:
```none
could not restore state from checkpoint: configured policy "static" differs from state checkpoint policy "none", please drain this node and delete the CPU manager checkpoint file "/var/lib/kubelet/cpu_manager_state" before restarting Kubelet
```
Примітка:
Якщо на вузлі змінюється набір доступних процесорів, то вузол необхідно вивести з експлуатації та вручну перезавантажити CPU manager, видаливши
файл стану cpu_manager_state у кореневій теці kubelet.
### Налаштування політики `none` {#none-policy-configuration}
Ця політика не має додаткових елементів конфігурації.
### Налаштування політики `static` {#static-policy-configuration}
Ця політика керує спільним пулом ЦП, який на початку містить всі ЦП на вузлі. Кількість ексклюзивно виділених ЦП дорівнює загальній кількості ЦП на вузлі мінус будь-які резерви ЦП за допомогою параметрів kubelet `--kube-reserved` або `--system-reserved`. З версії 1.17 список резервувань ЦП може бути вказаний явно за допомогою параметру kubelet `--reserved-cpus`. Явний список ЦП, вказаний за допомогою `--reserved-cpus`, має пріоритет над резервуванням ЦП, вказаним за допомогою `--kube-reserved` та `--system-reserved`. ЦП, зарезервовані цими параметрами, беруться, у цілочисельній кількості, зі спільного пулу на основі фізичного ідентифікатора ядра. Цей спільний пул — це множина ЦП, на яких працюють контейнери в Podʼах з `BestEffort` та `Burstable`. Контейнери у Podʼах з гарантованою продуктивністю з цілими `requests` ЦП також працюють на ЦП у спільному пулі. Ексклюзивні ЦП призначаються лише контейнерам, які одночасно належать до Podʼа з гарантованою продуктивністю та мають цілочисельні `requests` ЦП.
Примітка:
Kubelet потребує, щоб було зарезервовано не менше одного ЦП за допомогою параметрів --kube-reserved і/або --system-reserved або --reserved-cpus, коли включена статична політика. Це тому, що нульове резервування ЦП дозволить спільному пулу стати порожнім.
### Параметри політики static {#cpu-policy-static--options}
Ви можете включати та виключати групи параметрів на основі їх рівня зрілості, використовуючи наступні feature gate:
* `CPUManagerPolicyBetaOptions` — стандартно увімкнено. Вимкніть, щоб приховати параметри рівня бета.
* `CPUManagerPolicyAlphaOptions` — стандартно вимкнено. Увімкніть, щоб показати параметри рівня альфа. Ви все ще повинні увімкнути кожен параметр за допомогою опції kubelet `CPUManagerPolicyOptions`.
Для політики static `CPUManager` існують наступні параметри:
* `full-pcpus-only` (GA, типово видимий) (1.33 або вище)
* `distribute-cpus-across-numa` (бета, типово видимий) (1.33 або вище)
* `align-by-socket` (альфа, типово прихований) (1.25 або вище)
* `distribute-cpus-across-cores` (альфа, типово прихований) (1.31 або вище)
* `strict-cpu-reservation` (GA, типово видимий) (1.35 або вище)
* `prefer-align-cpus-by-uncorecache` (GA, типово видимий) (1.36 або вище)
Параметр `full-pcpus-only` можна включити, додавши `full-pcpus-only=true` до параметрів політики `CPUManager`. Так само параметр `distribute-cpus-across-numa` можна включити, додавши `distribute-cpus-across-numa=true` до параметрів політики `CPUManager`. Якщо обидва встановлені, вони "адитивні" у тому сенсі, що ЦП будуть розподілені по вузлах NUMA в шматках повних фізичних ядер, а не окремих ядер. Параметр політики `align-by-socket` можна увімкнути, додавши `align-by-socket=true` до параметрів політики `CPUManager`. Він також адитивний до параметрів політики `full-pcpus-only` та `distribute-cpus-across-numa`.
Опцію `distribute-cpus-across-cores` можна увімкнути, додавши `distribute-cpus-across-cores=true` до параметрів політики `CPUManager`. Зараз її не можна використовувати разом з параметрами політики `full-pcpus-only` або `distribute-cpus-across-numa`.
Опцію `strict-cpu-reservation` можна увімкнути, додавши `strict-cpu-reservation=true` до параметрів політики CPUManager, після чого видалити файл `/var/lib/kubelet/cpu_manager_state` і перезапустити kubelet.
Параметр `prefer-align-cpus-by-uncorecache` можна увімкнути, додавши `prefer-align-cpus-by-uncorecache` до параметрів політики `CPUManager`. Якщо буде використано несумісні опції, kubelet не запуститься з помилкою, яку буде вказано у журналах.
Докладні відомості про поведінку окремих параметрів, які ви можете налаштувати, наведено у документації [Менеджери ресурсів вузлів](/docs/concepts/policy/node-resource-managers).
## Що далі
* Дізнайтеся більше про [Менеджер ресурсів на рівні подів](/docs/concepts/workloads/resource-managers/#pod-level-resource-managers).