Kubeadm: coredns CrashLoopBackOff debido a dnsmasq

proporcione los registros de los pods de CoreDNS.

Google revela numerosos informes de que esto es problemático en Ubuntu:
nameserver 127.0.1.1
lea esto: https://askubuntu.com/questions/627899/nameserver-127-0-1-1-in-resolv-conf-wont-go-away

en 1.12.x también puede probar --feature-gates=CoreDNS=false para habilitar kube-dns.
solo por probar.

@ aravind-murthy ¿Ejecuta NetworkManager o dnsmasq en su máquina?
systemd-resuelto usa 'nameserver 127.0.0.53' en /etc/resolv.conf y guarda el resolv.conf original en /run/systemd/resolve/resolv.conf. No lo tiene, por lo que parece que systemd-resuelto no está habilitado.

@ aravind-murthy ¿Ejecuta NetworkManager o dnsmasq en su máquina?
systemd-resuelto usa 'nameserver 127.0.0.53' en /etc/resolv.conf y guarda el resolv.conf original en /run/systemd/resolve/resolv.conf. No lo tiene, por lo que parece que systemd-resuelto no está habilitado.

Hola @ bart0sh , por favor avise ¿cómo puedo verificar si hay NM y dnsmasq? Esta es una máquina virtual nueva, por lo que no he configurado nada explícitamente (que yo sepa) a menos que ya esté habilitado de forma predeterminada en el sistema operativo. Sin embargo, puedo verificar e informar.

@ aravind-murthy Compruebe si tiene /etc/NetworkManager/NetworkManager.conf y lo que se menciona allí como dns, por ejemplo, dns = dnsmasq. También puede verificar si el proceso dnsmasq está en la salida 'ps aux' o / y su estado de servicio: 'sudo systemctl status dnsmasq'

proporcione los registros de los pods de CoreDNS.

Google revela numerosos informes de que esto es problemático en Ubuntu:
nameserver 127.0.1.1
lea esto: https://askubuntu.com/questions/627899/nameserver-127-0-1-1-in-resolv-conf-wont-go-away

en 1.12.x también puede probar --feature-gates=CoreDNS=false para habilitar kube-dns.
solo por probar.

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

proporcione los registros de los pods de CoreDNS.

Google revela numerosos informes de que esto es problemático en Ubuntu:
nameserver 127.0.1.1
lea esto: https://askubuntu.com/questions/627899/nameserver-127-0-1-1-in-resolv-conf-wont-go-away

en 1.12.x también puede probar --feature-gates=CoreDNS=false para habilitar kube-dns.
solo por probar.

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 Compruebe si tiene /etc/NetworkManager/NetworkManager.conf y lo que se menciona allí como dns, por ejemplo, dns = dnsmasq. También puede verificar si el proceso dnsmasq está en la salida 'ps aux' o / y su estado de servicio: '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

^ debe agregar -n kube-system para especificar el espacio de nombres también.

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

^ debe agregar -n kube-system para especificar el espacio de nombres también.

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

una vez que el contenedor ingresa CrashLoopBackOff , también puede llamar a docker ps para ver los contenedores en ejecución y luego docker logs [coredns-container-id] para ver los registros del contenedor mismo.

@ aravind-murthy eso es interesante. El servicio está habilitado en el administrador de red, pero no se está ejecutando. Por favor, comente la línea 'dns = dnsmasq' en la configuración y reinicie el administrador de red: sudo systemctl restart network-manager

Luego restaure los servidores de nombres originales en /etc/resolv.conf (probablemente estén comentados). Eso debería ayudar a los pods core-dns cuando kubelet los reinicia.

Pude reproducir esto en mi máquina con 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.

una vez que el contenedor ingresa CrashLoopBackOff , también puede llamar a docker ps para ver los contenedores en ejecución y luego docker logs [coredns-container-id] para ver los registros del contenedor mismo.

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

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

Luego restaure los servidores de nombres originales en /etc/resolv.conf (probablemente estén comentados)

No he comentado nada en este archivo (/etc/resolv.conf). Actualmente tiene las siguientes 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 puede comentar la línea con la dirección dnsmasq: nameserver 127.0.1.1
luego puede eliminar los pods core-dns. serán reiniciados por kubelet y con suerte funcionarán

