Класи якості обслуговування (Quality of Service) Podʼів

Ця сторінка вводить класи обслуговування (Quality of Service, QoS) в Kubernetes та пояснює, як Kubernetes присвоює кожному Podʼа клас QoS як наслідок обмежень ресурсів, які ви вказуєте для контейнерів у цьому Podʼі. Kubernetes покладається на цю класифікацію для прийняття рішень про те, які Podʼи виводити при відсутності достатньої кількості ресурсів на вузлі.

Класи обслуговування (QoS)

Kubernetes класифікує Podʼи, які ви запускаєте, і розподіляє кожен Pod в певний клас обслуговування (Quality of Service, QoS). Kubernetes використовує цю класифікацію для впливу на те, як різні Podʼи обробляються. Kubernetes робить цю класифікацію на основі резервів ресурсів контейнерів у цьому Podʼі, а також того, як ці резерви стосуються обмежень ресурсів. Це відомо як клас обслуговування (Quality of Service, QoS). Kubernetes присвоює кожному Podʼу клас QoS на основі запитів та лімітів ресурсів його складових контейнерів. Класи QoS використовуються Kubernetes для вирішення того, які Podʼи виводити з вузла, який переживає високий тиск на вузол. Можливі класи QoS: Guaranteed, Burstable та BestEffort.

Guaranteed

Podʼи, які мають клас Guaranteed, мають найстрогіші обмеження ресурсів і найменшу ймовірність бути виселеними. Гарантується, що їх не буде примусово завершено, доки вони не перевищать свої ліміти або доки не буде інших Podʼів з меншим пріоритетом, які можна витіснити з вузла. Вони можуть не отримувати ресурси поза вказаними лімітами. Ці Podʼи також можуть використовувати виключно власні CPU, використовуючи політику управління CPU типу static.

Критерії

Щоб Pod отримав клас QoS Guaranteed:

  • Кожеен контейнер в Podʼі повинен мати ліміт та запит на памʼять, обидва більші за нуль.
  • Для кожного контейнера у Podʼі ліміт памʼяті повинен дорівнювати запиту памʼяті.
  • Кожеен контейнер в Podʼі повинен мати ліміт та запит на CPU, обидва більші за нуль.
  • Для кожного контейнера у Podʼі ліміт CPU повинен дорівнювати запиту CPU.

Якщо ж Pod використовує ресурси на рівні Podʼа:

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.34 [beta](стандартно увімкнено)
  • Pod повинен мати обмеження памʼяті на рівні Podʼа і запит на памʼять, і їхні значення повинні бути рівними.
  • Pod повинен мати обмеження та запит на використання процесора на рівні Podʼа, і їхні значення повинні бути рівними.

Burstable

Podʼи, які мають клас Burstable, мають гарантії ресурсів на основі запиту, але не вимагають конкретного ліміту. Якщо ліміт не вказано, він типово встановлюється рівним потужності вузла, що дозволяє Podʼам гнучко збільшувати свої ресурси, якщо це можливо. У разі виселення Podʼа через високий тиск на вузол ці Podʼи виселяються лише після виселення всіх Podʼів з класом BestEffort. Оскільки Burstable Pod може містити контейнер, який не має лімітів чи запитів ресурсів, Pod з класом Burstable може намагатися використовувати будь-яку кількість ресурсів вузла.

Критерії

Pod отримує клас QoS Burstable, якщо:

  • Pod не відповідає критеріям класу QoS Guaranteed.
  • Принаймні один Контейнер у Podʼі має запит або обмеження щодо памʼіяті чи CPU, або Pod має запит або обмеження щодо памʼяті чи CPU на рівні Pod.

BestEffort

Podʼи в класі BestEffort можуть використовувати ресурси вузла, які не призначені спеціально для Podʼів інших класів QoS. Наприклад, якщо у вузлі є 16 ядер CPU, і ви призначили 4 ядра CPU під Pod із класом Guaranteed, тоді Pod з класом BestEffort може намагатися використовувати будь-яку кількість решти з 12 ядер CPU.

