Kubeadm: coredns CrashLoopBackOff devido a dnsmasq

forneça logs dos pods CoreDNS.

o google revela vários relatórios de que isso é problemático no Ubuntu:
nameserver 127.0.1.1
leia isto: https://askubuntu.com/questions/627899/nameserver-127-0-1-1-in-resolv-conf-wont-go-away

em 1.12.x você também pode tentar --feature-gates=CoreDNS=false para habilitar o kube-dns.
apenas para fins de teste.

@ aravind-murthy Por acaso você executa o NetworkManager ou o dnsmasq em sua máquina?
systemd -olved usa 'nameserver 127.0.0.53' no /etc/resolv.conf e salva o resolv.conf original em /run/systemd/resolve/resolv.conf. Você não o tem, então parece que o systemd-Resolvido não está habilitado.

@ aravind-murthy Por acaso você executa o NetworkManager ou o dnsmasq em sua máquina?
systemd -olved usa 'nameserver 127.0.0.53' no /etc/resolv.conf e salva o resolv.conf original em /run/systemd/resolve/resolv.conf. Você não o tem, então parece que o systemd-Resolvido não está habilitado.

Olá @ bart0sh - por favor,

@ aravind-murthy Verifique se você tem /etc/NetworkManager/NetworkManager.conf e o que é mencionado lá como dns, por exemplo, dns = dnsmasq. Você também pode verificar se o processo dnsmasq está na saída 'ps aux' ou / e seu status de serviço: 'sudo systemctl status dnsmasq'

forneça logs dos pods CoreDNS.

o google revela vários relatórios de que isso é problemático no Ubuntu:
nameserver 127.0.1.1
leia isto: https://askubuntu.com/questions/627899/nameserver-127-0-1-1-in-resolv-conf-wont-go-away

em 1.12.x você também pode tentar --feature-gates=CoreDNS=false para habilitar o kube-dns.
apenas para fins de teste.

root@k8s-master:~# kubectl get pods --all-namespaces
NAMESPACE     NAME                                 READY   STATUS             RESTARTS   AGE
kube-system   coredns-576cbf47c7-dkhx5             0/1     CrashLoopBackOff   1          9m9s
kube-system   coredns-576cbf47c7-qlnqn             0/1     CrashLoopBackOff   1          9m9s
kube-system   etcd-k8s-master                      1/1     Running            0          18s
kube-system   kube-apiserver-k8s-master            1/1     Running            0          18s
kube-system   kube-controller-manager-k8s-master   1/1     Running            0          18s
kube-system   kube-flannel-ds-amd64-nr8lx          1/1     Running            0          32s
kube-system   kube-proxy-8s48m                     1/1     Running            0          9m9s
kube-system   kube-scheduler-k8s-master            1/1     Running            0          18s
root@k8s-master:~# kubectl describe pod coredns-576cbf47c7-dkhx5
Error from server (NotFound): pods "coredns-576cbf47c7-dkhx5" not found

forneça logs dos pods CoreDNS.

o google revela vários relatórios de que isso é problemático no Ubuntu:
nameserver 127.0.1.1
leia isto: https://askubuntu.com/questions/627899/nameserver-127-0-1-1-in-resolv-conf-wont-go-away

em 1.12.x você também pode tentar --feature-gates=CoreDNS=false para habilitar o kube-dns.
apenas para fins de teste.

root@k8s-master:~# kubectl get pods --all-namespaces
NAMESPACE     NAME                                 READY   STATUS             RESTARTS   AGE
kube-system   coredns-576cbf47c7-dkhx5             0/1     CrashLoopBackOff   4          11m
kube-system   coredns-576cbf47c7-qlnqn             0/1     CrashLoopBackOff   4          11m
kube-system   etcd-k8s-master                      1/1     Running            0          2m14s
kube-system   kube-apiserver-k8s-master            1/1     Running            0          2m14s
kube-system   kube-controller-manager-k8s-master   1/1     Running            0          2m14s
kube-system   kube-flannel-ds-amd64-nr8lx          1/1     Running            0          2m28s
kube-system   kube-proxy-8s48m                     1/1     Running            0          11m
kube-system   kube-scheduler-k8s-master            1/1     Running            0          2m14s
root@k8s-master:~# kubectl logs coredns-576cbf47c7-dkhx5
Error from server (NotFound): pods "coredns-576cbf47c7-dkhx5" not found
root@k8s-master:~# kubectl logs coredns-576cbf47c7-dkhx5 --previous
Error from server (NotFound): pods "coredns-576cbf47c7-dkhx5" not found

