k8s: Почему coredns не может работать на главном узле?

Я настраиваю кластер k8s, в котором есть один главный узел и один рабочий узел, coredns pod - это расписание для рабочего узла и отлично работает. Когда я удаляю рабочий узел, модуль coredns по расписанию для основного узла, но имеет состояние CrashLoopBackOff, журнал coredns модуля выглядит следующим образом:

E0118 10:06:02.408608       1 reflector.go:153] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:105: Failed to list *v1.Endpoints: Get https://10.96.0.1:443/api/v1/endpoints?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: connect: no route to host
E0118 10:06:02.408752       1 reflector.go:153] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:105: Failed to list *v1.Namespace: Get https://10.96.0.1:443/api/v1/namespaces?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: connect: no route to host
[INFO] SIGTERM: Shutting down servers then terminating
[INFO] plugin/health: Going into lameduck mode for 5s

Эта статья скажем, компоненты DNS должны работать на обычном узле кластера (а не на мастере Kubernetes):

Помимо основных компонентов Kubernetes, таких как api-server, scheduler, controller-manager, работающих на главной машине, существует ряд надстроек, которые по разным причинам должны запускаться на обычном узле кластера (а не на главном сервере Kubernetes). Некоторые из этих надстроек критически важны для полнофункционального кластера, например Heapster, DNS и UI.

Может ли кто-нибудь объяснить, почему модуль coredns не может работать на главном узле?


kubernetes coredns
person Ren    schedule 18.01.2021    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Идея Kubernetes с нуля заключается в развертывании подов на рабочих узлах. Мастер-узлы - это узлы, которые контролируют рабочие узлы и управляют ими.

При первой настройке кластера Kubernetes на главном узле устанавливается Taint, который автоматически предотвращает планирование любых модулей на этом узле. Вы можете увидеть это, а также при необходимости изменить это поведение. Лучше всего не развертывать рабочие нагрузки приложений на главном сервере.

Прочтите полезную статью: планирование главного узла.

Однако вы можете принудительно развернуть поды / развертывания на главных узлах с помощью nodeSelector. Например, дайте своему главному узлу метку, например, посвященную = master, и установите nodeSelector для вашего модуля, чтобы он искал эту метку.

См. Больше: развертывание на главных узлах.

person Malgorzata    schedule 18.01.2021
comment
@Ren Это ответ на ваш вопрос? - person Wytrzymały Wiktor; 19.01.2021
comment
@ WytrzymałyWiktor Нет, coredns теперь может работать на главном узле, но в состоянии CrashLoopBackOff я хочу знать, почему модуль coredns не может работать на главном узле - person Ren; 20.01.2021
comment
Это нормальное поведение, потому что, если ваш кластер теперь состоит из одного узла, который одновременно является главным узлом вашего модуля, несмотря на ограничения, он будет запланирован там, но только теоретически. На практике модуль не будет развернут и не будет работать на этом узле, как вы можете видеть - вы получили ошибку CrashLoopBackOff. - person Malgorzata; 20.01.2021