Менеджери ресурсів

Для забезпечення роботи робочих навантажень, для яких критично важлива низька затримка та висока пропускна здатність, Kubernetes пропонує набір менеджерів ресурсів. Ці менеджери призначені для координації та оптимізації розподілу ресурсів вузлів між подами, налаштованими з конкретними вимогами до ресурсів CPU, пристроїв та пам’яті (hugepages).

Менеджер топології

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [stable](стандартно увімкнено)

Менеджер топології — це компонент kubelet, який координує набір компонентів, відповідальних за ці оптимізації. Щоб дізнатися більше, прочитайте Керування політиками топології на вузлі.

Менеджер CPU

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [stable](стандартно увімкнено)

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

Політики призначення CPU подам

Після привʼязки Podʼа до вузла kubelet на цьому вузлі може потребувати або мультиплексування наявного апаратного забезпечення (наприклад, спільного використання CPU між кількома Podʼами), або виділення апаратного забезпечення шляхом резервування певних ресурсів (наприклад, виділення одного або кількох CPU для виключного використання одним Podʼом).

Зазвичай kubelet використовує CFS quota для забезпечення обмежень на використання CPU подами. Коли на вузлі працює багато подів, що завантажують CPU, робоче навантаження може переміщуватися між різними ядрами CPU залежно від того, чи обмежується под, і які ядра CPU доступні на момент планування. Багато робочих навантажень не чутливі до цього переміщення і тому працюють нормально без будь-якого втручання.

Однак у робочих навантаженнях, де спорідненість кешу CPU та затримка планування значно впливають на продуктивність, kubelet дозволяє використовувати альтернативні політики управління CPU для визначення деяких переваг розміщення на вузлі. Це реалізовано за допомогою Менеджера CPU та його політики. Існують дві доступні політики:

  • none: політика none явно включає наявну схему спорідненості CPU, не забезпечуючи спорідненості понад те, що автоматично робить планувальник ОС. Обмеження на використання CPU для подів Guaranteed та подів Burstable забезпечуються за допомогою CFS quota.
  • static: політика static дозволяє контейнерам у подах Guaranteed з цілими запитами CPU отримувати доступ до ексклюзивних CPU на вузлі. Ця ексклюзивність забезпечується за допомогою cpuset cgroup controller.

Примітка:

Системні служби, такі як середовище виконання контейнерів та сам kubelet, можуть і надалі працювати на цих виділених процесорах. Виключність поширюється лише на інші поди.

Менеджер CPU не підтримує відключення та підключення CPU під час виконання.

Політика static

Політика static дозволяє більш детально керувати CPU та забезпечує ексклюзивне призначення CPU. Ця політика керує спільним пулом CPU, який спочатку містить усі CPU на вузлі. Кількість CPU, доступних для ексклюзивного призначення, дорівнює загальній кількості CPU на вузлі за винятком будь-яких резервувань CPU, встановлених у конфігурації kubelet. CPU, зарезервовані цими параметрами, беруться у цілому числі з початкового спільного пулу у порядку зростання за фізичним ідентифікатором ядра. Цей спільний пул є набором CPU, на яких працюють будь-які контейнери в подах BestEffort та Burstable. Контейнери в подах Guaranteed з дробовими запитами CPU також працюють на CPU зі спільного пулу. Лише контейнери, які є частиною пода Guaranteed і мають цілі запити CPU, отримують ексклюзивні CPU.

Примітка:

Kubelet вимагає резервування CPU більше нуля, коли політика static увімкнена. Це тому, що нульове резервування CPU дозволило б спільному пулу стати порожнім.

Коли поди Guaranteed, контейнери яких відповідають вимогам для статичного призначення, плануються на вузлі, CPU видаляються зі спільного пулу та розміщуються в cpuset для контейнера. CFS quota не використовується для обмеження використання CPU цими контейнерами, оскільки їхнє використання обмежується самим доменом планування. Іншими словами, кількість CPU в cpuset контейнера дорівнює цілому числу CPU limit, зазначеному в специфікації пода. Це статичне призначення підвищує спорідненість CPU та зменшує перемикання контексту через обмеження для навантаження, що залежить від CPU.

Розглянемо контейнери в наступних специфікаціях пода:

spec:
  containers:
  - name: nginx
    image: nginx