@ aravind-murthy Verifique se você tem /etc/NetworkManager/NetworkManager.conf e o que é mencionado lá como dns, por exemplo, dns = dnsmasq. Você também pode verificar se o processo dnsmasq está na saída 'ps aux' ou / e seu status de serviço: 'sudo systemctl status dnsmasq'

root@k8s-master:~# cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile,ofono
dns=dnsmasq

[ifupdown]
managed=false
root@k8s-master:~# systemctl status dnsmasq
● dnsmasq.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
root@k8s-master:~#

root@k8s-master:~# kubectl describe pod coredns-576cbf47c7-dkhx5
Error from server (NotFound): pods "coredns-576cbf47c7-dkhx5" not found

^ você precisa adicionar -n kube-system para especificar o namespace também.

root@k8s-master:~# kubectl describe pod coredns-576cbf47c7-dkhx5
Error from server (NotFound): pods "coredns-576cbf47c7-dkhx5" not found

^ você precisa adicionar -n kube-system para especificar o namespace também.

root@k8s-master:~# kubectl describe pod coredns-576cbf47c7-dkhx5 -n kube-system

<output snipped>

Events:
  Type     Reason            Age                     From                 Message
  ----     ------            ----                    ----                 -------
  Warning  FailedScheduling  11m (x34 over 16m)      default-scheduler    0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.
  Normal   Started           6m46s (x4 over 7m33s)   kubelet, k8s-master  Started container
  Normal   Pulled            6m5s (x5 over 7m33s)    kubelet, k8s-master  Container image "k8s.gcr.io/coredns:1.2.2" already present on machine
  Normal   Created           6m5s (x5 over 7m33s)    kubelet, k8s-master  Created container
  Warning  BackOff           2m20s (x30 over 7m31s)  kubelet, k8s-master  Back-off restarting failed container

assim que o contêiner entrar em CrashLoopBackOff você também pode chamar docker ps para ver os contêineres em execução e, em seguida, docker logs [coredns-container-id] para ver os logs do próprio contêiner.

@aravind-murthy isso é interessante. O serviço está habilitado no gerenciador de rede, mas não está funcionando. Por favor, comente a linha 'dns = dnsmasq' na configuração e reinicie o gerenciador de rede: sudo systemctl restart network-manager

Em seguida, restaure os servidores de nomes originais em /etc/resolv.conf (eles provavelmente estão comentados lá). Isso deve ajudar os pods core-dns quando eles são reiniciados pelo kubelet.

Consegui reproduzir isso em minha máquina com o kubeadm 1.12.3:

Warning  FailedScheduling  7s (x21 over 3m19s)  default-scheduler  0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.

assim que o contêiner entrar em CrashLoopBackOff você também pode chamar docker ps para ver os contêineres em execução e, em seguida, docker logs [coredns-container-id] para ver os logs do próprio contêiner.

root@k8s-master:~# docker logs k8s_coredns_coredns-576cbf47c7-l6rkc_kube-system_59d21f34-f712-11e8-a662-001c423e384e_4
.:53
2018/12/03 15:47:02 [INFO] CoreDNS-1.2.2
2018/12/03 15:47:02 [INFO] linux/amd64, go1.11, eb51e8b
CoreDNS-1.2.2
linux/amd64, go1.11, eb51e8b
2018/12/03 15:47:02 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769
2018/12/03 15:47:02 [FATAL] plugin/loop: Seen "HINFO IN 2526125915973168889.7333277912286930769." more than twice, loop detected

Vejo:
https://github.com/coredns/coredns/issues/2087#issuecomment -432387727
https://github.com/coredns/coredns/blob/master/plugin/loop/README.md

Em seguida, restaure os servidores de nomes originais em /etc/resolv.conf (eles provavelmente estão comentados lá)

Eu não comentei nada neste arquivo (/etc/resolv.conf). Atualmente, possui as seguintes entradas:

Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.211.55.1
nameserver 127.0.1.1
search localdomain

@aravind-murthy você pode comentar a linha com o endereço dnsmasq: nameserver 127.0.1.1
então você pode excluir pods core-dns. eles serão reiniciados pelo kubelet e, com sorte, funcionarão

@ neolit123 meu caso é diferente. pods core-dns estão em estado pendente, os registros estão vazios

@aravind-murthy você pode comentar a linha com o endereço dnsmasq: nameserver 127.0.1.1
então você pode excluir pods core-dns. eles serão reiniciados pelo kubelet e, com sorte, funcionarão

cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.211.55.1
#nameserver 127.0.1.1
search localdomain

root@k8s-master:~# kubectl -n kube-system delete pod -l k8s-app=kube-dns
pod "coredns-576cbf47c7-l6rkc" deleted
pod "coredns-576cbf47c7-mhd4d" deleted

root@k8s-master:~# kubectl get pods --all-namespaces
NAMESPACE     NAME                                 READY   STATUS             RESTARTS   AGE
kube-system   coredns-576cbf47c7-2zjm4             0/1     Error              1          20s
kube-system   coredns-576cbf47c7-854dn             0/1     CrashLoopBackOff   1          20s
kube-system   etcd-k8s-master                      1/1     Running            0          13m
kube-system   kube-apiserver-k8s-master            1/1     Running            0          13m
kube-system   kube-controller-manager-k8s-master   1/1     Running            0          13m
kube-system   kube-flannel-ds-amd64-96724          1/1     Running            0          13m
kube-system   kube-proxy-4gq5w                     1/1     Running            0          14m
kube-system   kube-scheduler-k8s-master            1/1     Running            0          13m



md5-71924b6af31e6c3d5900914e6a6e2956



root@k8s-master:~# docker logs k8s_coredns_coredns-576cbf47c7-2zjm4_kube-system_4a9a1492-f714-11e8-a662-001c423e384e_5
.:53
2018/12/03 16:02:16 [INFO] CoreDNS-1.2.2
2018/12/03 16:02:16 [INFO] linux/amd64, go1.11, eb51e8b
CoreDNS-1.2.2
linux/amd64, go1.11, eb51e8b
2018/12/03 16:02:16 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769
2018/12/03 16:02:22 [FATAL] plugin/loop: Seen "HINFO IN 4180232279452050349.8122308360122098305." more than twice, loop detected

Vejo:
coredns / coredns # 2087 (comentário)

Sim, isso funciona conforme observei na seção "Tudo o que precisamos saber", mas parece uma solução hacky.

root@k8s-master:~# kubectl -n kube-system edit configmap coredns
<add a comment in the line containing 'loop' here, and save the file.
configmap/coredns edited
root@k8s-master:~#

root@k8s-master:~# kubectl -n kube-system delete pod -l k8s-app=kube-dns
pod "coredns-576cbf47c7-2zjm4" deleted
pod "coredns-576cbf47c7-854dn" deleted
root@k8s-master:~# kubectl get pods --all-namespaces
NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE
kube-system   coredns-576cbf47c7-7ls7n             1/1     Running   0          14s
kube-system   coredns-576cbf47c7-lvbnq             1/1     Running   0          14s
kube-system   etcd-k8s-master                      1/1     Running   0          20m
kube-system   kube-apiserver-k8s-master            1/1     Running   0          20m
kube-system   kube-controller-manager-k8s-master   1/1     Running   0          20m
kube-system   kube-flannel-ds-amd64-96724          1/1     Running   0          20m
kube-system   kube-proxy-4gq5w                     1/1     Running   0          21m
kube-system   kube-scheduler-k8s-master            1/1     Running   0          20m
root@k8s-master:~#

Sim, isso funciona conforme observei na seção "Tudo o que precisamos saber", mas parece uma solução hacky.

você também pode tentar o kube-dns, mas me parece que o Ubuntu está fazendo as coisas erradas.

https://kubernetes.io/docs/setup/independent/trou troubleshooting-kubeadm/#coredns -pods-have-crashloopbackoff-or-error-state solução não funciona BTW.

solução crashloopbackoff-or-error-state não funciona BTW.

infelizmente, pode haver mais de um motivo para o estado CrashLoopBackoff de um pod.

@ aravind-murthy Você consegue ver se a linha 'nameserver 127.0.1.1' ainda está comentada em seu /etc/resolv.conf? Pode ser reescrito e isso pode causar loop dns e travar o core-dns

@chrisohaver qual é a maneira oficial de resolver os problemas de loop que estão presentes no estoque Ubuntu 16.04 que devemos incluir em nosso guia de TS?

@ aravind-murthy em suas instruções de configuração, você mencionou que fez o seguinte:

1. Inicializar pod de kubernetes
   kubeadm init --pod-network-cidr = 10.244.0.0 / 16
2. Instale Flanel
   https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#pod -network & role para baixo até a seção "Instalando um complemento de rede pod" e selecione a guia "Flanela"

Antes de instalar a flanela por meio de kubectl apply -f https://... , você definiu /proc/sys/net/bridge/bridge-nf-call-iptables como 1 executando sysctl net.bridge.bridge-nf-call-iptables=1 ?

@ neolit123 , IMO, a melhor maneira de corrigir o problema de loop de auto-encaminhamento de DNS é consertar o problema de implantação subjacente no kubelet: o kubelet está enviando servidores upstream inválidos para pods com dnsPolicy = "default". Na verdade, faça o kubelet usar uma cópia de resolv.conf que contém os upstreams reais (onde quer que esteja em estoque Ubuntu 16.04). Isso resolveria o problema de todos os pods dnsPolicy = "default", não apenas do CoreDNS.

A parte complicada é localizar onde o resolv.conf "real" existe em seus sistemas. Parece que o Ubuntu mudou isso de uma versão para outra. Portanto, as etapas seriam, para cada nó:

1. encontre o caminho para resolv.conf que lista apenas os endereços IP reais de seus servidores upstream, sem endereços de loopback.
2. configure o kubelet para usar este caminho em vez do /etc/resolv.conf padrão.

Uma opção nuclear seria criar manualmente um resolv.conf em cada nó que contém os servidores upstream que você deseja que o k8s use e apontar cada kubelet para eles.

muito obrigado pelos detalhes @chrisohaver !

precisamos adicionar essas informações ao guia de solução de problemas.
este é um problema distro / resolv.conf e não um problema kubeadm, mas nossos usuários o enfrentam.

página para atualizar:
https://kubernetes.io/docs/setup/independent/trou troubleshooting-kubeadm/#coredns -pods-have-crashloopbackoff-or-error-state

Antes de instalar a flanela por meio de kubectl apply -f https://... , você definiu /proc/sys/net/bridge/bridge-nf-call-iptables como 1 executando sysctl net.bridge.bridge-nf-call-iptables=1 ?

Eu não fiz, obrigado por apontar isso. Vou tentar novamente em uma VM limpa mais uma vez e avisar em breve.

@ neolit123 neste caso particular, precisamos descobrir como desabilitar o dnsmasq completamente. Parece que desabilitá-lo no gerenciador de rede não é suficiente e o cliente dhcp ou outro software coloca 'nameserver 127.0.1.1' de volta nele, o que dispara a detecção de loop no core-dns.

@ neolit123 neste caso particular, precisamos descobrir como desabilitar o dnsmasq completamente

estou percebendo que automatizamos o que é passado para o kubelet dependendo do systemd resolvido e isso é problemático. mas instruir o usuário a escrever um resolv.conf personalizado ainda é uma opção, eu acho.

Parece que desabilitá-lo no gerenciador de rede não é suficiente e o cliente dhcp ou outro software coloca 'nameserver 127.0.1.1' de volta nele, o que dispara a detecção de loop no core-dns.

se usarmos o resolv.conf padrão, precisamos desabilitar a adição automática desses servidores de nomes de loopback.

então as etapas são:
1) comentar dns=dnsmasq na configuração do gerenciador de rede
2) este post contém algumas informações sobre o que deve ser feito a seguir:
https://askubuntu.com/a/716813
mas, para mim, parece que a solução resolv.conf personalizada é mais fácil de formular no guia TS.

Propus um PR que generaliza os documentos de solução de problemas de loop no leia-me do plug-in de loop coredns, de forma que se aplique mais claramente a qualquer tipo de servidor de cache DNS local, não apenas resolvido pelo systemd. coredns / coredns # 2363

@ aravind-murthy, você tentou novamente?

@ aravind-murthy, você tentou novamente?

@ alejandrox1 Ainda não, por favor, me dê algum tempo, eu preciso do cluster k8s instalado e funcionando para testar o plugin jenkins-k8s-kubectl (prova de conceito não relacionada a este problema). Eu informarei quando puder.

parece que já temos uma entrada para isso no guia TS aqui:
https://kubernetes.io/docs/setup/independent/trou troubleshooting-kubeadm/#coredns -pods-have-crashloopbackoff-or-error-state

@aravind-murthy sinta-se à vontade para relatar suas descobertas, ainda.

Olá @ alejandrox1 , @ neolit123 - não sei se é a combinação do novo kubernetes v1.13 (quando aumentei este tíquete, usei a v1.12 porque era a versão disponível na época) ou se eu estava seguindo as instruções (corretamente este tempo), mas, no Ubuntu 16.04.05, instalando o kubernetes v1.13 mais recente, seguindo https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#tabs -pod-install-4 (ou seja, flanela ) e, em seguida, definindo net.bridge.bridge-nf-call-iptables como 1, usando o comando
sysctl net.bridge.bridge-nf-call-iptables=1 e reinicie a máquina / VM, para permitir que a configuração do sysctl 'tome posse' e, em seguida, instale o Flannel ......

Não há mais erros de crashloopback para coredns !!!

:-) :-)

Muito obrigado

@aravind-murthy isso é interessante. O serviço está habilitado no gerenciador de rede, mas não está funcionando. Por favor, comente a linha 'dns = dnsmasq' na configuração e reinicie o gerenciador de rede: sudo systemctl restart network-manager

Em seguida, restaure os servidores de nomes originais em /etc/resolv.conf (eles provavelmente estão comentados lá). Isso deve ajudar os pods core-dns quando eles são reiniciados pelo kubelet.

desabilitar dnsmasq para o gerente de rede e comentar dnsmasq nameservers resolveu o problema para mim!

Eu tive esse mesmo problema depois de excluir o loop.

alguém poderia me ajudar com isso?

logs de kubectl coredns-fb8b8dccf-j6mjl -n kube-system
Erro do servidor (BadRequest): o contêiner "coredns" no pod "coredns-fb8b8dccf-j6mjl" está esperando para iniciar: ContainerCreating
master @ master : ~ $ sudo kubectl get pods --all-namespacesNAMESPACE NOME PRONTO STATUS RESTARTS IDADE
kube-system coredns-fb8b8dccf-j6mjl 0/1 ContainerCreating 0 7m31s
kube-system coredns-fb8b8dccf-lst4v 0/1 ContainerCreating 0 7m31s
kube-system etcd-master.testcluster.com 1/1 Executando 0 25m
kube-system kube-apiserver-master.testcluster.com 1/1 Executando

@ Ramane19 , seus pods estão presos em "ContainerCreating", o que é um problema diferente.

Antes de mostrar pendente, depois de deletar o loop ele mostrava criando container?

Existe alguma outra maneira de resolver esse problema?

@ Ramane19 , Você leu https://github.com/coredns/coredns/tree/master/plugin/loop#trou troubleshooting

Sim, ele fala sobre o problema de loop, não sobre a criação dos contêineres

@ Ramane19 , Você leu https://github.com/coredns/coredns/tree/master/plugin/loop#trou troubleshooting

OK, então parece não estar relacionado a este problema - ou seja, fora do tópico.

Em seguida, restaure os servidores de nomes originais em /etc/resolv.conf (eles provavelmente estão comentados lá)

Eu não comentei nada neste arquivo (/etc/resolv.conf). Atualmente, possui as seguintes entradas:

Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.211.55.1
nameserver 127.0.1.1
search localdomain

Isso funcionou para mim