Memory QoS переходить у бета-версію в Kubernetes v1.37 і тепер стандартно увімкнено. На вузлах Linux, що працюють з cgroup v2, ця функція використовує контролер пам’яті, щоб надати ядру кращі вказівки щодо обробки пам’яті контейнера. Вперше вона була представлена як альфа у v1.22 і розширена у v1.36 з багаторівневою резервацією пам’яті.
У цьому дописі розглядається, що змінилося у v1.37, що означає перехід у бета-версію для операторів кластерів і як налаштувати цю функцію.
Функціональна можливість MemoryQoS тепер у статусі Beta у v1.37. Це означає, що у кожного kubelet версії v1.37 ця функціональна можливість увімкнена без будь-яких змін у конфігурації. Увімкнення функції як стандартної є безпечним, оскільки конфігурація kubelet не активує обмеження пам’яті або резервування пам’яті. Жодні значення memory.high, memory.min або memory.low не записуються до cgroups, якщо ви явно їх не налаштували.
Ви можете вибірково ввімкнути певні поведінки через поля конфігурації kubelet:
memoryThrottlingFactor (наприклад, 0.9), щоб увімкнути обмеження memory.high для контейнерів Burstable і BestEffort. Типове значення null, що означає відсутність обмежень.memoryReservationPolicy на TieredReservation, щоб увімкнути багаторівневий захист пам’яті через memory.min і memory.low. Типове значення None, що означає відсутність резервування пам’яті.memoryThrottlingFactor змінено на nullУ попередніх альфа-релізах memoryThrottlingFactor мав стандартне значення 0.9, що означало, що увімкнення функціональної можливості призводило до того, що kubelet встановлював memory.high для контейнерів. У v1.37 стандартне значення — null, тому kubelet не встановлює memory.high, якщо ви явно не налаштували це значення.
Це зміна була внесена тому, що з стандартним увімкненням функціональної можливості автоматичне встановлення memory.high могло обмежувати робочі навантаження, які раніше працювали без обмежень. Встановлення значення null гарантує, що оновлення до v1.37 не змінює поведінку виконання для наявних кластерів.
Якщо ваш файл конфігурації kubelet уже містить явне значення memoryThrottlingFactor, це значення зберігається під час оновлення, і обмеження продовжує працювати як раніше. Якщо ваш файл конфігурації не містить memoryThrottlingFactor, kubelet використовує нове стандартне значення null і перестає встановлювати memory.high. Щоб зберегти обмеження в цьому випадку, додайте memoryThrottlingFactor явно:
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9
Для повного опису налаштування Memory QoS див. Memory QoS з cgroup v2, Налаштування резервування пам’яті та Системні вимоги
Встановіть memoryThrottlingFactor у значення між 0 і 1. kubelet використовує цей коефіцієнт для обчислення memory.high для контейнерів Burstable і BestEffort. Див. Обмеження пам’яті для того, як обчислюється memory.high для кожного класу QoS.
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9
memoryReservationPolicy: TieredReservation
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryReservationPolicy: TieredReservation
Щоб вимкнути функцію після оновлення, встановіть функціональну можливість у значення false і переконайтеся, що конфігурація kubelet сумісна. kubelet відхиляє конфігурацію, якщо memoryThrottlingFactor встановлено на будь-яке значення, крім колишнього стандартного значення 0.9, або якщо memoryReservationPolicy встановлено на TieredReservation, тому видаліть або відкоригуйте ці поля, якщо ви їх встановили.
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
MemoryQoS: false
Коли функціональна можливість вимкнена або memoryReservationPolicy не встановлено на TieredReservation, kubelet скидає застарілий захист під час запуску на вузлах cgroup v2: memory.min=0 і memory.low=0 у кореневому cgroup kubepods, а memory.low=0 у cgroup Burstable QoS. Для контейнерів застарілі значення memory.high скидаються до max на шляхах узгодження, таких як перезапуск або зміна розміру.
memoryReservationPolicy застосовується до кожного пода на вузлі. З TieredReservation кожен под Guaranteed отримує memory.min, а кожен Burstable под отримує memory.low; немає способу вибірково застосувати політику до окремих подів. Вузол, який змішує робочі навантаження, що потребують жорсткого резервування, з робочими навантаженнями, які повинні залишатися відновлюваними, повинен обрати одну політику для всіх них.
Жорстке резервування також охоплює все, що нараховується на cgroup контейнера, включно з кешем сторінок, тому под, який читає великі файли, може утримувати пам’ять, яку ядро в іншому випадку звільнило б для обслуговування сусідніх подів.
SIG Node відстежує обидва в kubernetes/kubernetes#140246. Якщо це впливає на вас, найкраще місце для опису вашого робочого навантаження — це цей тікет.
Наступним етапом для Memory QoS є перехід у GA. Відгуки користувачів Beta допоможуть визначити будь-які залишкові налаштування перед цим кроком. Якщо ви зіткнетеся з проблемами, будь ласка, повідомляйте про помилки в kubernetes/kubernetes.
Ця функціональна можливість керується SIG Node. Якщо ви зацікавлені у внеску або маєте відгуки, ви можете зв’язатися через: