# Довідник менеджерів ресурсів на рівні Podʼів

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

---

<div class="feature-state-notice feature-beta" title="Функціональна можливість: PodLevelResourceManagers">
              <span class="feature-state-name">Стан функціоналу:</span>
              <span class="feature-state-details">
               
                 <span class='feature-state-stage'>Beta</span> починаючи з Kubernetes v1.37; стандартно вимкнено
               </span>
            </div>

            
            <div class="feature-beta">
              
              
                <details>
                <summary>Докладніше про цей функціонал</summary>
                <p>Щоб скористатися цією функцією, вам (або адміністратору кластера) потрібно увімкнути функціональну можливість <a href="/uk/docs/reference/command-line-tools-reference/feature-gates/#PodLevelResourceManagers"><tt>PodLevelResourceManagers</tt></a> для всіх відповідних компонентів у вашому кластері.</p>
<p>Перегляньте <a href="/uk/docs/tasks/administer-cluster/configure-feature-gates/">Увімкнення або вимкнення функціональних можливостей</a> для отримання додаткової інформації.</p>

                </details>
                </div>


Цей документ надає довідкові деталі щодо реалізації менеджерів ресурсів на рівні Podʼів у `kubelet`, включаючи структури звітування API PodResources та міграції форматів контрольних точок стану під час оновлень та понижень версій.

## API PodResources {#podresources-api}

У Kubernetes 1.37 локальний для вузла gRPC API `PodResources` `kubelet` нативно включає записи ресурсів на рівні Podʼів, коли увімкнено функціональну можливість `PodLevelResourceManagers`. Це дозволяє локальним для вузла агентам моніторингу та втулкам пристроїв запитувати ексклюзивні ресурси, призначені Podʼу:

- **Поля на рівні Podʼа:** gRPC-повідомлення `PodResources` включає поля верхнього рівня `cpu_ids` та `memory`, які представляють ексклюзивні CPU та вирівняні за NUMA блоки памʼяті, виділені всьому Podʼу.
- **Фільтрація на рівні контейнерів:** звітування на рівні контейнерів уникає подвійного підрахунку:
  - Контейнери, яким виділено індивідуальні ексклюзивні ресурси, повідомляють про конкретні виділені їм процесори та обсяг пам’яті у полі `ContainerResources`.
  - Контейнери, які спільно використовують ресурси в межах бюджету Podʼа (що працюють в ізольованому для Podʼа спільному пулі або спільному пулі вузла), залишають поля `cpu_ids` та `memory` на рівні контейнера порожніми, при цьому розподіл ресурсів відображається на рівні Podʼа.
- **Обчислення спільного пулу Podʼа:** споживачі API можуть обчислити ресурси у спільному пулі на рівні Podʼа, віднявши від обсягу ресурсів, виділених на рівні подів, об’єднання всіх ексклюзивних виділень на рівні контейнерів: `PodSharedPool.CpuIds = Pod.CpuIds - Union(all Container.CpuIds)`

Ось підсумок поведінки звітування API `PodResources`, коли вказано ресурси на рівні Podʼів:

### 1. Область дії менеджера топології: `pod` {#1-topology-manager-scope-pod}

Менеджер топології розподіляє бюджет ресурсів на рівні Podʼа. Поля на рівні Podʼа у `PodResources` заповнюються даними цього розподілу.



 





<table><caption style="display: none;">Звітування API PodResources для області дії pod</caption>
	<thead>
			<tr>
					<th style="text-align: left">Комбінація контейнерів</th>
					<th style="text-align: left"><code>cpu_ids</code> / <code>memory</code> на рівні Podʼа</th>
					<th style="text-align: left"><code>cpu_ids</code> / <code>memory</code> на рівні контейнера</th>
					<th style="text-align: left">Деталі / Примітки</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td style="text-align: left">Ексклюзивний контейнер (Guaranteed)</td>
					<td style="text-align: left">Заповнюється повним розподілом на рівні Podʼа.</td>
					<td style="text-align: left">Заповнюється виділеною підмножиною контейнера.</td>
					<td style="text-align: left">Контейнер отримує ексклюзивні CPU, вирізані з розподілу на рівні Podʼа.</td>
			</tr>
			<tr>
					<td style="text-align: left">Контейнер спільного пулу</td>
					<td style="text-align: left">Заповнюється повним розподілом на рівні Podʼа.</td>
					<td style="text-align: left">Порожньо</td>
					<td style="text-align: left">Уникає подвійного підрахунку, оскільки контейнер працює у спільному пулі Podʼа.</td>
			</tr>
	</tbody>
</table>


### 2. Область дії менеджера топології: `container` {#2-topology-manager-scope-container}

`kubelet` оцінює розподіл ресурсів для кожного контейнера. Поля API `PodResources` на рівні Podʼа залишаються порожніми.



 





