QoS классы
Тема дорожной карты · Kubernetes
Классы QoS в Kubernetes — автоматически назначаемые уровни качества обслуживания, которые kubelet и OOM killer ядра используют для определения, какие Pod'ы вытеснять первыми при нехватке памяти на узле. Kubernetes назначает один из трёх классов QoS на основе полей resources.requests и resources.limits в спецификациях контейнеров Pod'а: Guaranteed (requests равны limits для всех контейнеров), Burstable (хотя бы один контейнер имеет установленные requests, отличающиеся от limits) и BestEffort (ни requests, ни limits не заданы вообще). Pod'ы Guaranteed вытесняются последними при давлении памяти на узле, поскольку kubelet может точно учесть их потребление ресурсов, тогда как Pod'ы BestEffort завершаются первыми, так как конкурируют за любую оставшуюся ёмкость. Классы QoS напрямую взаимодействуют с планировщиком Kubernetes — только Pod'ы Guaranteed можно безопасно совместно размещать на плотно упакованных узлах без риска OOMKill-каскадов — и с приоритетом и вытеснением Pod'ов для порядка вытеснения на уровне кластера. Установка корректных requests и limits для всех контейнеров — лучшая практика Kubernetes, применяемая политиками OPA Gatekeeper или Kyverno и валидируемая через объекты LimitRange на уровне пространства имён.
Как это работает
QoS классы обрабатывается scheduler Kubernetes — при создании pod scheduler выбирает ноду на основе resource requests, node labels, taints/tolerations, affinity/anti-affinity правил и priority class. Решение single-pass на pod и учитывает текущее состояние кластера; после scheduling pod остаётся на этой ноде до eviction или rescheduling.
Когда применять
Кастомизируйте QoS классы, когда дефолтное scheduling даёт проблемы: нагрузки конкурируют за то же железо (используйте anti-affinity для разнесения), нагрузки требуют конкретное железо (nodeSelector или nodeAffinity для GPU-нод), или важен приоритет (PriorityClass, чтобы critical pods вытесняли background). Без кастомизации kube-scheduler нормально справляется в ~80% случаев.
Типичные ошибки
Scheduling-ловушки: правила affinity настолько жёсткие, что pods не могут schedule никуда (Pending навсегда); resource requests, не отражающие реальное использование (кластер либо over-commit и крашится, либо under-commit и сжигает деньги); игнорирование eviction (pods, выселяемые под нагрузкой ноды, выглядят как случайные крэши). Мониторьте метрики scheduler — pending pods — leading indicator проблем кластера.