Ця сторінка вводить класи обслуговування (Quality of Service, QoS) в Kubernetes та пояснює, як Kubernetes присвоює кожному Podʼа клас QoS як наслідок обмежень ресурсів, які ви вказуєте для контейнерів у цьому Podʼі. Kubernetes покладається на цю класифікацію для прийняття рішень про те, які Podʼи виводити при відсутності достатньої кількості ресурсів на вузлі.
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.
Podʼи, які мають клас Guaranteed, мають найстрогіші обмеження ресурсів і найменшу ймовірність бути виселеними. Гарантується, що їх не буде примусово завершено, доки вони не перевищать свої ліміти або доки не буде інших Podʼів з меншим пріоритетом, які можна витіснити з вузла. Вони можуть не отримувати ресурси поза вказаними лімітами. Ці Podʼи також можуть використовувати виключно власні CPU, використовуючи політику управління CPU типу static.
Щоб Pod отримав клас QoS Guaranteed:
Якщо ж Pod використовує ресурси на рівні Podʼа:
Kubernetes v1.34 [beta](стандартно увімкнено)Podʼи, які мають клас Burstable, мають гарантії ресурсів на основі запиту, але не вимагають конкретного ліміту. Якщо ліміт не вказано, він типово встановлюється рівним потужності вузла, що дозволяє Podʼам гнучко збільшувати свої ресурси, якщо це можливо. У разі виселення Podʼа через високий тиск на вузол ці Podʼи виселяються лише після виселення всіх Podʼів з класом BestEffort. Оскільки Burstable Pod може містити контейнер, який не має лімітів чи запитів ресурсів, Pod з класом Burstable може намагатися використовувати будь-яку кількість ресурсів вузла.
Pod отримує клас QoS Burstable, якщо:
Guaranteed.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.
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:memory.min встановлюється на запити памʼяті. Ядро не буде звільняти цю памʼять за жодних обставин.memory.low встановлюється на запити памʼяті. Ядро надає перевагу збереженню цієї памʼяті, але може звільнити її під час сильного тиску.Для роботи Memory QoS необхідна версія Linux із cgroup v2. Рекомендується використовувати ядро версії 5.9 або вище, оскільки обмеження memory.high у старих версіях ядра може спричинити відому помилку livelock. Якщо функція MemoryQoS увімкнена на старішому ядрі, kubelet записує попередження у журнал під час запуску.
Деяка поведінка є незалежною від класу QoS, який визначає Kubernetes. Наприклад:
Будь-який контейнер, що перевищує ліміт ресурсів, буде завершено та перезапущено kubelet без впливу на інші контейнери в цьому Podʼі.
Якщо контейнер перевищує свій запит ресурсу і вузол, на якому він працює, стикається з нестачею ресурсів, Pod, в якому він перебуває, стає кандидатом для виселення. Якщо це станеться, всі контейнери в цьому Podʼі будуть завершені. Kubernetes може створити новий Pod, зазвичай на іншому вузлі.
Запит ресурсів Podʼа дорівнює сумі запитів ресурсів його компонентних контейнерів, а ліміт Podʼа дорівнює сумі лімітів ресурсів його контейнерів.
Планувальник kube-scheduler не враховує клас QoS при виборі того, які Podʼи випереджати. Випередження може відбуватися, коли кластер не має достатньо ресурсів для запуску всіх визначених вами Podʼів.
Клас QoS визначається під час створення Podʼа і залишається незмінним протягом усього терміну існування Podʼа. Якщо пізніше ви спробуєте виконати зміну розміру на місці, що призведе до зміни класу QoS, зміна розміру буде відхилена під час перевірки допуску.