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

Стан функціоналу: Beta починаючи з Kubernetes v1.37; стандартно вимкнено
Докладніше про цей функціонал

Щоб скористатися цією функцією, вам (або адміністратору кластера) потрібно увімкнути функціональну можливість PodLevelResourceManagers для всіх відповідних компонентів у вашому кластері.

Перегляньте Увімкнення або вимкнення функціональних можливостей для отримання додаткової інформації.

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

API PodResources

У 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

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

Звітування API PodResources для області дії pod
Комбінація контейнерівcpu_ids / memory на рівні Podʼаcpu_ids / memory на рівні контейнераДеталі / Примітки
Ексклюзивний контейнер (Guaranteed)Заповнюється повним розподілом на рівні Podʼа.Заповнюється виділеною підмножиною контейнера.Контейнер отримує ексклюзивні CPU, вирізані з розподілу на рівні Podʼа.
Контейнер спільного пулуЗаповнюється повним розподілом на рівні Podʼа.ПорожньоУникає подвійного підрахунку, оскільки контейнер працює у спільному пулі Podʼа.

2. Область дії менеджера топології: container

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

Звітування API PodResources для області дії container
Комбінація контейнерівcpu_ids / memory на рівні Podʼаcpu_ids / memory на рівні контейнераДеталі / Примітки
Ексклюзивний контейнер (Guaranteed)ПорожньоЗаповнюється виділеними CPU/памʼяттю контейнера.Контейнер отримує ексклюзивні виділення безпосередньо з пулу вузла, доступного для розподілу.
Контейнер спільного пулуПорожньоПорожньоПрацює у загальному спільному пулі вузла.

Формати контрольних точок стану kubelet

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

Формат контрольних точок у 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+

У 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 для отримання інформації про оновлення та пониження версій.

Дивіться також

Востаннє змінено August 30, 2026 at 10:31 AM PST: [uk] Ukrainian translation (all-in-one) (ac41b20ac1)