Под вище працює в класі QoS BestEffort, оскільки не вказано жодних ресурсних requests або limits. Він працює в спільному пулі.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

Под вище працює в класі QoS Burstable, оскільки ресурсні requests не дорівнюють limits, а кількість cpu не вказана. Він працює в спільному пулі.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "100Mi"
        cpu: "1"

Под вище працює в класі QoS Burstable, оскільки ресурсні requests не дорівнюють limits. Він працює в спільному пулі.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "200Mi"
        cpu: "2"

Под вище працює в класі QoS Guaranteed, оскільки requests дорівнюють limits. І обмеження ресурсу CPU для контейнера є цілим числом, більшим або рівним одиниці. Контейнер nginx отримує 2 ексклюзивні CPU.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "1.5"
      requests:
        memory: "200Mi"
        cpu: "1.5"

Под вище працює в класі QoS Guaranteed, оскільки requests дорівнюють limits. Але обмеження ресурсу CPU для контейнера є дробовим числом. Він працює в спільному пулі.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"

Под вище працює в класі QoS Guaranteed, оскільки requests дорівнюють limits. І обмеження ресурсу CPU для контейнера є цілим числом, більшим або рівним одиниці. Контейнер nginx отримує 2 ексклюзивні CPU.

Параметри політики Static

Ось доступні параметри політики static управління CPU, перераховані в алфавітному порядку:

align-by-socket (alpha, зазвичай приховано)
Вирівнювання CPU за фізичним пакетом / сокетом, а не за логічними межами NUMA (доступно з Kubernetes v1.25)
distribute-cpus-across-cores (alpha, зазвичай приховано)
Розподіл віртуальних ядер, іноді званих апаратними потоками, по різних фізичних ядрах (доступно з Kubernetes v1.31)
distribute-cpus-across-numa (beta, зазвичай видно)
Розподіл CPU по різних доменах NUMA, з метою досягнення рівномірного балансу між обраними доменами (доступно з Kubernetes v1.23)
full-pcpus-only (GA, зазвичай видно)
Завжди виділяти повні фізичні ядра (доступно з Kubernetes v1.22, GA з Kubernetes v1.33)
strict-cpu-reservation (GA, зазвичай видно)
Запобігання запуску всіх подів незалежно від їх класу якості обслуговування на зарезервованих CPU (доступно з Kubernetes v1.32, GA з Kubernetes v1.35)
prefer-align-cpus-by-uncorecache (GA, зазвичай видно)
Вирівнювання CPU за межами кешу uncore (Last-Level) на основі найкращих зусиль (доступно з Kubernetes v1.32)

Ви можете вмикати або вимикати групи параметрів залежно від їх рівня зрілості, використовуючи наступні функціональні ворота:

  • CPUManagerPolicyBetaOptions (мтандартно увімкнено). Вимкніть, щоб приховати параметри рівня beta.
  • CPUManagerPolicyAlphaOptions (мтандартно вимкнено). Увімкніть, щоб показати параметри рівня alpha.

Вам все одно доведеться увімкнути кожен параметр, використовуючи поле cpuManagerPolicyOptions у файлі конфігурації kubelet.

Щоб дізнатися більше про окремі параметри, які можна налаштувати, читайте далі.

full-pcpus-only

Якщо вказано параметр full-pcpus-only політики, політика static завжди виділятиме повні фізичні ядра. Зазазвичай, без цього параметра, політика static виділяє CPU, використовуючи топологічно-орієнтоване найкраще підходяще розміщення. На системах з увімкненим SMT політика може виділяти окремі віртуальні ядра, які відповідають апаратним потокам. Це може призвести до того, що різні контейнери будуть використовувати одні й ті ж фізичні ядра; така поведінка, у свою чергу, сприяє проблемі шумних сусідів. З увімкненим параметром, под буде прийнято kubelet лише в тому випадку, якщо запит CPU всіх його контейнерів може бути виконаний шляхом виділення повних фізичних ядер. Якщо под не отримує допуск, він буде переведений у стан Failed з повідомленням SMTAlignmentError.

distribute-cpus-across-numa

