Kubeadm: CoreDNS no comenzó con k8s 1.11 y weave (CentOS 7)

@kubernetes/sig-network-bugs

@carlosmkb , ¿cuál es tu versión de Docker?

Encuentro esto difícil de creer, probamos bastante CentOS 7 de nuestro lado.

¿Tiene los registros del sistema y del módulo?

¿Éste? https://stackoverflow.com/questions/44127247/does-anyone-know-a-workaround-for-no-new-privileges-blocking-selinux-transitions

@dims , puede tener sentido, lo intentaré

@neolit123 y @timothysc

versión de ventana acoplable: ventana acoplable-1.13.1-63.git94f4240.el7.centos.x86_64

registro de pods de corens : standard_init_linux.go:178: exec user process caused "operation not permitted"
registro del sistema journalctl -xeu kubelet :

Jul 17 23:45:17 server.raid.local kubelet[20442]: E0717 23:45:17.679867   20442 pod_workers.go:186] Error syncing pod dd030886-89f4-11e8-9786-0a92797fa29e ("cas-7d6d97c7bd-mzw5j_raidcloud(dd030886-89f4-11e8-9786-0a92797fa29e)"), skipping: failed to "StartContainer" for "cas" with ImagePullBackOff: "Back-off pulling image \"registry.raidcloud.io/raidcloud/cas:180328.pvt.01\""
Jul 17 23:45:18 server.raid.local kubelet[20442]: I0717 23:45:18.679059   20442 kuberuntime_manager.go:513] Container {Name:json2ldap Image:registry.raidcloud.io/raidcloud/json2ldap:180328.pvt.01 Command:[] Args:[] WorkingDir: Ports:[] EnvFrom:[] Env:[] Resources:{Limits:map[] Requests:map[]} VolumeMounts:[{Name:default-token-f2cmq ReadOnly:true MountPath:/var/run/secrets/kubernetes.io/serviceaccount SubPath: MountPropagation:<nil>}] VolumeDevices:[] LivenessProbe:&Probe{Handler:Handler{Exec:nil,HTTPGet:&HTTPGetAction{Path:/,Port:8080,Host:,Scheme:HTTP,HTTPHeaders:[],},TCPSocket:nil,},InitialDelaySeconds:30,TimeoutSeconds:5,PeriodSeconds:10,SuccessThreshold:1,FailureThreshold:3,} ReadinessProbe:nil Lifecycle:nil TerminationMessagePath:/dev/termination-log TerminationMessagePolicy:File ImagePullPolicy:IfNotPresent SecurityContext:&SecurityContext{Capabilities:nil,Privileged:*true,SELinuxOptions:nil,RunAsUser:nil,RunAsNonRoot:nil,ReadOnlyRootFilesystem:nil,AllowPrivilegeEscalation:nil,RunAsGroup:nil,} Stdin:false StdinOnce:false TTY:false} is dead, but RestartPolicy says that we should restart it.
Jul 17 23:45:18 server.raid.local kubelet[20442]: E0717 23:45:18.680001   20442 pod_workers.go:186] Error syncing pod dcc39ce2-89f4-11e8-9786-0a92797fa29e ("json2ldap-666fc85686-tmxrr_raidcloud(dcc39ce2-89f4-11e8-9786-0a92797fa29e)"), skipping: failed to "StartContainer" for "json2ldap" with ImagePullBackOff: "Back-off pulling image \"registry.raidcloud.io/raidcloud/json2ldap:180328.pvt.01\""
Jul 17 23:45:21 server.raid.local kubelet[20442]: I0717 23:45:21.678232   20442 kuberuntime_manager.go:513] Container {Name:coredns Image:k8s.gcr.io/coredns:1.1.3 Command:[] Args:[-conf /etc/coredns/Corefile] WorkingDir: Ports:[{Name:dns HostPort:0 ContainerPort:53 Protocol:UDP HostIP:} {Name:dns-tcp HostPort:0 ContainerPort:53 Protocol:TCP HostIP:} {Name:metrics HostPort:0 ContainerPort:9153 Protocol:TCP HostIP:}] EnvFrom:[] Env:[] Resources:{Limits:map[memory:{i:{value:178257920 scale:0} d:{Dec:<nil>} s:170Mi Format:BinarySI}] Requests:map[cpu:{i:{value:100 scale:-3} d:{Dec:<nil>} s:100m Format:DecimalSI} memory:{i:{value:73400320 scale:0} d:{Dec:<nil>} s:70Mi Format:BinarySI}]} VolumeMounts:[{Name:config-volume ReadOnly:true MountPath:/etc/coredns SubPath: MountPropagation:<nil>} {Name:coredns-token-6nhgg ReadOnly:true MountPath:/var/run/secrets/kubernetes.io/serviceaccount SubPath: MountPropagation:<nil>}] VolumeDevices:[] LivenessProbe:&Probe{Handler:Handler{Exec:nil,HTTPGet:&HTTPGetAction{Path:/health,Port:8080,Host:,Scheme:HTTP,HTTPHeaders:[],},TCPSocket:nil,},InitialDelaySeconds:60,TimeoutSeconds:5,PeriodSeconds:10,SuccessThreshold:1,FailureThreshold:5,} ReadinessProbe:nil Lifecycle:nil TerminationMessagePath:/dev/termination-log TerminationMessagePolicy:File ImagePullPolicy:IfNotPresent SecurityContext:&SecurityContext{Capabilities:&Capabilities{Add:[NET_BIND_SERVICE],Drop:[all],},Privileged:nil,SELinuxOptions:nil,RunAsUser:nil,RunAsNonRoot:nil,ReadOnlyRootFilesystem:*true,AllowPrivilegeEscalation:*false,RunAsGroup:nil,} Stdin:false StdinOnce:false TTY:false} is dead, but RestartPolicy says that we should restart it.
Jul 17 23:45:21 server.raid.local kubelet[20442]: I0717 23:45:21.678311   20442 kuberuntime_manager.go:757] checking backoff for container "coredns" in pod "coredns-78fcdf6894-znfvw_kube-system(9b44aa92-89f7-11e8-9786-0a92797fa29e)"
Jul 17 23:45:21 server.raid.local kubelet[20442]: I0717 23:45:21.678404   20442 kuberuntime_manager.go:767] Back-off 5m0s restarting failed container=coredns pod=coredns-78fcdf6894-znfvw_kube-system(9b44aa92-89f7-11e8-9786-0a92797fa29e)
Jul 17 23:45:21 server.raid.local kubelet[20442]: E0717 23:45:21.678425   20442 pod_workers.go:186] Error syncing pod 9b44aa92-89f7-11e8-9786-0a92797fa29e ("coredns-78fcdf6894-znfvw_kube-system(9b44aa92-89f7-11e8-9786-0a92797fa29e)"), skipping: failed to "StartContainer" for "coredns" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=coredns pod=coredns-78fcdf6894-znfvw_kube-system(9b44aa92-89f7-11e8-9786-0a92797fa29e)"
Jul 17 23:45:22 server.raid.local kubelet[20442]: I0717 23:45:22.679145   20442 kuberuntime_manager.go:513] Container {Name:login Image:registry.raidcloud.io/raidcloud/admin:180329.pvt.05 Command:[] Args:[] WorkingDir: Ports:[] EnvFrom:[] Env:[] Resources:{Limits:map[] Requests:map[]} VolumeMounts:[{Name:login-config ReadOnly:true MountPath:/usr/share/nginx/conf/ SubPath: MountPropagation:<nil>} {Name:default-token-f2cmq ReadOnly:true MountPath:/var/run/secrets/kubernetes.io/serviceaccount SubPath: MountPropagation:<nil>}] VolumeDevices:[] LivenessProbe:&Probe{Handler:Handler{Exec:nil,HTTPGet:&HTTPGetAction{Path:/health,Port:8080,Host:,Scheme:HTTP,HTTPHeaders:[],},TCPSocket:nil,},InitialDelaySeconds:5,TimeoutSeconds:5,PeriodSeconds:10,SuccessThreshold:1,FailureThreshold:3,} ReadinessProbe:nil Lifecycle:nil TerminationMessagePath:/dev/termination-log TerminationMessagePolicy:File ImagePullPolicy:IfNotPresent SecurityContext:&SecurityContext{Capabilities:nil,Privileged:*true,SELinuxOptions:nil,RunAsUser:nil,RunAsNonRoot:nil,ReadOnlyRootFilesystem:nil,AllowPrivilegeEscalation:nil,RunAsGroup:nil,} Stdin:false StdinOnce:false TTY:false} is dead, but RestartPolicy says that we should restart it.
Jul 17 23:45:22 server.raid.local kubelet[20442]: E0717 23:45:22.679941   20442 pod_workers.go:186] Error syncing pod dc8392a9-89f4-11e8-9786-0a92797fa29e ("login-85ffb66bb8-5l9fq_raidcloud(dc8392a9-89f4-11e8-9786-0a92797fa29e)"), skipping: failed to "StartContainer" for "login" with ImagePullBackOff: "Back-off pulling image \"registry.raidcloud.io/raidcloud/admin:180329.pvt.05\""
Jul 17 23:45:23 server.raid.local kubelet[20442]: I0717 23:45:23.678172   20442 kuberuntime_manager.go:513] Container {Name:coredns Image:k8s.gcr.io/coredns:1.1.3 Command:[] Args:[-conf /etc/coredns/Corefile] WorkingDir: Ports:[{Name:dns HostPort:0 ContainerPort:53 Protocol:UDP HostIP:} {Name:dns-tcp HostPort:0 ContainerPort:53 Protocol:TCP HostIP:} {Name:metrics HostPort:0 ContainerPort:9153 Protocol:TCP HostIP:}] EnvFrom:[] Env:[] Resources:{Limits:map[memory:{i:{value:178257920 scale:0} d:{Dec:<nil>} s:170Mi Format:BinarySI}] Requests:map[cpu:{i:{value:100 scale:-3} d:{Dec:<nil>} s:100m Format:DecimalSI} memory:{i:{value:73400320 scale:0} d:{Dec:<nil>} s:70Mi Format:BinarySI}]} VolumeMounts:[{Name:config-volume ReadOnly:true MountPath:/etc/coredns SubPath: MountPropagation:<nil>} {Name:coredns-token-6nhgg ReadOnly:true MountPath:/var/run/secrets/kubernetes.io/serviceaccount SubPath: MountPropagation:<nil>}] VolumeDevices:[] LivenessProbe:&Probe{Handler:Handler{Exec:nil,HTTPGet:&HTTPGetAction{Path:/health,Port:8080,Host:,Scheme:HTTP,HTTPHeaders:[],},TCPSocket:nil,},InitialDelaySeconds:60,TimeoutSeconds:5,PeriodSeconds:10,SuccessThreshold:1,FailureThreshold:5,} ReadinessProbe:nil Lifecycle:nil TerminationMessagePath:/dev/termination-log TerminationMessagePolicy:File ImagePullPolicy:IfNotPresent SecurityContext:&SecurityContext{Capabilities:&Capabilities{Add:[NET_BIND_SERVICE],Drop:[all],},Privileged:nil,SELinuxOptions:nil,RunAsUser:nil,RunAsNonRoot:nil,ReadOnlyRootFilesystem:*true,AllowPrivilegeEscalation:*false,RunAsGroup:nil,} Stdin:false StdinOnce:false TTY:false} is dead, but RestartPolicy says that we should restart it.
Jul 17 23:45:23 server.raid.local kubelet[20442]: I0717 23:45:23.678412   20442 kuberuntime_manager.go:757] checking backoff for container "coredns" in pod "coredns-78fcdf6894-lcqt5_kube-system(9b45a068-89f7-11e8-9786-0a92797fa29e)"
Jul 17 23:45:23 server.raid.local kubelet[20442]: I0717 23:45:23.678532   20442 kuberuntime_manager.go:767] Back-off 5m0s restarting failed container=coredns pod=coredns-78fcdf6894-lcqt5_kube-system(9b45a068-89f7-11e8-9786-0a92797fa29e)
Jul 17 23:45:23 server.raid.local kubelet[20442]: E0717 23:45:23.678554   20442 pod_workers.go:186] Error syncing pod 9b45a068-89f7-11e8-9786-0a92797fa29e ("coredns-78fcdf6894-lcqt5_kube-system(9b45a068-89f7-11e8-9786-0a92797fa29e)"), skipping: failed to "StartContainer" for "coredns" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=coredns pod=coredns-78fcdf6894-lcqt5_kube-system(9b45a068-89f7-11e8-9786-0a92797fa29e)"

