Узел Kubernetes игнорирует создание обычных подов

Вы можете выбрать из nodeSelector или сходство узлов.

nodeSelector предоставляет очень простой способ привязать модули к узлам с определенными метками. Функция сродства / анти-сродства значительно расширяет типы ограничений, которые вы можете выразить. Ключевые улучшения:

1. язык более выразительный (не просто «И или точное совпадение»)
2. вы можете указать, что правило является «мягким» / «предпочтительным», а не жестким требованием, поэтому, если планировщик не может удовлетворить его, модуль все равно будет запланирован
3. вы можете ограничивать метки на других модулях, работающих на узле (или другом топологическом домене), а не метки на самом узле, что позволяет правила о том, какие модули могут и не могут быть совмещены

Функция аффинности состоит из двух типов аффинности: «аффинности узла» и «аффинности / антиаффинности между стручками». Сходство узла похоже на существующее nodeSelector (но с первыми двумя преимуществами, перечисленными выше), в то время как сродство / анти-сродство между модулями ограничивает метки модулей, а не метки узлов, как описано в третьем пункте, перечисленном выше, в дополнение к наличию первого и второго свойств, перечисленных выше

Коротко node affinity похоже на nodeSelector но это позволяет вам ограничить, какие узлы могут быть запланированы для вашего модуля, на основе меток на узле.

Вы также можете посмотреть порчи и терпимость

Вы добавляете помутнение к узлу, используя kubectl taint. Например,

kubectl taint nodes node1 key=value:NoSchedule

помещает пятно на узел node1. У заразы есть ключ key, стоимость value, и эффект загрязнения NoSchedule. Это означает, что ни один модуль не сможет запланировать node1 если у него нет подходящего допуска.

Нет смысла цитировать или переписывать документы в ответе. Я действительно рекомендую вам пройтись по ним и выбрать тот, который лучше соответствует вашему примеру.