Kubelet віддає перевагу виселенню Podʼів з класом BestEffort, якщо вузол потрапляє в стан тиску на ресурси.

Критерії

Pod має клас QoS BestEffort, якщо він не відповідає критеріям а ні Guaranteed, а ні Burstable. Іншими словами, Pod має клас BestEffort лише в тому випадку, якщо жоден з контейнерів у Podʼі не має ліміту або запиту памʼяті, і жоден з контейнерів у Podʼі не має ліміту або запиту CPU, а Pod не має жодних обмежень або запитів щодо памʼяті або CPU на рівні Podʼа. Контейнери в Podʼі можуть запитувати інші ресурси (не CPU чи памʼять) і все одно класифікуватися як BestEffort.

QoS памʼяті з cgroup v2

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

Memory QoS використовує контролер памʼяті cgroup v2 для управління обмеженням пропускної здатності та захистом пам'яті в Kubernetes. Ця функція використовує клас QoS Pod для визначення, які налаштування cgroup слід застосувати, але є окремою функцією, яку потрібно вмикати вручну. Вимкнення Memory QoS не впливає на класифікацію Pod.

Обмеження використання памʼяті

Для подів типу Burstable kubelet встановлює значення memory.high, щоб обмежити виділення памʼяті до того, як робоче навантаження досягне свого жорсткого обмеження (memory.max). Поріг обмеження обчислюється за такою формулою:

memory.high = requests + memoryThrottlingFactor * (limits - requests)

де memoryThrottlingFactor зазвичай дорівнює 0,9. Наприклад, контейнер із запитом 256 МіБ і лімітом 1 ГіБ отримає memory.high, встановлений приблизно на 947 МіБ. Якщо контейнер Burstable не має обмеження памʼяті, використовується доступна памʼять вузла замість ліміту.

Поди Guaranteed не отримують memory.high, оскільки їхні запити дорівнюють лімітам. Поди BestEffort не отримують memory.high, оскільки вони не мають запитів або лімітів.

Налаштування резервування памʼяті

Резервування памʼяті контролюється через поле конфігурації kubelet memoryReservationPolicy:

  • None (стандартно): kubelet не встановлює memory.min або memory.low для контейнерів і подів. Жодна памʼять не блокується ядром.
  • TieredReservation: kubelet встановлює багаторівневий захист памʼяті на основі класу QoS Pod:
    • Guaranteed поди: memory.min встановлюється на запити памʼяті. Ядро не буде звільняти цю памʼять за жодних обставин.
    • Burstable поди: memory.low встановлюється на запити памʼяті. Ядро надає перевагу збереженню цієї памʼяті, але може звільнити її під час сильного тиску.
    • BestEffort поди: захист памʼяті не встановлюється.

Системні вимоги

Для роботи Memory QoS необхідна версія Linux із cgroup v2. Рекомендується використовувати ядро версії 5.9 або вище, оскільки обмеження memory.high у старих версіях ядра може спричинити відому помилку livelock. Якщо функція MemoryQoS увімкнена на старішому ядрі, kubelet записує попередження у журнал під час запуску.

Деяка поведінка незалежна від класу QoS

Деяка поведінка є незалежною від класу QoS, який визначає Kubernetes. Наприклад:

  • Будь-який контейнер, що перевищує ліміт ресурсів, буде завершено та перезапущено kubelet без впливу на інші контейнери в цьому Podʼі.

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

  • Запит ресурсів Podʼа дорівнює сумі запитів ресурсів його компонентних контейнерів, а ліміт Podʼа дорівнює сумі лімітів ресурсів його контейнерів.

  • Планувальник kube-scheduler не враховує клас QoS при виборі того, які Podʼи випереджати. Випередження може відбуватися, коли кластер не має достатньо ресурсів для запуску всіх визначених вами Podʼів.

  • Клас QoS визначається під час створення Podʼа і залишається незмінним протягом усього терміну існування Podʼа. Якщо пізніше ви спробуєте виконати зміну розміру на місці, що призведе до зміни класу QoS, зміна розміру буде відхилена під час перевірки допуску.

Що далі

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