Проверьте taints на всех ваших узлах, выполнив:
kubectl describe node <node-name> | grep -i taint
Мастер-узел по умолчанию имеет taint, что предотвращает регулярное планирование Pods на этом конкретный узел. Обратите внимание, что главный узел предназначен исключительно для запуска элементов управления kubernetes компонентов, которые находятся в пространстве имен kube-system. Такое решение обеспечивает стабильность кластера kubernetes и полностью оправдано. Как правило, развертывание любой дополнительной рабочей нагрузки на главном узле 1015 * - плохая идея. Когда речь идет о непроизводственных решениях, таких как Minikube , когда у вас кластер из одного узла, это вполне приемлемо. Возможно, вы захотите ознакомиться с tains и tollerations , чтобы лучше понять эту концепцию.
Помимо добавления tollerations к Pod спецификации, вы можете рассмотреть удаление taints из ваших узлов (описано также здесь ):
Удаление порчи с узла Вы можете использовать kubectl taint для удаления порчи. Вы можете удалить портные с помощью key, key-value или key-effect.
Например, следующая команда удаляет из узла foo все порты с выделенным ключом:
kubectl taint nodes foo dedicated-
Важно: портят не ярлыки! , как могут предположить некоторые комментарии. Они могут быть связаны с метками, но сами по себе они не являются метками.
Вы можете легко проверить это, выполнив:
kubectl get node <tainted-node> -o yaml
, и вы увидите все примененные в настоящее время портки в узле spe c section:
spec:
...
taints:
- effect: NoSchedule
key: key
value: some-value
Обычно на главном узле вы видите следующую порчу:
spec:
taints:
- effect: NoSchedule
key: node-role.kubernetes.io/master
и среди многих других меток есть указанная c, связанная с этой поркой:
node-role.kubernetes.io/master: ""
Ответ на заданный вами c вопрос, который вы разместили в заголовке:
Почему модуль, созданный этим манифестом, может быть развернут на GPU Worker без Указание Nodeselector
Я рекомендую вам прочитать больше о различных механизмах, используемых kubernetes для назначения Pods на Nodes в этой статье и вам ' Вы увидите, что nodeSelector можно использовать, если вы хотите гарантировать, что ваш Pod будет запланирован на узле с указанными c метками. Однако отсутствие nodeSelector не мешает вашему Pods быть запланированным на таком узле. Pods все еще можно запланировать на каждом узле, который не имеет каких-либо вредных воздействий (предотвращая таким образом определенные Pods, у которых нет указанного допуска c, который можно запланировать на нем), или на любых узлах, которые имеют некоторые вредные воздействия, однако запланированный Pod может допустить эти вреды.
В вашем случае рабочий узел является единственным узлом, на котором нет вредных воздействий, предотвращая Pods, которые не допускают этого указания c заражения запланировано на это. Так как рабочий узел не имеет каких-либо вредных воздействий, на нем запланировано Pod.
Если вы хотите запретить любые другие Pod, например, которые не требуют, чтобы GPU планировался на этот параметр c узел, вы можете создать свой собственный вред, и только Pods, который будет иметь заданный допуск c, может быть запланирован на таком узле.
Надеюсь, это очистило ваши сомнения.