Якщо вказано параметр distribute-cpus-across-numa, політика static рівномірно розподіляє CPU між NUMA-вузлами у випадках, коли для задоволення виділення потрібно більше одного NUMA-вузла. Стандартно, CPUManager розміщує CPU на одному NUMA-вузлі, поки він не заповниться, а залишкові CPU просто переходять до наступного NUMA-вузла. Це може спричинити небажані вузькі місця в паралельному коді, що використовує барʼєри (та подібні примітиви синхронізації), оскільки такий код зазвичай працює лише так швидко, як його найповільніший працівник (який сповільнюється через те, що на принаймні одному NUMA-вузлі доступно менше CPU). Розподіляючи CPU рівномірно між NUMA-вузлами, розробники застосунків можуть легше забезпечити, щоб жоден працівник не страждав від ефектів NUMA більше, ніж інші, покращуючи загальну продуктивність таких застосунків.

align-by-socket

Якщо вказано параметр align-by-socket, CPU будуть вважатися вирівняними на межі сокета при прийнятті рішення про виділення CPU контейнеру. Стандартно, CPUManager вирівнює виділення CPU на межі NUMA, що може призвести до зниження продуктивності, якщо для задоволення виділення потрібно більше одного NUMA-вузла. Хоча він намагається забезпечити виділення всіх CPU з мінімальної кількості NUMA-вузлів, немає гарантії, що ці NUMA-вузли будуть на одному сокеті. Направляючи CPUManager явно вирівнювати CPU на межі сокета замість межі NUMA, ми можемо уникнути таких проблем. Зверніть увагу, що цей параметр політики не сумісний з політикою single-numa-node TopologyManager і не застосовується до апаратного забезпечення, де кількість сокетів перевищує кількість NUMA-вузлів.

distribute-cpus-across-cores

Якщо вказано параметр distribute-cpus-across-cores, політика static намагатиметься виділяти віртуальні ядра (апаратні потоки) на різних фізичних ядрах. Стандартно, CPUManager намагається розміщувати CPU на якомога меншій кількості фізичних ядер, що може призвести до конкуренції між CPU на одному фізичному ядрі та спричинити вузькі місця у продуктивності. Увімкнувши параметр distribute-cpus-across-cores, політика static забезпечує розподіл CPU на якомога більшій кількості фізичних ядер, зменшуючи конкуренцію на одному фізичному ядрі та покращуючи загальну продуктивність. Однак важливо зазначити, що ця стратегія може бути менш ефективною при високому навантаженні системи. У таких умовах користь від зменшення конкуренції зменшується. Навпаки, стандартна поведінка може допомогти зменшити накладні витрати на міжядерну комунікацію, потенційно забезпечуючи кращу продуктивність при високому навантаженні.

strict-cpu-reservation

Параметр reservedSystemCPUs у KubeletConfiguration, або застаріла опція командного рядка kubelet --reserved-cpus, визначає явний набір CPU для системних демонів ОС та демонів Kubernetes. Більше деталей про цей параметр можна знайти на сторінці Явно зарезервований список CPU. Стандартно, ця ізоляція реалізується лише для гарантованих подів з цілими запитами CPU, а не для подів з можливістю перевантаження та подів з найкращим зусиллям (та гарантованих подів з дробовими запитами CPU). Допуск здійснюється лише шляхом порівняння запитів CPU з доступними CPU. Оскільки ліміт CPU вищий за запит, стандартна поведінка дозволяє подам з можливістю перевантаження та подам з найкращим зусиллям використовувати всю ємність reservedSystemCPUs і спричиняти нестачу ресурсів для служб ОС у реальних розгортаннях. Якщо параметр політики strict-cpu-reservation увімкнено, політика static не дозволить жодному робочому навантаженню використовувати ядра CPU, зазначені в reservedSystemCPUs.

prefer-align-cpus-by-uncorecache

Якщо вказано параметр prefer-align-cpus-by-uncorecache, політика static виділятиме ресурси CPU для окремих контейнерів таким чином, щоб усі CPU, призначені контейнеру, використовували один і той же блок кешу uncore (також відомий як кеш останнього рівня або LLC). Зазвичай CPUManager щільно розподіляє призначення CPU, що може призвести до того, що контейнери отримують CPU з кількох кешів uncore. Ця опція дозволяє CPUManager виділяти CPU таким чином, щоб максимально ефективно використовувати кеш uncore. Виділення здійснюється на основі найкращих зусиль, намагаючись призначити якомога більше CPU в межах одного кешу uncore. Якщо вимога контейнера щодо CPU перевищує ємність одного кешу uncore, CPUManager мінімізує кількість використаних кешів uncore, щоб підтримувати оптимальне вирівнювання кешу uncore. Конкретні робочі навантаження можуть отримати вигоду у продуктивності від зменшення затримки між кешами та шумних сусідів на рівні кешу. Якщо CPUManager не може оптимально вирівняти CPU при наявності достатніх ресурсів на вузлі, контейнер все одно буде прийнято з використанням стандартного щільного розподілу.