Encontré un par de instancias de los mismos errores informados en otros escenarios en el pasado.
Podría intentar eliminar "allowPrivilegeEscalation: false" de la implementación de CoreDNS para ver si eso ayuda.

El mismo problema para mí. Configuración similar CentOS 7.4.1708, Docker versión 1.13.1, compilación 94f4240/1.13.1 (viene con CentOS):

[root@faas-A01 ~]# kubectl get pods --all-namespaces
NAMESPACE     NAME                                                 READY     STATUS             RESTARTS   AGE
kube-system   calico-node-2vssv                                    2/2       Running            0          9m
kube-system   calico-node-4vr7t                                    2/2       Running            0          7m
kube-system   calico-node-nlfnd                                    2/2       Running            0          17m
kube-system   calico-node-rgw5w                                    2/2       Running            0          23m
kube-system   coredns-78fcdf6894-p4wbl                             0/1       CrashLoopBackOff   9          30m
kube-system   coredns-78fcdf6894-r4pwf                             0/1       CrashLoopBackOff   9          30m
kube-system   etcd-faas-a01.sl.cloud9.ibm.com                      1/1       Running            0          29m
kube-system   kube-apiserver-faas-a01.sl.cloud9.ibm.com            1/1       Running            0          29m
kube-system   kube-controller-manager-faas-a01.sl.cloud9.ibm.com   1/1       Running            0          29m
kube-system   kube-proxy-55csj                                     1/1       Running            0          17m
kube-system   kube-proxy-56r8c                                     1/1       Running            0          30m
kube-system   kube-proxy-kncql                                     1/1       Running            0          9m
kube-system   kube-proxy-mf2bp                                     1/1       Running            0          7m
kube-system   kube-scheduler-faas-a01.sl.cloud9.ibm.com            1/1       Running            0          29m
[root@faas-A01 ~]# kubectl logs --namespace=all coredns-78fcdf6894-p4wbl
Error from server (NotFound): namespaces "all" not found
[root@faas-A01 ~]# kubectl logs --namespace=kube-system coredns-78fcdf6894-p4wbl
standard_init_linux.go:178: exec user process caused "operation not permitted"

