Scheduling
Тема дорожной карты · Kubernetes
Планирование в Kubernetes — процесс, в ходе которого kube-scheduler выбирает подходящий рабочий узел для каждого не привязанного Pod'а на основе доступности ресурсов, ограничений и правил политик. Планировщик следует двухфазному процессу: фильтрация, исключающая узлы, не удовлетворяющие жёстким ограничениям — недостаточная ёмкость requests, несоответствующие правила nodeSelector или node affinity, отсутствующие tolerations для taints узлов или нарушенные ограничения topology spread; и оценка, ранжирующая оставшиеся узлы по взвешенным критериям — баланс ресурсов, предпочтения pod affinity и загрузка узла. Пользовательское поведение планирования настраивается через schedulerName для использования альтернативного планировщика, topologySpreadConstraints для равномерного распределения Pod'ов по зонам или узлам с maxSkew или priorityClassName для назначения приоритета при вытеснении. Cluster Autoscaler интегрируется с очередью ожидающих Pod'ов планировщика — когда планировщик не может найти узел из-за недостаточной ёмкости, Cluster Autoscaler провизирует новые узлы и планировщик повторяет попытку размещения. Расширенные сценарии планирования в Kubernetes используют PodDisruptionBudget, inter-pod affinity/anti-affinity с topologyKey: kubernetes.io/hostname и Descheduler для непрерывной перебалансировки кластера после первоначального размещения.
Как это работает
Scheduling обрабатывается scheduler Kubernetes — при создании pod scheduler выбирает ноду на основе resource requests, node labels, taints/tolerations, affinity/anti-affinity правил и priority class. Решение single-pass на pod и учитывает текущее состояние кластера; после scheduling pod остаётся на этой ноде до eviction или rescheduling.
Когда применять
Кастомизируйте Scheduling, когда дефолтное 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 проблем кластера.