Менеджер памʼяті

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.32 [stable](стандартно увімкнено)

Memory Manager є компонентом kubelet, який забезпечує ексклюзивне виділення ресурсів памʼяті. Він консультується з Topology Manager для прийняття рішень щодо призначення ресурсів. Щоб дізнатися більше, прочитайте Керування політиками управління памʼяттю на вузлі.

Політики призначення памʼяті для подів

В Kubernetes Memory Manager виділяє ресурси оперативної памʼяті (RAM, а також за потреби великі сторінки Linux) для подів у QoS class Guaranteed .

Memory Manager використовує протокол генерації підказок для визначення найбільш підходящої NUMA-спорідненості для пода. Memory Manager передає ці підказки центральному менеджеру (Topology Manager). На основі як підказок, так і політики Topology Manager, под приймається або відхиляється на вузлі.

Більше того, Memory Manager забезпечує, щоб памʼять, яку запитує под, виділялася з мінімальної кількості NUMA-вузлів.

Щоб дізнатися більше, прочитайте Керування політиками управління памʼяттю на вузлі.

Менеджер пристроїв

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [stable]

Device Manager є компонентом kubelet, який виділяє апаратні пристрої для подів за допомогою API втулків пристроїв. Він консультується з Topology Manager, використовуючи інформацію про топологію, надану втулками пристроїв, для прийняття рішень щодо призначення ресурсів. Щоб дізнатися більше, прочитайте Інтеграція втулків пристроїв з Topology Manager.

Менеджер ресурсів на рівні подів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.36 [alpha](стандартно вимкнено)

Підтримка ресурсів на рівні подів для наявних менеджерів ресурсів (Topology, CPU та Memory) розширює їх для обробки специфікацій ресурсів на рівні подів. Коли ця функція увімкнена (через прапори функцій PodLevelResources та PodLevelResourceManagers), менеджери ресурсів можуть використовувати .spec.resources безпосередньо як основу для своїх рішень щодо виділення ресурсів, переходячи від строго контейнерного моделювання до моделювання орієнтованого на поди. Ця схема розподілу вводить більш гнучку та потужну модель управління ресурсами, особливо для робочих навантажень, чутливих до продуктивності. Вона дозволяє визначати гібридні моделі розподілу, де деякі контейнери в поді отримують ексклюзивні ресурси, вирівняні за NUMA, тоді як інші ділять залишкові ресурси з загального пулу на рівні пода.

Важливо розрізняти можливості, які пропонує кожна область дії Topology Manager, і як це змінює поведінку менеджерів ресурсів. Область дії pod дозволяє виділення на основі бюджету всього пода, створюючи спільний пул на рівні пода для контейнерів, які не мають статусу Guaranteed, поряд з ексклюзивними виділеннями. На відміну від цього, область дії container дозволяє гібридну модель виділення, де окремі контейнери можуть отримувати ексклюзивні ресурси, вирівняні за NUMA, тоді як інші працюють у спільному пулі вузла, без вирівнювання всього пода як єдиного блоку.

Як стандартні контейнери ініціалізації, так і контейнери ініціалізації з перезапуском (sidecars) повністю підтримуються. Вони можуть отримувати ексклюзивні частини ресурсів або використовувати спільний пул пода, і їхні правила життєвого циклу (наприклад, повторне використання ресурсів для стандартних контейнерів ініціалізації проти постійних резервувань для sidecars) дотримуються менеджерами ресурсів на рівні подів.

Глосарій