por si acaso, selinux está en modo permisivo en todos los nodos.

Y estoy usando Calico (no tejido como @carlosmkb).

[ root@faas-A01 ~]# kubectl logs --namespace=kube-system coredns-78fcdf6894-p4wbl
standard_init_linux.go:178: el proceso de usuario exec causó "operación no permitida"

Ah: este es un error de kubectl al intentar obtener los registros, no el contenido de los registros...

@chrisohaver el kubectl logs funciona con otros pods del sistema kube

Bien, ¿ha intentado eliminar "allowPrivilegeEscalation: false" de la implementación de CoreDNS para ver si eso ayuda?

... ¿un kubectl describe del pod de coredns muestra algo interesante?

El mismo problema para mí.
Versión de CentOS Linux 7.5.1804 (núcleo)
Docker versión 1.13.1, compilación dded712/1.13.1
franela como complemento cni

[root<strong i="9">@k8s</strong> ~]# kubectl get pods --all-namespaces
NAMESPACE     NAME                                 READY     STATUS             RESTARTS   AGE
kube-system   coredns-78fcdf6894-cfmm7             0/1       CrashLoopBackOff   12         15m
kube-system   coredns-78fcdf6894-k65js             0/1       CrashLoopBackOff   11         15m
kube-system   etcd-k8s.master                      1/1       Running            0          14m
kube-system   kube-apiserver-k8s.master            1/1       Running            0          13m
kube-system   kube-controller-manager-k8s.master   1/1       Running            0          14m
kube-system   kube-flannel-ds-fts6v                1/1       Running            0          14m
kube-system   kube-proxy-4tdb5                     1/1       Running            0          15m
kube-system   kube-scheduler-k8s.master            1/1       Running            0          14m
[root<strong i="10">@k8s</strong> ~]# kubectl logs coredns-78fcdf6894-cfmm7 -n kube-system
standard_init_linux.go:178: exec user process caused "operation not permitted"
[root<strong i="11">@k8s</strong> ~]# kubectl describe pods coredns-78fcdf6894-cfmm7 -n kube-system
Name:           coredns-78fcdf6894-cfmm7
Namespace:      kube-system
Node:           k8s.master/192.168.150.40
Start Time:     Fri, 27 Jul 2018 00:32:09 +0800
Labels:         k8s-app=kube-dns
                pod-template-hash=3497892450