@ neolit123 mi caso es diferente. Los pods de core-dns están en estado pendiente, los registros están vacíos

@ aravind-murthy puede comentar la línea con la dirección dnsmasq: nameserver 127.0.1.1
luego puede eliminar los pods core-dns. serán reiniciados por kubelet y con suerte funcionarán

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

ver:
coredns / coredns # 2087 (comentario)

Sí, esto funciona como señalé en la sección "Cualquier otra cosa que necesitemos saber", pero parece que es una solución 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:~#

Sí, esto funciona como señalé en la sección "Cualquier otra cosa que necesitemos saber", pero parece que es una solución hacky.

también puedes probar kube-dns, pero me parece que Ubuntu está haciendo las cosas mal.

La solución

La solución crashloopbackoff-or-error-state no funciona por cierto.

Lamentablemente, puede haber más de una razón para el estado CrashLoopBackoff vainas.

@ aravind-murthy ¿Puedes ver si la línea 'nameserver 127.0.1.1' todavía está comentada en tu /etc/resolv.conf? Podría reescribirse y eso puede causar el bucle dns y el bloqueo de core-dns

@chrisohaver ¿cuál es la forma oficial de resolver los problemas de bucle que están presentes en el stock Ubuntu 16.04 que deberíamos incluir en nuestra guía de TS?

@ aravind-murthy en sus instrucciones de configuración mencionó que hizo lo siguiente:

1. Inicializar pod de Kubernetes
   kubeadm init --pod-network-cidr = 10.244.0.0 / 16
2. Instalar Flanel
   https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#pod -network y desplácese hacia abajo hasta la sección "Instalación de un complemento de red de pod" y seleccione la pestaña "Flannel"

Antes de instalar la franela a través de kubectl apply -f https://... , ¿configuró /proc/sys/net/bridge/bridge-nf-call-iptables en 1 ejecutando sysctl net.bridge.bridge-nf-call-iptables=1 ?

@ neolit123 , en resolv.conf que contiene las corrientes ascendentes reales (donde sea que esté en un Ubuntu 16.04 estándar). Esto solucionaría el problema para todos los pods dnsPolicy = "default", no solo para CoreDNS.

El truco es localizar dónde existe el resolv.conf "real" en sus sistemas. Parece que Ubuntu ha movido esto de una versión a otra. Entonces los pasos serían, para cada nodo:

1. busque la ruta al resolv.conf que enumera solo las direcciones IP reales de sus servidores ascendentes, no direcciones de bucle invertido.
2. configure kubelet para usar esta ruta en lugar de la predeterminada /etc/resolv.conf .

Una opción nuclear sería crear manualmente un resolv.conf en cada nodo que contenga los servidores ascendentes que desea que use k8s, y apuntar cada kubelet a esos.

muchas gracias por los detalles @chrisohaver !

necesitamos agregar esta información a la guía de solución de problemas.
este es un problema de distro / resolv.conf y no un problema de kubeadm, pero nuestros usuarios lo enfrentan.

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

Antes de instalar la franela a través de kubectl apply -f https://... , ¿configuró /proc/sys/net/bridge/bridge-nf-call-iptables en 1 ejecutando sysctl net.bridge.bridge-nf-call-iptables=1 ?

No lo hice, gracias por señalarlo. Volveré a intentarlo con una máquina virtual limpia y lo asesoraré en breve.

@ neolit123 en este caso particular, necesitamos descubrir cómo deshabilitar dnsmasq por completo. Parece que deshabilitarlo en el administrador de red no es suficiente y el cliente dhcp u otra pieza de software devuelve el 'servidor de nombres 127.0.1.1', lo que activa la detección de bucles en core-dns.

@ neolit123 en este caso particular, necesitamos descubrir cómo deshabilitar dnsmasq por completo

Me estoy dando cuenta de que automatizamos lo que se pasa al kubelet dependiendo de systemd-resuelto y eso es problemático. pero dar instrucciones al usuario para que escriba un resolv.conf personalizado sigue siendo una opción también, supongo.