Специфікація ресурсів на рівні подів
Бюджет ресурсів, визначений на рівні пода в .spec.resources, який визначає колективні запити та обмеження для всього пода.
Контейнер Guaranteed
У контексті цієї функції контейнер вважається Guaranteed, якщо він вказує запити ресурсів, рівні його обмеженням для обох CPU (ексклюзивне виділення CPU вимагає позитивного цілого значення) та памʼяті. Цей статус робить його придатним для ексклюзивного виділення ресурсів від менеджерів ресурсів.
Ексклюзивний slice
Виділена частина ресурсів (наприклад, конкретні CPU або сторінки памʼяті), призначена виключно для одного контейнера, що забезпечує ізоляцію від інших контейнерів.
Спільний пул пода
Підмножина ресурсів, виділених поду, яка залишається після резервування всіх ексклюзивних sliceʼів. Ці ресурси спільно використовуються всіма контейнерами в поді, які не отримали ексклюзивного виділення. Хоча контейнери в цьому пулі ділять ресурси між собою, вони суворо ізольовані від ексклюзивних sliceʼів і загального пулу вузла.

Як працюють менеджери ресурсів на рівні подів

Менеджери ресурсів CPU та памʼяті працюють по-різному залежно від налаштованої області дії Topology Manager.

Область дії менеджера топології та ресурси на рівні подів

Коли область дії Topology Manager встановлена на pod, Kubelet виконує одне вирівнювання NUMA для всього пода на основі бюджету ресурсів, визначеного в .spec.resources.

Отриманий NUMA-вирівняний пул ресурсів потім розподіляється:

  1. Ексклюзивні sliceʼи: Контейнери, які вказують ресурси Guaranteed (запити рівні обмеженням для обох CPU та памʼяті, і запит CPU є позитивним цілим числом), отримують ексклюзивні sliceʼи з загального виділення пода.
  2. Спільний пул пода: Залишкові ресурси формують спільний пул, який використовується всіма іншими контейнерами в поді, які не отримали ексклюзивного виділення. Хоча контейнери в цьому пулі ділять ресурси між собою, вони суворо ізольовані від ексклюзивних sliceʼів і загального пулу вузла.

Зважте, що коли стандартні init-контейнери завершують виконання, їхні ресурси додаються до повторно використовуваного набору на рівні пода, а не повертаються до пулу ресурсів вузла. Оскільки вони виконуються послідовно, ці ресурси стають повторно використовуваними для наступних контейнерів застосунків (або для їхніх власних ексклюзивних sliceʼів, або для спільного пулу).

Це дозволяє розміщувати контейнери, які потребують ексклюзивних ресурсів (наприклад, високопродуктивний основний застосунок), разом з тими, які цього не потребують (наприклад, sidecars для логування або моніторингу), все в межах одного NUMA-вирівняного пода.

Розгляньте контейнери в наступній специфікації пода, де область дії Topology Manager встановлена на pod, а под має загальний бюджет у 4 CPU. main-app запитує ексклюзивний slice на 2 CPU, тоді як sidecars ділять залишкові 2 CPU в спільному пулі пода:

pods/resource/pod-level-resource-managers-pod-scope-mixed.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-scope-mixed
  annotations:
    kubernetes.io/description: "A pod demonstrating pod-level scope where one container gets exclusive resources and others share the remaining pod resources in a shared pool."
spec:
  # На рівні Podʼа, Pod має запит на CPU, рівний лімітам, і запит на памʼять також
  # рівний лімітам памʼяті. Контейнер main-app відповідає вимогам для класу QoS
  # Guaranteed на рівні контейнера, а sidecar контейнери не вказують жодного
  # запиту на ресурси. У межах масштабу Podʼа kubelet може статично призначити
  # 4 CPU для всього Podʼа, з яких 2 призначені ексклюзивно для контейнера
  # main-app, а решта 2 спільно використовуються sidecar контейнерами.
  resources:
    requests:
      cpu: "4"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "4Gi"
  initContainers:
  - name: metrics-sidecar
    image: registry.example/example-image:v1
    restartPolicy: Always
  - name: logging-sidecar
    image: registry.example/example-image:v1
    restartPolicy: Always
  containers:
  - name: main-app
    image: registry.example/example-image:v1
    resources:
      requests:
        cpu: "2"
        memory: "2Gi"
      limits:
        cpu: "2"
        memory: "2Gi"

Важливі міркування:

При використанні ресурсів на рівні пода з областю дії Topology Manager на рівні пода існують деякі важливі міркування:

  • Обмеження порожнього спільного пулу: Ця конфігурація не дозволяє специфікації пода, які призвели б до порожнього спільного пулу пода, якщо є контейнери, які його потребують. Якщо сума запитів ресурсів від усіх контейнерів, які мають Guaranteed, точно дорівнює загальному бюджету ресурсів, і є принаймні один інший контейнер, який потребує спільного пулу, под буде відхилено в процесі допуску.

    Наприклад, наступний под запитує бюджет на рівні пода у 4 CPU. main-app потребує ексклюзивні 3 CPU, а metrics-sidecar потребує ексклюзивні 1 CPU. Оскільки в спільному пулі для logging-sidecar залишилося 0 CPU, цей под відхиляється (те саме правило застосовується для памʼяті):

    pods/resource/pod-level-resource-managers-empty-shared-pool.yaml 
    apiVersion: v1
  kind: Pod
  metadata:
    name: empty-shared-pool
    annotations:
      kubernetes.io/description: "A pod demonstrating a configuration that is rejected because exclusive containers consume the entire pod resource budget, leaving no resources for the remaining container in the shared pool."
  spec:
    # На рівні Podʼа, Pod має запит на CPU, рівний лімітам, і запит на памʼять також
    # рівний лімітам памʼяті. Контейнер main-app і metrics-sidecar відповідають вимогам для
    # класу QoS Guaranteed на рівні контейнера, а контейнер logging-sidecar не вказує
    # жодного запиту на ресурси. Оскільки контейнери Guaranteed споживають весь ресурсний
    # бюджет Podʼа, залишаючи 0 CPU для спільного пулу, необхідного для logging-sidecar,
    # цей Pod буде відхилено при допуску.
    resources:
      requests:
        cpu: "4"
        memory: "4Gi"
      limits:
        cpu: "4"
        memory: "4Gi"
    initContainers:
    - name: metrics-sidecar
      image: registry.example/example-image:v1
      restartPolicy: Always
      resources:
        requests:
          cpu: "1"
          memory: "1Gi"
        limits:
          cpu: "1"
          memory: "1Gi"
    - name: logging-sidecar
      image: registry.example/example-image:v1
      restartPolicy: Always
    containers:
    - name: main-app
      image: registry.example/example-image:v1
      resources:
        requests:
          cpu: "3"
          memory: "3Gi"
        limits:
          cpu: "3"
          memory: "3Gi"

  • Змарновані ресурси: Будь-які ресурси, які були перевиділені при використанні області дії pod (загальна сума запитів контейнерів менша за бюджет на рівні пода і немає контейнерів у спільному пулі, або контейнери спільного пулу не повністю використовують залишкову кількість), будуть призначені та зарезервовані для пода, фактично марнуватись протягом усього виконання пода.

  • Постійний пул: Загальний пул ресурсів пода (вирівнювання NUMA та загальна зарезервована ємність) є постійним. Якщо контейнер спільного пулу аварійно завершує роботу та перезапускається, загальна резервація ресурсів пода залишається надійно закріпленою на вузлі. Ресурси повертаються до загального пулу вузла лише після завершення всього пода.

Область дії контейнера Topology Manager та ресурси на рівні пода

Коли область дії Topology Manager встановлена на container, Kubelet оцінює кожен контейнер окремо для ексклюзивного виділення.

Якщо загальний под досягає класу QoS Guaranteed (через наявність відповідних значень у ресурсах на рівні пода .spec.resources), ви можете комбінувати контейнери:

  • Контейнери з власними запитами Guaranteed отримують ексклюзивні ресурси, вирівняні за NUMA.
  • Інші контейнери non-Guaranteed у поді працюють у спільному пулі вузла.
  • Колективне споживання ресурсів усіх контейнерів все ще контролюється обмеженнями .spec.resources пода.

Ця область дії корисна, коли у вас є інфраструктурний sidecar, який потребує вирівнювання до конкретного вузла NUMA для доступу до пристроїв, тоді як основне навантаження може працювати у загальному спільному пулі вузла.

Розглянемо контейнери у наступній специфікації пода, де область дії Topology Manager встановлена на container, а под представляє робоче навантаження з інфраструктурним sidecar та двома виконавцями застосунків, з загальним бюджетом у 4 CPU. infrastructure-sidecar отримує ексклюзивний, вирівняний за NUMA, 2 CPU фрагмент. Два виконавці застосунків (worker-1 та worker-2) працюють у загальному, вузловому спільному пулі:

pods/resource/pod-level-resource-managers-container-scope-mixed.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: container-scope-mixed
  annotations:
    kubernetes.io/description: "A pod demonstrating container-level scope where one container gets exclusive resources and others run in the node's shared pool."