Annotations:    <none>
Status:         Running
IP:             10.244.0.12
Controlled By:  ReplicaSet/coredns-78fcdf6894
Containers:
  coredns:
    Container ID:  docker://3b7670fbc07084410984d7e3f8c0fa1b6d493a41d2a4e32f5885b7db9d602417
    Image:         k8s.gcr.io/coredns:1.1.3
    Image ID:      docker-pullable://k8s.gcr.io/coredns<strong i="12">@sha256</strong>:db2bf53126ed1c761d5a41f24a1b82a461c85f736ff6e90542e9522be4757848
    Ports:         53/UDP, 53/TCP, 9153/TCP
    Host Ports:    0/UDP, 0/TCP, 0/TCP
    Args:
      -conf
      /etc/coredns/Corefile
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Fri, 27 Jul 2018 00:46:30 +0800
      Finished:     Fri, 27 Jul 2018 00:46:30 +0800
    Ready:          False
    Restart Count:  12
    Limits:
      memory:  170Mi
    Requests:
      cpu:        100m
      memory:     70Mi
    Liveness:     http-get http://:8080/health delay=60s timeout=5s period=10s #success=1 #failure=5
    Environment:  <none>
    Mounts:
      /etc/coredns from config-volume (ro)
      /var/run/secrets/kubernetes.io/serviceaccount from coredns-token-vqslm (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  config-volume:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      coredns
    Optional:  false
  coredns-token-vqslm:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  coredns-token-vqslm
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     CriticalAddonsOnly
                 node-role.kubernetes.io/master:NoSchedule
                 node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason            Age                 From                 Message
  ----     ------            ----                ----                 -------
  Warning  FailedScheduling  16m (x6 over 16m)   default-scheduler    0/1 nodes are available: 1 node(s) were not ready.
  Normal   Scheduled         16m                 default-scheduler    Successfully assigned kube-system/coredns-78fcdf6894-cfmm7 to k8s.master
  Warning  BackOff           14m (x10 over 16m)  kubelet, k8s.master  Back-off restarting failed container
  Normal   Pulled            14m (x5 over 16m)   kubelet, k8s.master  Container image "k8s.gcr.io/coredns:1.1.3" already present on machine
  Normal   Created           14m (x5 over 16m)   kubelet, k8s.master  Created container
  Normal   Started           14m (x5 over 16m)   kubelet, k8s.master  Started container
  Normal   Pulled            11m (x4 over 12m)   kubelet, k8s.master  Container image "k8s.gcr.io/coredns:1.1.3" already present on machine
  Normal   Created           11m (x4 over 12m)   kubelet, k8s.master  Created container
  Normal   Started           11m (x4 over 12m)   kubelet, k8s.master  Started container
  Warning  BackOff           2m (x56 over 12m)   kubelet, k8s.master  Back-off restarting failed container
[root<strong i="13">@k8s</strong> ~]# uname
Linux
[root<strong i="14">@k8s</strong> ~]# uname -a
Linux k8s.master 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[root<strong i="15">@k8s</strong> ~]# cat /etc/redhat-release 
CentOS Linux release 7.5.1804 (Core) 
[root<strong i="16">@k8s</strong> ~]# docker --version
Docker version 1.13.1, build dded712/1.13.1

Tengo el mismo problema cuando selinux está en modo permisivo. Cuando lo deshabilito en /etc/selinux/conf SELINUX=disabled y reinicio la máquina, el pod se inicia.

Redhat 7.4, núcleo 3.10.0-693.11.6.el7.x86_64
docker-1.13.1-68.gitdded712.el7.x86_64

FYI, también funciona para mí con SELinux deshabilitado (no permisivo, pero _deshabilitado_).
Docker versión 1.13.1, compilación dded712/1.13.1
CentOS 7

[root<strong i="8">@centosk8s</strong> ~]# kubectl logs coredns-78fcdf6894-rhx9p -n kube-system
.:53
CoreDNS-1.1.3
linux/amd64, go1.10.1, b0fd575c
2018/07/27 16:37:31 [INFO] CoreDNS-1.1.3
2018/07/27 16:37:31 [INFO] linux/amd64, go1.10.1, b0fd575c
2018/07/27 16:37:31 [INFO] plugin/reload: Running configuration MD5 = 2a066f12ec80aeb2b92740dd74c17138

También estamos experimentando este problema, aprovisionamos infraestructura a través de la automatización, por lo que no es aceptable requerir un reinicio para deshabilitar completamente selinux. ¿Hay alguna otra solución por la que esperemos a que esto se solucione?

Intente eliminar "allowPrivilegeEscalation: false" de la implementación de CoreDNS para ver si eso ayuda.
Actualizar a una versión más reciente de docker (que 1.13) también puede ayudar.

Mismo problema aquí
Docker versión 1.2.6
CentOS 7
como @lareeth , también aprovisionamos la automatización de kubernetes en el uso de kubeadm, y tampoco es aceptable requerir un reinicio para deshabilitar completamente selinux.
@chrisohaver intentar requerir un reinicio para deshabilitar completamente selinux no es aceptable. es útil. gracias !
Pero como sé, las opciones de coredns no están configuradas en la configuración de kubeadm
¿No hay otra manera?

Intente eliminar "allowPrivilegeEscalation: false" de la implementación de CoreDNS para ver si eso ayuda.
Actualizar a una versión más reciente de docker (por ejemplo, a la versión recomendada por k8s) también puede ayudar.

Verifiqué que eliminar "allowPrivilegeEscalation: false" de la implementación de coredns resuelve el problema (con SE linux habilitado en modo permisivo).

También verifiqué que actualizar a una versión de docker recomendada por Kubernetes (docker 17.03) resuelve el problema, con "allowPrivilegeEscalation: false" en su lugar en la implementación de coredns y SELinux habilitado en modo permisivo.

Por lo tanto, parece que existe una incompatibilidad entre las versiones anteriores de docker y SELinux con la directiva allowPrivilegeEscalation que aparentemente se resolvió en versiones posteriores de docker.

Parece que hay 3 soluciones diferentes:

• Actualice a una versión más nueva de docker, por ejemplo, 17.03, la versión actualmente recomendada por k8s
• O elimine allowPrivilegeEscalation=false de la especificación del pod de la implementación.
• O desactivar SELinux

@chrisohaver Resolví el problema al actualizar a la versión más nueva de docker 17.03. gracias

gracias por la investigación @chrisohaver :100:

¡Gracias, @chrisohaver !

Esto funcionó:

kubectl -n kube-system get deployment coredns -o yaml | \
  sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
  kubectl apply -f -

@chrisohaver
¿Cree que deberíamos documentar este paso en la guía de solución de problemas de kubeadm para nodos de SELinux en las líneas de:

Los pods coredns tienen un estado CrashLoopBackOff o Error

Si tiene nodos que ejecutan SELinux con una versión anterior de Docker, es posible que experimente un escenario en el que los pods coredns no se inician. Para solucionarlo puedes probar una de las siguientes opciones:

• Actualice a una versión más reciente de Docker: se confirma que la 17.03 funciona.
• Deshabilite SELinux.
• Modifique la implementación de coredns para establecer allowPrivilegeEscalation en true :

kubectl -n kube-system get deployment coredns -o yaml | \
  sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
  kubectl apply -f -

WDYT? sugiera enmiendas al texto si cree que se puede mejorar algo.

Esta bien. Tal vez deberíamos mencionar que existen implicaciones de seguridad negativas al deshabilitar SELinux o cambiar la configuración de allowPrivilegeEscalation.

La solución más segura es actualizar Docker a la versión que recomienda Kubernetes (17.03)

@chrisohaver
entendido, modificará la copia y presentará un PR para ello.

También hay una respuesta para eso en stackoverflow:
https://stackoverflow.com/questions/53075796/coredns-pods-have-crashloopbackoff-or-error-state

Este error

[FATAL] plugin/loop: Seen "HINFO IN 6900627972087569316.7905576541070882081." more than twice, loop detected

se produce cuando CoreDNS detecta un bucle en la configuración de resolución y es el comportamiento previsto. Estás golpeando este problema:

https://github.com/kubernetes/kubeadm/issues/1162

https://github.com/coredns/coredns/issues/2087

Solución Hacky: deshabilite la detección de bucle CoreDNS

Edite el mapa de configuración de CoreDNS:

kubectl -n kube-system edit configmap coredns

Elimine o comente la línea con loop , guarde y salga.

Luego, elimine los pods de CoreDNS, para que se puedan crear nuevos con la nueva configuración:

kubectl -n kube-system delete pod -l k8s-app=kube-dns

Todo debería estar bien después de eso.

Solución preferida: eliminar el bucle en la configuración de DNS

Primero, verifica si estás usando systemd-resolved . Si está ejecutando Ubuntu 18.04, probablemente sea el caso.

systemctl list-unit-files | grep enabled | grep systemd-resolved

Si es así, verifique qué archivo resolv.conf está usando su clúster como referencia:

ps auxww | grep kubelet

Es posible que vea una línea como:

/usr/bin/kubelet ... --resolv-conf=/run/systemd/resolve/resolv.conf

La parte importante es --resolv-conf : averiguamos si systemd resolv.conf se usa o no.

Si es el resolv.conf de systemd , haga lo siguiente:

Verifique el contenido de /run/systemd/resolve/resolv.conf para ver si hay un registro como:

nameserver 127.0.0.1

Si hay 127.0.0.1 , es el que causa el bucle.

Para deshacerse de él, no debe editar ese archivo, sino verificar otros lugares para que se genere correctamente.

Verifique todos los archivos por debajo /etc/systemd/network y si encuentra un registro como

DNS=127.0.0.1

borrar ese registro. También marque /etc/systemd/resolved.conf y haga lo mismo si es necesario. Asegúrese de tener al menos uno o dos servidores DNS configurados, como

DNS=1.1.1.1 1.0.0.1

Después de hacer todo eso, reinicie los servicios de systemd para que los cambios surtan efecto:
systemctl reiniciar systemd-networkd systemd-resuelto

Después de eso, verifique que DNS=127.0.0.1 ya no esté en el archivo resolv.conf :

cat /run/systemd/resolve/resolv.conf

Finalmente, active la recreación de los pods de DNS

kubectl -n kube-system delete pod -l k8s-app=kube-dns

Resumen: la solución consiste en deshacerse de lo que parece un bucle de búsqueda de DNS de la configuración de DNS del host. Los pasos varían entre diferentes administradores/implementaciones de resolv.conf.

Gracias. También se trata en el archivo Léame del complemento de bucle de CoreDNS ...

tengo el mismo problema y otro problema
1, significa que no puedo encontrar dns. el error es
[ERROR] complemento/errores: 2 2115717704248378980.1120568170924441806. HINFO: backend inalcanzable: leer udp 10.224.0.3:57088->8.8.8.8:53: tiempo de espera de E/S
[ERROR] complemento/errores: 2 2115717704248378980.1120568170924441806. HINFO: backend inalcanzable: leer udp 10.224.0.3:38819->172.16.254.1:53: tiempo de espera de E/S
........

mi /etc/resolv.com
no tengo
servidor de nombres 172.16.254.1 #este es mi dns
servidor de nombres 8.8.8.8 #otro dns en red
Corro

kubectl -n kube-system obtener implementación coredns -o yaml | \
sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
kubectl aplicar -f -

entonces la reconstrucción del pod solo tiene un error

[ERROR] complemento/errores: 2 10594135170717325.8545646296733374240. HINFO: backend inalcanzable: sin host ascendente

No sé si eso es normal. quizás

2, los corens no pueden encontrar mi servicio api. el error es

kube-dns No se pudo enumerar *v1.Endpoints getsockopt: 10.96.0.1:6443 conexión api rechazada

coredns se reinicia una y otra vez, por fin CrashLoopBackOff

así que tengo que ejecutar coredns en el nodo maestro, hago eso

kubectl edit deployment/coredns --namespace=kube-system
especificación.plantilla.especificación
selector de nodos:
rol-nodo.kubernetes.io/master: ""

no se si eso es normal

por fin dar mi env

Linux 4.20.10-1.el7.elrepo.x86_64 /// centos 7

Versión acoplable: 18.09.3

[ root@k8smaster00 ~]# imagen acoplable ls -a
ID DE LA IMAGEN DE LA ETIQUETA DEL REPOSITOR TAMAÑO CREADO
k8s.gcr.io/kube-controller-manager v1.13.3 0482f6400933 Hace 6 semanas 146 MB
k8s.gcr.io/kube-proxy v1.13.3 98db19758ad4 Hace 6 semanas 80.3MB
k8s.gcr.io/kube-apiserver v1.13.3 fe242e556a99 Hace 6 semanas 181 MB
k8s.gcr.io/kube-scheduler v1.13.3 3a6f709e97a0 Hace 6 semanas 79.6MB
quay.io/coreos/flannel v0.11.0-amd64 ff281650a721 Hace 7 semanas 52.6MB
k8s.gcr.io/coredns 1.2.6 f59dcacceff4 Hace 4 meses 40MB
k8s.gcr.io/etcd 3.2.24 3cab8e1b9802 Hace 6 meses 220MB
k8s.gcr.io/pause 3.1 da86e6ba6ca1 Hace 15 meses 742kB

kubenets es 1.13.3

Creo que esto es un error Espere una actualización oficial o una solución

Yo tengo el mismo problema ...

@mengxifl , esos errores son significativamente diferentes a los informados y discutidos en este problema.

[ERROR] complemento/errores: 2 2115717704248378980.1120568170924441806. HINFO: backend inalcanzable: leer udp 10.224.0.3:57088->8.8.8.8:53: tiempo de espera de E/S
[ERROR] complemento/errores: 2 2115717704248378980.1120568170924441806. HINFO: backend inalcanzable: leer udp 10.224.0.3:38819->172.16.254.1:53: tiempo de espera de E/S

Esos errores significan que el pod de CoreDNS (y probablemente todos los demás pods) no pueden acceder a sus servidores de nombres. Esto sugiere un problema de red en su clúster para el mundo exterior. Posiblemente mala configuración de franela o cortafuegos.

los coredns no pueden encontrar mi servicio api...
así que tengo que ejecutar coredns en el nodo maestro

Esto tampoco es normal. Si lo entiendo correctamente, está diciendo que CoreDNS puede comunicarse con la API desde el nodo maestro, pero no desde otros nodos. Esto sugeriría un pod para dar servicio a los problemas de red entre los nodos dentro de su clúster, tal vez un problema con la configuración de franela o los firewalls.

Yo tengo el mismo problema ...

@mengxifl , esos errores son significativamente diferentes a los informados y discutidos en este problema.

[ERROR] complemento/errores: 2 2115717704248378980.1120568170924441806. HINFO: backend inalcanzable: leer udp 10.224.0.3:57088->8.8.8.8:53: tiempo de espera de E/S
[ERROR] complemento/errores: 2 2115717704248378980.1120568170924441806. HINFO: backend inalcanzable: leer udp 10.224.0.3:38819->172.16.254.1:53: tiempo de espera de E/S

Esos errores significan que el pod de CoreDNS (y probablemente todos los demás pods) no pueden acceder a sus servidores de nombres. Esto sugiere un problema de red en su clúster para el mundo exterior. Posiblemente mala configuración de franela o cortafuegos.

los coredns no pueden encontrar mi servicio api...
así que tengo que ejecutar coredns en el nodo maestro

Esto tampoco es normal. Si lo entiendo correctamente, está diciendo que CoreDNS puede comunicarse con la API desde el nodo maestro, pero no desde otros nodos. Esto sugeriría un pod para dar servicio a los problemas de red entre los nodos dentro de su clúster, tal vez un problema con la configuración de franela o los firewalls.

Gracias por su respuesta

tal vez debería poner mi archivo yaml

yo suelo
inicio de kubeadm --config=config.yaml

mi contenido config.yaml es

apiVersion: kubeadm.k8s.io/v1alpha3
kind: InitConfiguration
apiEndpoint:
  advertiseAddress: "172.16.254.74"
  bindPort: 6443
---
apiVersion: kubeadm.k8s.io/v1alpha3
kind: ClusterConfiguration
kubernetesVersion: "v1.13.3"
etcd:
  external:
    endpoints:
    - "https://172.16.254.86:2379" 
    - "https://172.16.254.87:2379"
    - "https://172.16.254.88:2379"
    caFile: /etc/kubernetes/pki/etcd/ca.pem
    certFile: /etc/kubernetes/pki/etcd/client.pem
    keyFile: /etc/kubernetes/pki/etcd/client-key.pem
networking:
  podSubnet: "10.224.0.0/16"
  serviceSubnet: "10.96.0.0/12"
apiServerCertSANs:
- k8smaster00
- k8smaster01
- k8snode00
- k8snode01
- 172.16.254.74
- 172.16.254.79
- 172.16.254.80
- 172.16.254.81
- 172.16.254.85 #Vip
- 127.0.0.1
clusterName: "cluster"
controlPlaneEndpoint: "172.16.254.85:6443"

apiServerExtraArgs:
  service-node-port-range: 20-65535

mi fannel yaml es predeterminado

https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

systemctl status firewalld
TODOS los nodos dicen
No se pudo encontrar la unidad firewalld.service.

cat /etc/sysconfig/iptables
TODOS los nodos dicen
*filtrar
:ENTRADA ACEPTAR [0:0]
:ADELANTE ACEPTAR [0:0]
: SALIDA ACEPTAR [0:0]
-A ENTRADA -p tcp -m tcp --dport 1:65535 -j ACEPTAR
-A ENTRADA -m estado --estado RELACIONADO, ESTABLECIDO -j ACEPTAR
-A ENTRADA -p icmp -j ACEPTAR
-A ENTRADA -i lo -j ACEPTAR
-A ENTRADA -p tcp -m estado --estado NUEVO -m tcp --dport 22 -j ACEPTAR
-A SALIDA -p tcp -m tcp --sport 1:65535 -j ACEPTAR
-A ADELANTE -p tcp -m tcp --dport 1:65535 -j ACEPTAR
-A ADELANTE -p tcp -m tcp --sport 1:65535 -j ACEPTAR
COMI

cat /etc/resolv.conf & ping bing.com
TODOS los nodos dicen
[1] 6330
servidor de nombres 172.16.254.1
servidor de nombres 8.8.8.8
PING bing.com (13.107.21.200) 56(84) bytes de datos.
64 bytes desde 13.107.21.200 (13.107.21.200): icmp_seq=2 ttl=111 tiempo=149 ms

uname -rs
nodo maestro decir
Linux 4.20.10-1.el7.elrepo.x86_64

uname -rs
nodo esclavo decir
Linux 4.4.176-1.el7.elrepo.x86_64

entonces no creo que el firewall tenga problemas con mybe fannel? pero uso la configuración predeterminada. Y tal vez la versión de Linux. no sé .

ok corro
/sbin/iptables -t nat -I POSTROUTING -s 10.224.0.0/16 -j MASQUERADE

en todos mis nodos que funcionan para mí. Gracias