Taints и tolerations
Тема дорожной карты · Kubernetes
Taints и Tolerations — взаимодополняющие механизмы планирования Kubernetes: taints применяются к узлам, чтобы отталкивать Pod'ы, явно не допускающие их, а tolerations в спецификации Pod'а позволяют Pod'у быть запланированным на узлах с taint'ами. Taint добавляется командой kubectl taint nodes <node> key=value:effect, где эффект — один из: NoSchedule (новые Pod'ы без соответствующей toleration не будут размещены), PreferNoSchedule (мягкое предпочтение) или NoExecute (существующие Pod'ы без toleration вытесняются). Tolerations объявляются в spec.tolerations с соответствующими полями key, operator (Equal или Exists), value и effect, а опциональный tolerationSeconds для taint'ов NoExecute задерживает вытеснение. Распространённые production-применения taints и tolerations: выделение GPU-узлов с nvidia.com/gpu=present:NoSchedule, изоляция системных компонентов с node-role.kubernetes.io/control-plane:NoSchedule на узлах плоскости управления и пометка неработоспособных узлов для вытеснения через taint node.kubernetes.io/not-ready:NoExecute, применяемый kube-controller-manager. Taints и Tolerations работают совместно с правилами node affinity и ограничениями topology spread, давая операторам Kubernetes точный контроль над размещением нагрузок в гетерогенных топологиях кластера.
Как это работает
Taints и tolerations обрабатывается scheduler Kubernetes — при создании pod scheduler выбирает ноду на основе resource requests, node labels, taints/tolerations, affinity/anti-affinity правил и priority class. Решение single-pass на pod и учитывает текущее состояние кластера; после scheduling pod остаётся на этой ноде до eviction или rescheduling.
Когда применять
Кастомизируйте Taints и tolerations, когда дефолтное 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 проблем кластера.