Kubeadm: CoreDNS n'a pas démarré avec k8s 1.11 et weave (CentOS 7)

@kubernetes/sig-network-bugs

@carlosmkb , quelle est votre version de Docker ?

Je trouve cela difficile à croire, nous testons assez largement CentOS 7 de notre côté.

Avez-vous les journaux du système et du pod ?

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

@dims , peut avoir du sens, je vais essayer

@neolit123 et @timothysc

version du docker : docker-1.13.1-63.git94f4240.el7.centos.x86_64

journal des pods coredns : standard_init_linux.go:178: exec user process caused "operation not permitted"
journal système 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)"

Trouvé quelques instances des mêmes erreurs signalées dans d'autres scénarios dans le passé.
Essayez peut-être de supprimer "allowPrivilegeEscalation : false" du déploiement CoreDNS pour voir si cela aide.

Même problème pour moi. Configuration similaire CentOS 7.4.1708, Docker version 1.13.1, build 94f4240/1.13.1 (fourni avec 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"

juste au cas où, selinux est en mode permissif sur tous les nœuds.

Et j'utilise Calico (pas de tissage comme @carlosmkb).

[ root@faas-A01 ~]# kubectl logs --namespace=kube-system coredns-78fcdf6894-p4wbl
standard_init_linux.go:178 : le processus utilisateur exec a provoqué "l'opération n'est pas autorisée"

Ah - Il s'agit d'une erreur de kubectl lors de la tentative d'obtention des journaux, pas du contenu des journaux...

@chrisohaver le kubectl logs fonctionne avec un autre pod du système kube

OK - avez-vous essayé de supprimer "allowPrivilegeEscalation : false" du déploiement CoreDNS pour voir si cela aide ?

... est-ce qu'un kubectl describe du pod coredns montre quelque chose d'intéressant ?

Même problème pour moi.
CentOS Linux version 7.5.1804 (Core)
Docker version 1.13.1, build dded712/1.13.1
flanelle comme complément 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

J'ai le même problème lorsque selinux est en mode permissif. Lorsque je le désactive dans /etc/selinux/conf SELINUX=disabled et que je redémarre la machine, le pod démarre.

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

Pour votre information, fonctionne également pour moi avec SELinux désactivé (non permissif, mais _disabled_).
Docker version 1.13.1, build dded712/1.13.1
Cent OS 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

Nous rencontrons également ce problème, nous provisionnons l'infrastructure via l'automatisation, il n'est donc pas acceptable d'exiger un redémarrage pour désactiver complètement selinux. Existe-t-il d'autres solutions de contournement pour lesquelles nous attendons que cela soit corrigé ?

Essayez de supprimer "allowPrivilegeEscalation : false" du déploiement CoreDNS pour voir si cela vous aide.
La mise à jour vers une version plus récente de docker (que la 1.13) peut également aider.

Même problème ici
Docker version 1.2.6
Cent OS 7
comme @lareeth, nous fournissons également l'automatisation de kubernetes lors de l'utilisation de kubeadm, et exiger également un redémarrage pour désactiver complètement selinux n'est pas acceptable.
@chrisohaver essayer d'exiger un redémarrage pour désactiver complètement selinux n'est pas acceptable. il utilise utile. Merci !
Mais comme je sais que les options coredns ne sont pas définies dans la configuration de kubeadm
N'y a-t-il pas d'autre moyen ?

Essayez de supprimer "allowPrivilegeEscalation : false" du déploiement CoreDNS pour voir si cela vous aide.
La mise à jour vers une version plus récente de docker (par exemple vers la version recommandée par k8s) peut également aider.

J'ai vérifié que la suppression de "allowPrivilegeEscalation: false" du déploiement coredns résout le problème (avec SE linux activé en mode permissif).

J'ai également vérifié que la mise à niveau vers une version de docker recommandée par Kubernetes (docker 17.03) résout le problème, avec "allowPrivilegeEscalation : false" laissé en place dans le déploiement coredns, et SELinux activé en mode permissif.

Ainsi, il semble qu'il y ait une incompatibilité entre les anciennes versions de docker et SELinux avec la directive allowPrivilegeEscalation qui a apparemment été résolue dans les versions ultérieures de docker.

Il semble y avoir 3 solutions de contournement différentes :

• Mettez à niveau vers une version plus récente de docker, par exemple 17.03, la version actuellement recommandée par k8s
• Ou supprimez allowPrivilegeEscalation=false de la spécification de pod du déploiement
• Ou désactiver SELinux

@chrisohaver J'ai résolu le problème en passant à la nouvelle version de docker 17.03. THX

merci pour l'enquête @chrisohaver :100:

Merci @chrisohaver !

Cela a fonctionné :

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

@chrisohaver
pensez-vous que nous devrions documenter cette étape dans le guide de dépannage kubeadm pour les nœuds SELinux dans les lignes de :

Les pods coredns ont l'état CrashLoopBackOff ou Error

Si vous avez des nœuds qui exécutent SELinux avec une ancienne version de Docker, vous pouvez rencontrer un scénario dans lequel les pods coredns ne démarrent pas. Pour résoudre ce problème, vous pouvez essayer l'une des options suivantes :

• La mise à niveau vers une version plus récente de Docker - 17.03 est confirmée pour fonctionner.
• Désactivez SELinux.
• Modifiez le déploiement de coredns pour définir allowPrivilegeEscalation sur true :

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

WDYT ? s'il vous plaît suggérer des amendements au texte si vous pensez que quelque chose peut être amélioré.

C'est très bien. Nous devrions peut-être mentionner qu'il y a des implications de sécurité négatives lors de la désactivation de SELinux ou de la modification du paramètre allowPrivilegeEscalation.

La solution la plus sécurisée consiste à mettre à niveau Docker vers la version recommandée par Kubernetes (17.03)

@chrisohaver
compris, modifiera la copie et soumettra un PR pour cela.

Il y a aussi une réponse à cela dans stackoverflow :
https://stackoverflow.com/questions/53075796/coredns-pods-have-crashloopbackoff-or-error-state

Cette erreur

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

est provoqué lorsque CoreDNS détecte une boucle dans la configuration de résolution, et c'est le comportement prévu. Vous rencontrez ce problème :

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

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

Solution Hacky : Désactiver la détection de boucle CoreDNS

Modifiez le mappage de configuration CoreDNS :

kubectl -n kube-system edit configmap coredns

Supprimez ou commentez la ligne avec loop , enregistrez et quittez.

Supprimez ensuite les pods CoreDNS, afin que de nouveaux puissent être créés avec une nouvelle configuration :

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

Tout devrait bien se passer ensuite.

Solution préférée : supprimer la boucle dans la configuration DNS

Tout d'abord, vérifiez si vous utilisez systemd-resolved . Si vous utilisez Ubuntu 18.04, c'est probablement le cas.

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

Si c'est le cas, vérifiez quel fichier resolv.conf votre cluster utilise comme référence :

ps auxww | grep kubelet

Vous pourriez voir une ligne comme :

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

La partie importante est --resolv-conf - nous déterminons si systemd resolv.conf est utilisé ou non.

S'il s'agit du resolv.conf de systemd , procédez comme suit :

Vérifiez le contenu de /run/systemd/resolve/resolv.conf pour voir s'il existe un enregistrement comme :

nameserver 127.0.0.1

S'il y a 127.0.0.1 , c'est celui qui provoque la boucle.

Pour vous en débarrasser, vous ne devez pas modifier ce fichier, mais vérifier d'autres endroits pour qu'il soit correctement généré.

Vérifiez tous les fichiers sous /etc/systemd/network et si vous trouvez un enregistrement comme

DNS=127.0.0.1

supprimer cet enregistrement. Vérifiez également /etc/systemd/resolved.conf et faites de même si nécessaire. Assurez-vous d'avoir au moins un ou deux serveurs DNS configurés, tels que

DNS=1.1.1.1 1.0.0.1

Après avoir fait tout cela, redémarrez les services systemd pour appliquer vos modifications :
systemctl redémarrer systemd-networkd systemd-résolu

Ensuite, vérifiez que DNS=127.0.0.1 n'est plus dans le fichier resolv.conf :

cat /run/systemd/resolve/resolv.conf

Enfin, déclenchez la recréation des pods DNS

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

Résumé : La solution consiste à se débarrasser de ce qui ressemble à une boucle de recherche DNS à partir de la configuration DNS de l'hôte. Les étapes varient entre les différents gestionnaires/implémentations de resolv.conf.

Merci. Il est également couvert dans le fichier readme du plug-in de boucle CoreDNS ...

J'ai le même problème et un autre problème
1, signifie que je ne peux pas trouver de DNS. l'erreur est
[ERREUR] plugin/erreurs : 2 2115717704248378980.1120568170924441806. HINFO : backend inaccessible : lecture udp 10.224.0.3:57088->8.8.8.8:53 : expiration du délai d'e/s
[ERREUR] plugin/erreurs : 2 2115717704248378980.1120568170924441806. HINFO : backend inaccessible : lecture udp 10.224.0.3:38819->172.16.254.1:53 : expiration du délai d'e/s
........

mon /etc/resolv.com
n'ont pas
serveur de noms 172.16.254.1 #c'est mon DNS
serveur de noms 8.8.8.8 #un autre DNS dans le réseau
je cours

kubectl -n kube-system obtenir le déploiement coredns -o yaml | \
sed 's/allowPrivilegeEscalation : faux/allowPrivilegeEscalation : vrai/g' | \
kubectl appliquer -f -

alors la reconstruction du pod n'a qu'une seule erreur

[ERREUR] plugin/erreurs : 2 10594135170717325.8545646296733374240. HINFO : backend inaccessible : pas d'hôte en amont

Je ne sais pas si c'est normal. peut être

2, les coredns ne peuvent pas trouver mon service api. l'erreur est

kube-dns Échec de la liste *v1.Endpoints getsockopt : 10.96.0.1:6443 connexion api refusée

coredns redémarre encore et encore, enfin CrashLoopBackOff

donc je dois exécuter coredns sur le nœud maître je le fais

kubectl modifier déploiement/coredns --namespace=kube-system
spec.template.spec
nodeSelector :
node-role.kubernetes.io/master : ""

je ne sais pas si c'est normal

donne enfin mon env

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

Docker Version : 18.09.3

[ root@k8smaster00 ~]# image docker ls -a
ID D'IMAGE D'ÉTIQUETTE DE RÉFÉRENTIEL TAILLE CRÉÉE
k8s.gcr.io/kube-controller-manager v1.13.3 0482f6400933 il y a 6 semaines 146MB
k8s.gcr.io/kube-proxy v1.13.3 98db19758ad4 il y a 6 semaines 80.3MB
k8s.gcr.io/kube-apiserver v1.13.3 fe242e556a99 il y a 6 semaines 181 Mo
k8s.gcr.io/kube-scheduler v1.13.3 3a6f709e97a0 il y a 6 semaines 79.6MB
quay.io/coreos/flannel v0.11.0-amd64 ff281650a721 il y a 7 semaines 52.6MB
k8s.gcr.io/coredns 1.2.6 f59dcacceff4 il y a 4 mois 40MB
k8s.gcr.io/etcd 3.2.24 3cab8e1b9802 il y a 6 mois 220MB
k8s.gcr.io/pause 3.1 da86e6ba6ca1 il y a 15 mois 742kB

kubenets est 1.13.3

Je pense que c'est un bogue Attendez-vous à une mise à jour officielle ou à une solution

J'ai le même problème...

@mengxifl , ces erreurs sont très différentes de celles signalées et discutées dans ce numéro.

[ERREUR] plugin/erreurs : 2 2115717704248378980.1120568170924441806. HINFO : backend inaccessible : lecture udp 10.224.0.3:57088->8.8.8.8:53 : expiration du délai d'e/s
[ERREUR] plugin/erreurs : 2 2115717704248378980.1120568170924441806. HINFO : backend inaccessible : lecture udp 10.224.0.3:38819->172.16.254.1:53 : expiration du délai d'e/s

Ces erreurs signifient que le pod CoreDNS (et probablement tous les autres pods) ne peut pas atteindre vos serveurs de noms. Cela suggère un problème de mise en réseau dans votre cluster avec le monde extérieur. Peut-être une mauvaise configuration de la flanelle ou des pare-feu.

les coredns ne peuvent pas trouver mon service api ...
donc je dois exécuter coredns sur le nœud maître

Ce n'est pas non plus normal. Si je vous comprends bien, vous dites que CoreDNS peut contacter l'API à partir du nœud maître mais pas d'autres nœuds. Cela suggérerait des problèmes de mise en réseau de pod à service entre les nœuds de votre cluster - peut-être un problème de configuration Flannel ou de pare-feu.

J'ai le même problème...

@mengxifl , ces erreurs sont très différentes de celles signalées et discutées dans ce numéro.

[ERREUR] plugin/erreurs : 2 2115717704248378980.1120568170924441806. HINFO : backend inaccessible : lecture udp 10.224.0.3:57088->8.8.8.8:53 : expiration du délai d'e/s
[ERREUR] plugin/erreurs : 2 2115717704248378980.1120568170924441806. HINFO : backend inaccessible : lecture udp 10.224.0.3:38819->172.16.254.1:53 : expiration du délai d'e/s

Ces erreurs signifient que le pod CoreDNS (et probablement tous les autres pods) ne peut pas atteindre vos serveurs de noms. Cela suggère un problème de mise en réseau dans votre cluster avec le monde extérieur. Peut-être une mauvaise configuration de la flanelle ou des pare-feu.

les coredns ne peuvent pas trouver mon service api ...
donc je dois exécuter coredns sur le nœud maître

Ce n'est pas non plus normal. Si je vous comprends bien, vous dites que CoreDNS peut contacter l'API à partir du nœud maître mais pas d'autres nœuds. Cela suggérerait des problèmes de mise en réseau de pod à service entre les nœuds de votre cluster - peut-être un problème de configuration Flannel ou de pare-feu.

Merci pour votre réponse

peut-être que je devrais mettre mon fichier yaml

j'utilise
kubeadm init --config=config.yaml

mon contenu config.yaml est

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

mon fannel yaml est par défaut

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

systemctl status firewalld
TOUS les nœuds disent
L'unité firewalld.service est introuvable.

cat /etc/sysconfig/iptables
TOUS les nœuds disent
*filtre
:ENTRÉE ACCEPTÉE [0:0]
:AVANCE ACCEPTER [0:0]
:SORTIE ACCEPTER [0:0]
-A ENTRÉE -p tcp -m tcp --dport 1:65535 -j ACCEPTER
-A ENTRÉE -m état --état CONNEXE, ÉTABLI -j ACCEPTER
-A ENTRÉE -p icmp -j ACCEPTER
-A ENTRÉE -i lo -j ACCEPTER
-A ENTRÉE -p tcp -m état --état NOUVEAU -m tcp --dport 22 -j ACCEPTER
-A SORTIE -p tcp -m tcp --sport 1:65535 -j ACCEPTER
-A AVANT -p tcp -m tcp --dport 1:65535 -j ACCEPTER
-A AVANT -p tcp -m tcp --sport 1:65535 -j ACCEPTER
COMMI

cat /etc/resolv.conf & ping bing.com
TOUS les nœuds disent
[1] 6330
serveur de noms 172.16.254.1
serveur de noms 8.8.8.8
PING bing.com (13.107.21.200) 56(84) octets de données.
64 octets à partir de 13.107.21.200 (13.107.21.200) : icmp_seq=2 ttl=111 time=149 ms

uname -rs
nœud maître dire
Linux 4.20.10-1.el7.elrepo.x86_64

uname -rs
nœud esclave dire
Linux 4.4.176-1.el7.elrepo.x86_64

donc je ne pense pas que le pare-feu ait un problème mybe fannel? mais j'utilise la configuration par défaut. Et peut-être la version Linux. je ne sais pas .

bon je cours
/sbin/iptables -t nat -I POSTROUTING -s 10.224.0.0/16 -j MASQUERADE

sur tous mes nœuds qui fonctionnent pour moi. Merci