Parece que deshabilitarlo en el administrador de red no es suficiente y el cliente dhcp u otra pieza de software devuelve el 'servidor de nombres 127.0.1.1', lo que activa la detección de bucles en core-dns.

si usamos el resolv.conf predeterminado, necesitamos deshabilitar la adición automática de estos servidores de nombres de bucle invertido.

entonces los pasos son:
1) comentar dns=dnsmasq en la configuración del administrador de red
2) esta publicación tiene información de lo que se debe hacer a continuación:
https://askubuntu.com/a/716813
pero a mí me parece que la solución resolv.conf personalizada es más fácil de formular en la guía TS.

He propuesto un PR que generaliza los documentos de resolución de problemas de bucle en el archivo Léame del complemento de bucle de coredns, por lo que se aplica más claramente a cualquier tipo de servidor de almacenamiento en caché DNS local, no solo resuelto por el sistema. coredns / coredns # 2363

@ aravind-murthy, ¿has vuelto a intentar esto?

@ aravind-murthy, ¿has vuelto a intentar esto?

@ alejandrox1 Todavía no, por favor, dame un poco de tiempo, necesito que el clúster k8s esté en funcionamiento para probar el complemento jenkins-k8s-kubectl (prueba de concepto no relacionada con este problema). Informaré cuando pueda.

parece que ya tenemos una entrada para esto en la guía TS aquí:
https://kubernetes.io/docs/setup/independent/troubleshooting-kubeadm/#coredns -pods-have-crashloopbackoff-or-error-state

@ aravind-murthy, aún así, siéntase libre de informar sus hallazgos.

Hola @ alejandrox1 , @ neolit123 - no sé si es la combinación del nuevo kubernetes v1.13 (cuando subí este ticket usé v1.12 porque esa era la versión disponible en ese momento) o si sigo las instrucciones (correctamente esto time), pero, en Ubuntu 16.04.05, instalando la última versión de kubernetes v1.13, siguiendo https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#tabs -pod-install-4 (es decir, Flannel ) y luego estableciendo net.bridge.bridge-nf-call-iptables en 1, usando el comando
sysctl net.bridge.bridge-nf-call-iptables=1 y luego reiniciar la máquina / VM, para permitir que la configuración de sysctl 'se mantenga' y luego instale Flannel ...

¡No más errores de crashloopback para coredns!

:-) :-)

Muchas gracias

@ aravind-murthy eso es interesante. El servicio está habilitado en el administrador de red, pero no se está ejecutando. Por favor, comente la línea 'dns = dnsmasq' en la configuración y reinicie el administrador de red: sudo systemctl restart network-manager

Luego restaure los servidores de nombres originales en /etc/resolv.conf (probablemente estén comentados). Eso debería ayudar a los pods core-dns cuando kubelet los reinicia.

deshabilitar dnsmasq para el administrador de red y comentar dnsmasq servidores

Tuve este mismo problema después de eliminar el bucle.

¿Puede alguien ayudarme con esto?

registros de kubectl coredns-fb8b8dccf-j6mjl -n kube-system
Error del servidor (BadRequest): el contenedor "coredns" en el pod "coredns-fb8b8dccf-j6mjl" está esperando para comenzar: ContainerCreating
master @ master : ~ $ sudo kubectl get pods --all-namespaces NOMBRE DEL ESPACIO NOMBRE ESTADO LISTO REINICIE EDAD
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 Corriendo 0 25m
kube-system kube-apiserver-master.testcluster.com 1/1 Ejecutando

@ Ramane19 , sus pods están bloqueados en "ContainerCreating", que es un problema diferente.

Antes de que se muestre pendiente, después de que eliminé el bucle, ¿mostró la creación de un contenedor?

¿Existe alguna otra forma de resolver este problema?

@ Ramane19 , ¿ha leído https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting?

Lo hice, habla del problema de los bucles, no de la creación de los contenedores.

@ Ramane19 , ¿ha leído https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting?

Bien, entonces parece no estar relacionado con este problema, es decir, fuera de tema.

Luego restaure los servidores de nombres originales en /etc/resolv.conf (probablemente estén comentados)

No he comentado nada en este archivo (/etc/resolv.conf). Actualmente tiene las siguientes 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

Esto funcionó para mi