Pod priority и preemption
Тема дорожной карты · Kubernetes
Приоритет и вытеснение Pod'ов — механизм планирования Kubernetes, назначающий целочисленные значения приоритета Pod'ам и позволяющий планировщику вытеснять Pod'ы с более низким приоритетом с узлов, когда нагрузки с более высоким приоритетом не могут быть запланированы из-за нехватки ресурсов. Приоритет определяется через ресурс PriorityClass — например, system-cluster-critical со значением 2000000000 зарезервирован для критически важных системных компонентов — и назначается Pod'у через spec.priorityClassName. Когда kube-scheduler не может найти узел с достаточным количеством CPU и памяти для размещения высокоприоритетного Pod'а, включается вытеснение: планировщик определяет Pod'ы-жертвы с более низким приоритетом на узле-кандидате, выселяет их с соблюдением terminationGracePeriodSeconds и размещает ожидающий Pod в освобождённом пространстве. Ресурсы PodDisruptionBudget взаимодействуют с вытеснением, ограничивая количество Pod'ов данного Deployment или StatefulSet, одновременно недоступных, защищая критические сервисы во время событий вытеснения. Приоритет и вытеснение Pod'ов необходимы для кластеров со смешанными нагрузками — обеспечивая, что production-Pod'ы с QoS Guaranteed всегда вытесняют пакетные задания или фоновые задачи BestEffort при конкуренции за ресурсы.
Как это работает
Pod priority и preemption обрабатывается scheduler Kubernetes — при создании pod scheduler выбирает ноду на основе resource requests, node labels, taints/tolerations, affinity/anti-affinity правил и priority class. Решение single-pass на pod и учитывает текущее состояние кластера; после scheduling pod остаётся на этой ноде до eviction или rescheduling.
Когда применять
Кастомизируйте Pod priority и preemption, когда дефолтное 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 проблем кластера.