Kubeadm: CoreDNS não iniciado com k8s 1.11 e weave (CentOS 7)

@kubernetes/sig-network-bugs

@carlosmkb , qual é a sua versão do docker?

Acho difícil de acreditar, testamos extensivamente o CentOS 7 do nosso lado.

Você tem os logs do sistema e do pod?

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

@dims , pode fazer sentido, vou tentar

@neolit123 e @timothysc

versão do docker: docker-1.13.1-63.git94f4240.el7.centos.x86_64

log de pods do coredns : standard_init_linux.go:178: exec user process caused "operation not permitted"
log do 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)"

Encontrou algumas instâncias dos mesmos erros relatados em outros cenários no passado.
Pode tentar remover "allowPrivilegeEscalation: false" da implantação do CoreDNS para ver se isso ajuda.

Mesma questão para mim. Configuração semelhante CentOS 7.4.1708, Docker versão 1.13.1, compilação 94f4240/1.13.1 (vem com 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"

apenas no caso, o selinux está no modo permissivo em todos os nós.

E estou usando Calico (não tece como @carlosmkb).

[ root@faas-A01 ~]# kubectl logs --namespace=kube-system coredns-78fcdf6894-p4wbl
standard_init_linux.go:178: processo de usuário exec causou "operação não permitida"

Ah - Este é um erro do kubectl ao tentar obter os logs, não o conteúdo dos logs...

@chrisohaver o kubectl logs funciona com outros pods do sistema kube

OK - você tentou remover "allowPrivilegeEscalation: false" da implantação do CoreDNS para ver se isso ajuda?

... um kubectl describe do pod coredns mostra algo interessante?

Mesma questão para mim.
CentOS Linux versão 7.5.1804 (Núcleo)
Docker versão 1.13.1, compilação dded712/1.13.1
flanela como complemento da 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

Eu tenho o mesmo problema quando o selinux está no modo permissivo. Quando eu desabilito em /etc/selinux/conf SELINUX=disabled e reinicio a máquina, o pod é inicializado.

Redhat 7.4, kernel 3.10.0-693.11.6.el7.x86_64
docker-1.13.1-68.gitdded712.el7.x86_64

FYI, também funciona para mim com o SELinux desativado (não permissivo, mas _disabled_).
Docker versão 1.13.1, compilação 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

Também estamos enfrentando esse problema, provisionamos infraestrutura por meio de automação, portanto, exigir uma reinicialização para desabilitar completamente o selinux não é aceitável. Existem outras soluções alternativas por que esperamos que isso seja corrigido?

Tente remover "allowPrivilegeEscalation: false" da implantação do CoreDNS para ver se isso ajuda.
Atualizar para uma versão mais recente do docker (que 1.13) também pode ajudar.

Mesmo problema aqui
Versão do Docker 1.2.6
CentOS 7
como @lareeth , também provisionamos a automação do kubernetes ao usar o kubeadm, e também exigir uma reinicialização para desabilitar completamente o selinux não é aceitável.
@chrisohaver tentar exigir uma reinicialização para desabilitar completamente o selinux não é aceitável. ele usa útil. obrigada !
Mas, como eu sei, as opções do coredns não estão sendo definidas na configuração do kubeadm
Não há outra maneira?

Tente remover "allowPrivilegeEscalation: false" da implantação do CoreDNS para ver se isso ajuda.
Atualizar para uma versão mais recente do docker (por exemplo, para a versão recomendada pelo k8s) também pode ajudar.

Verifiquei que a remoção de "allowPrivilegeEscalation: false" da implantação do coredns resolve o problema (com o SE linux habilitado no modo permissivo).

Também verifiquei que a atualização para uma versão do docker recomendada pelo Kubernetes (docker 17.03) resolve o problema, com "allowPrivilegeEscalation: false" deixado na implantação do coredns e o SELinux habilitado no modo permissivo.

Portanto, parece que há uma incompatibilidade entre as versões antigas do docker e do SELinux com a diretiva allowPrivilegeEscalation que aparentemente foi resolvida em versões posteriores do docker.

Parece haver 3 soluções alternativas diferentes:

• Atualize para a versão mais recente do docker, por exemplo, 17.03, a versão atualmente recomendada pelo k8s
• Ou remova allowPrivilegeEscalation=false da especificação do pod da implantação
• Ou desative o SELinux

@chrishaver Resolvi o problema atualizando para a versão mais recente do docker 17.03. THX

obrigado pela investigação @chrishaver :100:

Obrigado, @chrishaver !

Isso funcionou:

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

@chrishaver
você acha que devemos documentar esta etapa no guia de solução de problemas do kubeadm para nós SELinux nas linhas de:

Os pods coredns têm estado CrashLoopBackOff ou Error

Se você tiver nós que estão executando o SELinux com uma versão mais antiga do Docker, poderá enfrentar um cenário em que os pods coredns não estão sendo iniciados. Para resolver isso, você pode tentar uma das seguintes opções:

• A atualização para uma versão mais recente do Docker - 17.03 está confirmada para funcionar.
• Desative o SELinux.
• Modifique a implantação coredns para definir allowPrivilegeEscalation para true :

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

WDYT? por favor, sugira alterações ao texto se achar que algo pode ser melhorado.

Isso é bom. Talvez devêssemos mencionar que há implicações de segurança negativas ao desabilitar o SELinux ou alterar a configuração allowPrivilegeEscalation.

A solução mais segura é atualizar o Docker para a versão que o Kubernetes recomenda (17.03)

@chrishaver
entendido, alterará a cópia e enviará um PR para isso.

Também há uma resposta para isso no stackoverflow:
https://stackoverflow.com/questions/53075796/coredns-pods-have-crashloopbackoff-or-error-state

Esse erro

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

é causado quando o CoreDNS detecta um loop na configuração de resolução e é o comportamento pretendido. Você está acertando este problema:

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

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

Solução hacky: desative a detecção de loop CoreDNS

Edite o mapa de configuração do CoreDNS:

kubectl -n kube-system edit configmap coredns

Remova ou comente a linha com loop , salve e saia.

Em seguida, remova os pods CoreDNS, para que novos possam ser criados com nova configuração:

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

Tudo deve ficar bem depois disso.

Solução preferencial: remova o loop na configuração de DNS

Primeiro, verifique se você está usando systemd-resolved . Se você estiver executando o Ubuntu 18.04, provavelmente é o caso.

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

Se estiver, verifique qual arquivo resolv.conf seu cluster está usando como referência:

ps auxww | grep kubelet

Você pode ver uma linha como:

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

A parte importante é --resolv-conf - nós descobrimos se o systemd resolv.conf é usado ou não.

Se for resolv.conf de systemd , faça o seguinte:

Verifique o conteúdo de /run/systemd/resolve/resolv.conf para ver se há um registro como:

nameserver 127.0.0.1

Se houver 127.0.0.1 , é aquele que está causando o loop.

Para se livrar dele, você não deve editar esse arquivo, mas verificar outros lugares para torná-lo gerado corretamente.

Verifique todos os arquivos em /etc/systemd/network e se você encontrar um registro como

DNS=127.0.0.1

excluir esse registro. Verifique também /etc/systemd/resolved.conf e faça o mesmo, se necessário. Certifique-se de ter pelo menos um ou dois servidores DNS configurados, como

DNS=1.1.1.1 1.0.0.1

Depois de fazer tudo isso, reinicie os serviços do systemd para colocar suas alterações em vigor:
systemctl reinicie systemd-networkd systemd-resolved

Depois disso, verifique se DNS=127.0.0.1 não está mais no arquivo resolv.conf :

cat /run/systemd/resolve/resolv.conf

Por fim, acione a recriação dos pods DNS

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

Resumo: A solução envolve eliminar o que parece ser um loop de pesquisa de DNS da configuração de DNS do host. As etapas variam entre os diferentes gerenciadores/implementações do resolv.conf.

Obrigado. Também é abordado no leia-me do plug-in de loop CoreDNS ...

Estou com o mesmo problema e outro problema
1、significa que não consigo encontrar dns. o erro é
[ERRO] plugin/erros: 2 2115717704248378980.1120568170924441806. HINFO: back-end inacessível: leia udp 10.224.0.3:57088->8.8.8.8:53: tempo limite de e/s
[ERRO] plugin/erros: 2 2115717704248378980.1120568170924441806. HINFO: back-end inacessível: leia udp 10.224.0.3:38819->172.16.254.1:53: tempo limite de e/s
........

meu /etc/resolv.com
não tenho
nameserver 172.16.254.1 #este é meu dns
nameserver 8.8.8.8 #outro dns na net
eu corro

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

então a reconstrução do pod tem apenas um erro

[ERRO] plugin/erros: 2 10594135170717325.8545646296733374240. HINFO: back-end inacessível: nenhum host upstream

Não sei se isso é normal. pode ser

2、os coredns não podem encontrar meu serviço de API. erro é

kube-dns Falha ao listar *v1.Endpoints getsockopt: 10.96.0.1:6443 conexão api recusada

coredns reinicia de novo e de novo, finalmente CrashLoopBackOff

então eu tenho que executar coredns no nó mestre eu faço isso

kubectl editar deployment/coredns --namespace=kube-system
spec.template.spec
nodeSelector:
node-role.kubernetes.io/master: ""

não sei se isso é normal

finalmente dou meu env

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

Versão do docker: 18.09.3

[ root@k8smaster00 ~]# imagem docker ls -a
ID DA IMAGEM DA TAG DO REPOSITÓRIO TAMANHO CRIADO
k8s.gcr.io/kube-controller-manager v1.13.3 0482f6400933 6 semanas atrás 146 MB
k8s.gcr.io/kube-proxy v1.13.3 98db19758ad4 6 semanas atrás 80,3 MB
k8s.gcr.io/kube-apiserver v1.13.3 fe242e556a99 6 semanas atrás 181 MB
k8s.gcr.io/kube-scheduler v1.13.3 3a6f709e97a0 6 semanas atrás 79,6 MB
quay.io/coreos/flanel v0.11.0-amd64 ff281650a721 7 semanas atrás 52,6 MB
k8s.gcr.io/coredns 1.2.6 f59dcacceff4 4 meses atrás 40 MB
k8s.gcr.io/etcd 3.2.24 3cab8e1b9802 6 meses atrás 220 MB
k8s.gcr.io/pause 3.1 da86e6ba6ca1 15 meses atrás 742kB

kubenets é 1.13.3

Eu acho que isso é um bug Espere uma atualização oficial ou uma solução

tenho o mesmo problema...

@mengxifl , Esses erros são significativamente diferentes dos relatados e discutidos nesta edição.

[ERRO] plugin/erros: 2 2115717704248378980.1120568170924441806. HINFO: back-end inacessível: leia udp 10.224.0.3:57088->8.8.8.8:53: tempo limite de e/s
[ERRO] plugin/erros: 2 2115717704248378980.1120568170924441806. HINFO: back-end inacessível: leia udp 10.224.0.3:38819->172.16.254.1:53: tempo limite de e/s

Esses erros significam que o pod CoreDNS (e provavelmente todos os outros pods) não podem acessar seus servidores de nomes. Isso sugere um problema de rede em seu cluster para o mundo externo. Possivelmente configuração incorreta de flanela ou firewalls.

o coredns não pode encontrar meu serviço de api ...
então eu tenho que executar coredns no nó mestre

Isso também não é normal. Se entendi corretamente, você está dizendo que o CoreDNS pode entrar em contato com a API do nó mestre, mas não de outros nós. Isso sugeriria problemas de rede de serviço de pod entre nós em seu cluster - talvez um problema com configuração de flanela ou firewalls.

tenho o mesmo problema...

@mengxifl , Esses erros são significativamente diferentes dos relatados e discutidos nesta edição.

[ERRO] plugin/erros: 2 2115717704248378980.1120568170924441806. HINFO: back-end inacessível: leia udp 10.224.0.3:57088->8.8.8.8:53: tempo limite de e/s
[ERRO] plugin/erros: 2 2115717704248378980.1120568170924441806. HINFO: back-end inacessível: leia udp 10.224.0.3:38819->172.16.254.1:53: tempo limite de e/s

Esses erros significam que o pod CoreDNS (e provavelmente todos os outros pods) não podem acessar seus servidores de nomes. Isso sugere um problema de rede em seu cluster para o mundo externo. Possivelmente configuração incorreta de flanela ou firewalls.

o coredns não pode encontrar meu serviço de api ...
então eu tenho que executar coredns no nó mestre

Isso também não é normal. Se entendi corretamente, você está dizendo que o CoreDNS pode entrar em contato com a API do nó mestre, mas não de outros nós. Isso sugeriria problemas de rede de serviço de pod entre nós em seu cluster - talvez um problema com configuração de flanela ou firewalls.

Obrigado por sua resposta

talvez eu deva colocar meu arquivo yaml

eu uso
kubeadm init --config=config.yaml

meu conteúdo config.yaml é

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

meu fannel yaml é padrão

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

systemctl status firewalld
TODOS os nós dizem
A unidade firewalld.service não pôde ser encontrada.

cat /etc/sysconfig/iptables
TODOS os nós dizem
*filtro
:ENTRADA ACEITAR [0:0]
:ENVIAR ACEITAR [0:0]
:ACEITAR SAÍDA [0:0]
-A INPUT -p tcp -m tcp --dport 1:65535 -j ACEITAR
-A ENTRADA -m estado --estado RELACIONADO,ESTABELECIDO -j ACEITAR
-A ENTRADA -p icmp -j ACEITAR
-A ENTRADA -i lo -j ACEITAR
-A INPUT -p tcp -m estado --estado NOVO -m tcp --dport 22 -j ACEITAR
-A SAÍDA -p tcp -m tcp --sport 1:65535 -j ACEITAR
-A FORWARD -p tcp -m tcp --dport 1:65535 -j ACEITAR
-A FORWARD -p tcp -m tcp --sport 1:65535 -j ACEITAR
COMI

cat /etc/resolv.conf & ping bing.com
TODOS os nós dizem
[1] 6330
servidor de nomes 172.16.254.1
servidor de nomes 8.8.8.8
PING bing.com (13.107.21.200) 56(84) bytes de dados.
64 bytes de 13.107.21.200 (13.107.21.200): icmp_seq=2 ttl=111 time=149 ms

uname -rs
nó mestre dizer
Linux 4.20.10-1.el7.elrepo.x86_64

uname -rs
nó escravo dizer
Linux 4.4.176-1.el7.elrepo.x86_64

então eu não acho que o firewall tem problema mybe fannel? mas eu uso a configuração padrão. E talvez versão linux. não sei .

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

em todos os meus nós que funcionam para mim. obrigado