<table><caption style="display: none;">Звітування API PodResources для області дії container</caption>
	<thead>
			<tr>
					<th style="text-align: left">Комбінація контейнерів</th>
					<th style="text-align: left"><code>cpu_ids</code> / <code>memory</code> на рівні Podʼа</th>
					<th style="text-align: left"><code>cpu_ids</code> / <code>memory</code> на рівні контейнера</th>
					<th style="text-align: left">Деталі / Примітки</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td style="text-align: left">Ексклюзивний контейнер (Guaranteed)</td>
					<td style="text-align: left">Порожньо</td>
					<td style="text-align: left">Заповнюється виділеними CPU/памʼяттю контейнера.</td>
					<td style="text-align: left">Контейнер отримує ексклюзивні виділення безпосередньо з пулу вузла, доступного для розподілу.</td>
			</tr>
			<tr>
					<td style="text-align: left">Контейнер спільного пулу</td>
					<td style="text-align: left">Порожньо</td>
					<td style="text-align: left">Порожньо</td>
					<td style="text-align: left">Працює у загальному спільному пулі вузла.</td>
			</tr>
	</tbody>
</table>


## Формати контрольних точок стану `kubelet` {#state-checkpoints}

`kubelet` підтримує локальні файли контрольних точок стану (`cpu_manager_state` та `memory_manager_state` у кореневій теці `kubelet`), щоб зберігати призначення ресурсів під час перезапусків при оновленнях та пониженнях версій `kubelet`.

### Формат контрольних точок у Kubernetes v1.36 {#checkpoint-format-in-kubernetes-v1-36}

У Kubernetes v1.36 увімкнення функціональної можливості `PodLevelResourceManagers` зберігало контрольні точки стану з використанням внутрішнього формату V3. Хоча оновлення до 1.36 є зворотно сумісним, формат V3 не має прямої сумісності. Якщо ви понизите версію `kubelet` 1.36 до 1.35 або старішої (або вимкнете функціональну можливість після активного використання у 1.36), старіший `kubelet` не зможе проаналізувати контрольні точки V3, не запуститься та видасть помилку `checkpoint is corrupted`.

Щоб відновитися, очистіть вузол, вручну видаліть файли контрольних точок (`cpu_manager_state` та `memory_manager_state`) і перезапустіть `kubelet`.

### Формат, сумісний із майбутніми версіями, у Kubernetes v1.37+ {#forward-compatible-format-in-kubernetes-v1-37}

У Kubernetes v1.37 файли контрольних точок використовують узагальнений формат V4, який вбудовує стандартну структуру V2. Це впроваджує внутрішній формат, сумісний із майбутніми версіями, щоб несумісність контрольних точок була разовою проблемою, а не тим, чого слід очікувати в майбутніх оновленнях:

- **Сумісність при оновленні та пониженні версії:** старіші версії `kubelet` можуть читати контрольні точки V4 без помилок пошкодження. Якщо ви понизите версію `kubelet` v1.37 до v1.36 (навіть з увімкненим `PodLevelResourceManagers` у 1.36), `kubelet` 1.36 безпечно відновить стандартні виділення контейнерів з V2.
- **Втрата записів на рівні Podʼів:** хоча `kubelet` запускається безпечно без пошкоджень, активні призначення ресурсів на рівні Podʼів (`PodEntries`) втрачаються при пониженні версії до v1.36.

Якщо ви не запускаєте Kubernetes v1.37, зверніться до документації для цієї версії Kubernetes для отримання інформації про оновлення та пониження версій.

## Дивіться також {#see-also}

- [Концепція менеджерів ресурсів на рівні Podʼів](/docs/concepts/resource-management/pod-level-resource-managers/): прочитайте сторінку концепції, щоб зрозуміти загальну архітектуру, вимоги до класу QoS та правила виділення менеджерів ресурсів для областей дії `pod` та `container`.
- [Призначення ресурсів CPU та памʼяті на рівні Podʼів](/docs/tasks/configure-pod-container/assign-pod-level-resources/): дізнайтеся, як налаштувати `.spec.resources` у маніфестах Podʼів для запиту обчислювальних ресурсів на рівні Podʼа.
- [Використання ресурсів на рівні Podʼів з менеджерами ресурсів `kubelet`](/docs/tutorials/cluster-management/use-pod-level-resource-managers/): пройдіть покроковий практичний навчальний посібник для налаштування `kubelet` та перевірки поведінки виділення.
- [Довідка з файлів стану `kubelet`](/docs/reference/node/kubelet-files/#resource-managers-state): дізнайтеся більше про те, де на файловій системі хосту зберігаються локальні файли контрольних точок стану (`cpu_manager_state` та `memory_manager_state`).