# k8s QOS

## [control groups (cgroups)](https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/#memory-qos-with-cgroup-v2)

Memory QoS работает через cgroups v2 — это "менеджеры памяти" в [Linux](/2%20ComputerScience/2.0%20Linux/), которые контролируют, сколько памяти получает каждая группа процессов.

Cgroups — это как разделители в общежитии. Без cgroups:

* Все контейнеры живут в одной комнате;

* Кто первый проснулся — тот и память забрал;

* Можно случайно залезть в чужую память.

[K8s Memory](./4.3.6.6.2%20k8sMemory.md) requests and limits контейнеров в поде используются для установки конкретных интерфейсов `memory.min` и `memory.high` предоставляются контроллером памяти.

![k8s-node-cgroups-hierarchy](https://github.com/eldaroid/pictures/blob/master/iOSWiki/Common/Orchestration/k8s-node-cgroups-hierarchy.png?raw=true)

## QOS Types

Далее Kubernetes на этапе планирования (scheduling) и валидации определяет класс QoS в соответствии с наличием и конфигурацией requests и limits в манифесте:

* Guaranteed: У всех контейнеров `limits.memory == requests.memory` (и они заданы);

* Burstable: Есть хотя бы один контейнер, у которого `requests.memory < limits.memory` (или `limit` не задан);

* BestEffort: Ни у одного контейнера не заданы ни `requests`, ни `limits`.

![k8sQOS](https://github.com/eldaroid/pictures/blob/master/iOSWiki/Common/Orchestration/k8sQOS.png?raw=true)

## Какой QOS выбрать?

Если вы новичок в Kubernetes, для начала лучше всего использовать значения limits точно такие же как и requests - это обеспечит так называемый “гарантированный класс качества сервиса” (`Guaranteed QoS class`, об этих классах чуть ниже). Класс `Guaranteed` обладает **максимальным приоритетом**, и поды данного класса будут остановлены только если они используют больше ресурсов, чем установлено в limits.

С другой стороны, класс `Burstable QoS` потенциально позволяет более эффективно использовать ресурсы инфраструктуры, правда, за счет большей непредсказуемости - например, рост CPU-latency может повлиять на остальные поды/контейнеры, запущенные на том же рабочем узле (ноде). Поды класса `Burstable` обычно имеют некоторое гарантированное количество ресурсов (благодаря requests), но могут использовать больше ресурсов (если такие доступны).

Поды класса `Best-Effort` обладают наименьшим приоритетом. Они могут использовать любое количество свободной памяти, доступное на рабочем узле, но будут остановлены в первую очередь, если система испытывает недостаток памяти (under memory pressure).

Если система испытывает недостаток памяти (и остановка подов с классом `Best-Effort` не помогла), то поды данного класса, которые превысили значение заданное в requests будут остановлены.

----------

[4.3.6.6.4 Vertical Pod Autoscaler Theme](./4.3.6.6.4%20VerticalPodAutoscaler.md) | [Back To iOSWiki Contents](https://github.com/eldaroid/iOSWiki)