spec:
  # На рівні Podʼа, Pod має запит на CPU, рівний лімітам, і запит на памʼять також
  # рівний лімітам памʼяті. Контейнер infrastructure-sidecar відповідає вимогам для
  # класу QoS Guaranteed на рівні контейнера, а робочі контейнери не вказують
  # жодного запиту на ресурси. У межах контейнерного масштабу kubelet оцінює
  # контейнери індивідуально для ексклюзивного виділення. Це означає, що
  # infrastructure-sidecar отримує ексклюзивний фрагмент CPU на 2 ядра, тоді як
  # робочі контейнери працюють у загальному пулі вузла, все це обмежено загальними
  # лімітами Podʼа.
  resources:
    requests:
      cpu: "4"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "4Gi"
  initContainers:
  - name: infrastructure-sidecar
    image: registry.example/example-image:v1
    restartPolicy: Always
    resources:
      requests:
        cpu: "2"
        memory: "2Gi"
      limits:
        cpu: "2"
        memory: "2Gi"
  containers:
  - name: worker-1
    image: registry.example/example-image:v1
  - name: worker-2
    image: registry.example/example-image:v1

CPU quota (CFS)

Коли ви запускаєте змішані робочі навантаження в межах пода, ізоляція забезпечується по-різному залежно від виділення:

  • Ексклюзивні контейнери: Контейнери, яким надано ексклюзивні CPU, мають вимкнене застосування квоти CPU CFS, що дозволяє їм працювати без обмежень з боку планувальника Linux.
  • Контейнери спільного пулу пода: Контейнери, що потрапляють у спільний пул пода, мають увімкнені квоти CPU CFS, що забезпечує їхнє споживання не більше залишкового бюджету пода та запобігає втручанню в роботу ексклюзивних контейнерів.

Постійний пул і перезапуски

Загальний пул ресурсів пода (вирівнювання NUMA та загальна зарезервована ємність) є постійним. Якщо контейнер, що використовує спільний пул пода, аварійно завершує роботу та перезапускається, загальне резервування ресурсів пода залишається надійно закріпленим на вузлі. Ресурси звільняються назад у загальний пул вузла лише після завершення роботи всього пода.

Пониження версії Kubelet та контрольні точки стану

Увага:

Увімкнення функції PodLevelResourceManagers вводить нові версії стану для менеджерів CPU та памʼяті.

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

Спостережуваність та метрики

Ви можете відстежувати поведінку та стан менеджерів ресурсів як на рівні контейнерів, так і на рівні подів, використовуючи наступні метрики Kubelet (увімкнені через функціональний прапорець PodLevelResourceManagers):

  • resource_manager_allocations_total: Підраховує загальну кількість ексклюзивних виділень ресурсів, виконаних менеджером. Мітка source ("pod" або "node") відрізняє виділення з пулу на рівні вузла від попередньо виділеного пулу на рівні пода.
  • resource_manager_allocation_errors_total: Підраховує помилки, що виникають під час ексклюзивного виділення ресурсів, відрізняючи за призначеним джерелом виділення source ("pod" або "node").
  • resource_manager_container_assignments: Відстежує кумулятивну кількість контейнерів, яким буде надано певний тип призначення ресурсів. Мітка assignment_type ("node_exclusive", "pod_exclusive", "pod_shared") надає видимість того, скільки контейнерів працюють з ексклюзивними ресурсами (з вузлового або подового пулу) порівняно з подовим спільним пулом.

Обмеження та застереження

  • Функціональність реалізована лише для політики менеджера CPU static та політики менеджера памʼяті Static. Зверніть увагу, що політика BestEffort не підтримується для менеджера памʼяті.
  • Ця функція підтримується лише на вузлах під управлінням Linux. На вузлах під управлінням Windows менеджери ресурсів не виконуватимуть жодних дій щодо розподілу ресурсів на рівні подів.

Що далі

За більш детальною інформацією про менеджери ресурсів на рівні вузла звертайтеся до наступних розділів:

За більш детальною інформацією про налаштування та використання менеджерів ресурсів на рівні подів звертайтеся до наступних розділів:

Востаннє змінено May 05, 2026 at 3:37 PM PST: [uk] Ukrainian translation (all-in-one) (f7bdd3ee72)