💻 QoS-классы в Kubernetes: как определяется приоритет подов
Каждый под в кластере получает класс качества обслуживания — QoS class.
kubelet вычисляет его сам, исходя из того, как в поде описаны requests и limits.
QoS-класс влияет на приоритет вытеснения подов при нехватке памяти на ноде.
👑 Guaranteed
Самый высокий приоритет.
— У каждого контейнера в поде заданы requests и limits для CPU и памяти
— Для каждого ресурса requests равны limits
— Правило распространяется и на init-контейнеры
resources:
requests:
cpu: "1"
memory: "1Gi"
limits:
cpu: "1"
memory: "1Gi"
Такие поды вытесняются последними и получают oom_score_adj: -997 — ядро убивает их процессы в самую последнюю очередь.
Подходит для БД, брокеров очередей и всего, что нельзя терять при скачке нагрузки на соседей.
🥈 Burstable
Промежуточный класс.
Хотя бы у одного контейнера должен быть задан request или limit по CPU или памяти, но до критериев Guaranteed под не дотягивает.
resources:
requests:
cpu: "200m"
memory: "256Mi"
limits:
memory: "1Gi"
Под может забирать ресурсы сверх requests, пока они свободны на ноде. Но при нехватке памяти он попадает под вытеснение раньше Guaranteed. Внутри класса порядок тоже не случайный: первыми уходят поды, которые потребляют больше, чем запросили.
Самый частый класс в реальных кластерах и разумный выбор по умолчанию для stateless-приложений.
🎭 BestEffort
Ни у одного контейнера в поде не указано ни одного request или limit.
# resources не задан вовсе
Такой под планируется куда угодно и потребляет всё, до чего дотянется. При нехватке памяти на ноде он уходит первым, а его oom_score_adj равен 1000 — максимальный приоритет для OOM Killer.
Годится для разовых задач, где потеря пода ничего не стоит, и категорически не годится для продакшн-сервисов.
➡️ Важные нюансы
— QoS-класс вычисляется один раз при создании пода и меняется только вместе с пересозданием
— Классы влияют на вытеснение по памяти; CPU при превышении лимита не убивает под, а троттлит его
— Guaranteed не защищает от аппаратного сбоя ноды и от вытеснения по нехватке места на диске
— Один контейнер без resources внутри многоконтейнерного пода опускает весь под до Burstable
#заметкиИнженера
Каждый под в кластере получает класс качества обслуживания — QoS class.
kubelet вычисляет его сам, исходя из того, как в поде описаны requests и limits.
QoS-класс влияет на приоритет вытеснения подов при нехватке памяти на ноде.
👑 Guaranteed
Самый высокий приоритет.
— У каждого контейнера в поде заданы requests и limits для CPU и памяти
— Для каждого ресурса requests равны limits
— Правило распространяется и на init-контейнеры
resources:
requests:
cpu: "1"
memory: "1Gi"
limits:
cpu: "1"
memory: "1Gi"
Такие поды вытесняются последними и получают oom_score_adj: -997 — ядро убивает их процессы в самую последнюю очередь.
Подходит для БД, брокеров очередей и всего, что нельзя терять при скачке нагрузки на соседей.
🥈 Burstable
Промежуточный класс.
Хотя бы у одного контейнера должен быть задан request или limit по CPU или памяти, но до критериев Guaranteed под не дотягивает.
resources:
requests:
cpu: "200m"
memory: "256Mi"
limits:
memory: "1Gi"
Под может забирать ресурсы сверх requests, пока они свободны на ноде. Но при нехватке памяти он попадает под вытеснение раньше Guaranteed. Внутри класса порядок тоже не случайный: первыми уходят поды, которые потребляют больше, чем запросили.
Самый частый класс в реальных кластерах и разумный выбор по умолчанию для stateless-приложений.
🎭 BestEffort
Ни у одного контейнера в поде не указано ни одного request или limit.
# resources не задан вовсе
Такой под планируется куда угодно и потребляет всё, до чего дотянется. При нехватке памяти на ноде он уходит первым, а его oom_score_adj равен 1000 — максимальный приоритет для OOM Killer.
Годится для разовых задач, где потеря пода ничего не стоит, и категорически не годится для продакшн-сервисов.
➡️ Важные нюансы
— QoS-класс вычисляется один раз при создании пода и меняется только вместе с пересозданием
— Классы влияют на вытеснение по памяти; CPU при превышении лимита не убивает под, а троттлит его
— Guaranteed не защищает от аппаратного сбоя ноды и от вытеснения по нехватке места на диске
— Один контейнер без resources внутри многоконтейнерного пода опускает весь под до Burstable
#заметкиИнженера