nodeSelector и nodeAffinity
Тема дорожной карты · Kubernetes
Селекторы узлов и Affinity — механизмы планирования Kubernetes, ограничивающие, на какие узлы может быть помещён Pod; обеспечивают привязку нагрузок к оборудованию для GPU-узлов, SSD, конкретных зон доступности или выделенных пулов узлов. Простейшая форма — spec.nodeSelector: словарь пар ключ-значение меток, используемых планировщиком для фильтрации узлов-кандидатов, например disktype: ssd или kubernetes.io/arch: arm64. Node Affinity расширяет nodeSelector правилами requiredDuringSchedulingIgnoredDuringExecution (жёсткое ограничение) и preferredDuringSchedulingIgnoredDuringExecution (мягкое предпочтение) с операторами matchExpressions: In, NotIn, Exists и Gt. Pod Affinity и Pod Anti-Affinity используют тот же синтаксис, но сопоставляют метки других Pod'ов, а не узлов, обеспечивая совместное размещение связанных сервисов или распределение реплик одного Deployment по доменам отказа с помощью topologyKey: kubernetes.io/hostname или topology.kubernetes.io/zone. Правила Node Selectors и Affinity работают совместно с taints и tolerations — если affinity притягивает Pod'ы к узлам, то taints и tolerations отталкивают нежелательные Pod'ы, — давая операторам Kubernetes полный контроль над топологией планирования.
Как это работает
nodeSelector и nodeAffinity обрабатывается scheduler Kubernetes — при создании pod scheduler выбирает ноду на основе resource requests, node labels, taints/tolerations, affinity/anti-affinity правил и priority class. Решение single-pass на pod и учитывает текущее состояние кластера; после scheduling pod остаётся на этой ноде до eviction или rescheduling.
Когда применять
Кастомизируйте nodeSelector и nodeAffinity, когда дефолтное 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 проблем кластера.