Kubeadm: CoreDNS nicht gestartet mit k8s 1.11 und weben (CentOS 7)

@kubernetes/sig-network-bugs

@carlosmkb , was ist deine Docker-Version?

Ich kann das kaum glauben, wir testen CentOS 7 auf unserer Seite ziemlich ausführlich.

Hast du die System- und Pod-Logs?

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

@dims , kann Sinn machen, ich werde es versuchen

@neolit123 und @timothysc

Docker-Version: docker-1.13.1-63.git94f4240.el7.centos.x86_64

coredns-Pods-Protokoll : standard_init_linux.go:178: exec user process caused "operation not permitted"
Systemprotokoll 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)"

Es wurden einige Instanzen derselben Fehler gefunden, die in der Vergangenheit in anderen Szenarien gemeldet wurden.
Versuchen Sie möglicherweise, „allowPrivilegeEscalation: false“ aus der CoreDNS-Bereitstellung zu entfernen, um zu sehen, ob das hilft.

Dasselbe Problem für mich. Ähnliches Setup CentOS 7.4.1708, Docker-Version 1.13.1, Build 94f4240/1.13.1 (kommt mit 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"

für alle Fälle befindet sich Selinux auf allen Knoten im Permissive-Modus.

Und ich verwende Calico (nicht weben als @carlosmkb).

[ root@faas-A01 ~]# kubectl logs --namespace=kube-system coredns-78fcdf6894-p4wbl
standard_init_linux.go:178: exec-Benutzerprozess verursachte "Operation nicht erlaubt"

Ah - Dies ist ein Fehler von kubectl beim Versuch, die Protokolle abzurufen, nicht den Inhalt der Protokolle ...

@chrisohaver das kubectl logs funktioniert mit anderen Kube-System-Pods

OK – haben Sie versucht, „allowPrivilegeEscalation: false“ aus der CoreDNS-Bereitstellung zu entfernen, um zu sehen, ob das hilft?

... zeigt ein kubectl describe des coredns-Pods irgendetwas Interessantes?

Dasselbe Problem für mich.
CentOS Linux-Version 7.5.1804 (Core)
Docker-Version 1.13.1, Build dded712/1.13.1
flanell als cni add-on

[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

Ich habe das gleiche Problem, wenn sich Selinux im permissiven Modus befindet. Wenn ich es in /etc/selinux/conf SELINUX=disabled deaktiviere und die Maschine neu starte, startet der Pod.

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

FYI, funktioniert bei mir auch mit deaktiviertem SELinux (nicht permissiv, aber _disabled_).
Docker-Version 1.13.1, Build 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

Wir haben dieses Problem auch, wir stellen Infrastruktur durch Automatisierung bereit, daher ist es nicht akzeptabel, dass ein Neustart erforderlich ist, um Selinux vollständig zu deaktivieren. Gibt es andere Problemumgehungen, warum wir darauf warten, dass dies behoben wird?

Versuchen Sie, „allowPrivilegeEscalation: false“ aus der CoreDNS-Bereitstellung zu entfernen, um zu sehen, ob das hilft.
Ein Update auf eine neuere Version von Docker (als 1.13) kann ebenfalls hilfreich sein.

Dasselbe Problem hier
Docker-Version 1.2.6
CentOS 7
wie @lareeth stellen wir auch die Kubernetes-Automatisierung bei der Verwendung von kubeadm bereit, und es ist nicht akzeptabel, dass ein Neustart erforderlich ist, um selinux vollständig zu deaktivieren.
@chrisohaver Der Versuch, einen Neustart zu erfordern, um Selinux vollständig zu deaktivieren, ist nicht akzeptabel. Es ist hilfreich. Danke !
Aber wie ich weiß, werden die coredns-Optionen nicht in der kubeadm-Konfiguration eingestellt
Gibt es keinen anderen Weg?

Versuchen Sie, „allowPrivilegeEscalation: false“ aus der CoreDNS-Bereitstellung zu entfernen, um zu sehen, ob das hilft.
Ein Update auf eine neuere Docker-Version (z. B. auf die von k8s empfohlene Version) kann ebenfalls hilfreich sein.

Ich habe überprüft, dass das Entfernen von „allowPrivilegeEscalation: false“ aus der coredns-Bereitstellung das Problem behebt (mit aktiviertem SE-Linux im Permissive-Modus).

Ich habe auch überprüft, dass ein Upgrade auf eine von Kubernetes empfohlene Docker-Version (Docker 17.03) das Problem behebt, wobei „allowPrivilegeEscalation: false“ in der coredns-Bereitstellung bestehen bleibt und SELinux im Permissive-Modus aktiviert ist.

Es scheint also eine Inkompatibilität zwischen alten Versionen von Docker und SELinux mit der Direktive allowPrivilegeEscalation zu geben, die anscheinend in späteren Versionen von Docker behoben wurde.

Es scheint 3 verschiedene Problemumgehungen zu geben:

• Aktualisieren Sie auf eine neuere Docker-Version, z. B. 17.03, die derzeit von k8s empfohlene Version
• Oder entfernen Sie allowPrivilegeEscalation=false aus der Pod-Spezifikation der Bereitstellung
• Oder deaktivieren Sie SELinux

@chrisohaver Ich habe das Problem gelöst, indem ich auf eine neuere Version von Docker 17.03 aktualisiert habe. Vielen Dank

Danke für die Untersuchung @chrisohave :100:

Danke, @chrisoaver !

Das hat funktioniert:

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

@chrisohaver
Denken Sie, wir sollten diesen Schritt im kubeadm-Leitfaden zur Fehlerbehebung für SELinux-Knoten in den folgenden Zeilen dokumentieren:

coredns -Pods haben den Status CrashLoopBackOff oder Error

Wenn Sie über Knoten verfügen, auf denen SELinux mit einer älteren Docker-Version ausgeführt wird, kann ein Szenario auftreten, in dem die coredns -Pods nicht gestartet werden. Um das zu lösen, können Sie eine der folgenden Optionen ausprobieren:

• Upgrade auf eine neuere Version von Docker – 17.03 funktioniert nachweislich.
• Deaktivieren Sie SELinux.
• Ändern Sie die coredns -Bereitstellung, um allowPrivilegeEscalation auf true :

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

WDYT? Bitte schlagen Sie Änderungen am Text vor, wenn Sie der Meinung sind, dass etwas verbessert werden kann.

Das ist gut. Wir sollten vielleicht erwähnen, dass es negative Auswirkungen auf die Sicherheit gibt, wenn SELinux deaktiviert oder die Einstellung allowPrivilegeEscalation geändert wird.

Die sicherste Lösung ist das Upgrade von Docker auf die von Kubernetes empfohlene Version (17.03).

@chrisohaver
verstanden, wird die Kopie abändern und dafür eine PR einreichen.

Es gibt auch eine Antwort dafür in Stackoverflow:
https://stackoverflow.com/questions/53075796/coredns-pods-have-crashloopbackoff-or-error-state

Dieser Fehler

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

wird verursacht, wenn CoreDNS eine Schleife in der Auflösungskonfiguration erkennt, und es ist das beabsichtigte Verhalten. Sie treffen auf dieses Problem:

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

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

Hackige Lösung: Deaktivieren Sie die CoreDNS-Loop-Erkennung

Bearbeiten Sie die CoreDNS-Konfigurationskarte:

kubectl -n kube-system edit configmap coredns

Entfernen oder kommentieren Sie die Zeile mit loop aus, speichern und beenden Sie.

Entfernen Sie dann die CoreDNS-Pods, damit neue mit neuer Konfiguration erstellt werden können:

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

Danach sollte alles in Ordnung sein.

Bevorzugte Lösung: Entfernen Sie die Schleife in der DNS-Konfiguration

Überprüfen Sie zunächst, ob Sie systemd-resolved verwenden. Wenn Sie Ubuntu 18.04 ausführen, ist dies wahrscheinlich der Fall.

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

Wenn dies der Fall ist, prüfen Sie, welche resolv.conf -Datei Ihr Cluster als Referenz verwendet:

ps auxww | grep kubelet

Möglicherweise sehen Sie eine Zeile wie:

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

Der wichtige Teil ist --resolv-conf - wir finden heraus, ob systemd resolv.conf verwendet wird oder nicht.

Wenn es sich um resolv.conf von systemd handelt, gehen Sie wie folgt vor:

Überprüfen Sie den Inhalt von /run/systemd/resolve/resolv.conf , um zu sehen, ob es einen Eintrag wie diesen gibt:

nameserver 127.0.0.1

Wenn es 127.0.0.1 gibt, ist es derjenige, der die Schleife verursacht.

Um es loszuwerden, sollten Sie diese Datei nicht bearbeiten, sondern andere Stellen überprüfen, damit sie richtig generiert wird.

Überprüfen Sie alle Dateien unter /etc/systemd/network und finden Sie einen Eintrag wie

DNS=127.0.0.1

diesen Datensatz löschen. Überprüfen Sie auch /etc/systemd/resolved.conf und tun Sie dasselbe, falls erforderlich. Stellen Sie sicher, dass Sie mindestens einen oder zwei DNS-Server konfiguriert haben, wie z

DNS=1.1.1.1 1.0.0.1

Starten Sie danach die systemd-Dienste neu, damit Ihre Änderungen wirksam werden:
systemctl Neustart systemd-networkd systemd-resolved

Stellen Sie danach sicher, dass DNS=127.0.0.1 nicht mehr in der Datei resolv.conf enthalten ist:

cat /run/systemd/resolve/resolv.conf

Lösen Sie schließlich die Neuerstellung der DNS-Pods aus

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

Zusammenfassung: Die Lösung besteht darin, etwas, das wie eine DNS-Lookup-Schleife aussieht, aus der DNS-Konfiguration des Hosts zu entfernen. Die Schritte variieren zwischen verschiedenen resolv.conf-Managern/Implementierungen.

Danke. Es wird auch in der Readme -Datei des CoreDNS-Loop-Plugins behandelt ...

Ich habe das gleiche Problem und noch ein weiteres Problem
1. Ich kann DNS nicht finden. der Fehler ist
[FEHLER] Plugin/Fehler: 2 2115717704248378980.1120568170924441806. HINFO: Backend nicht erreichbar: udp 10.224.0.3:57088 lesen -> 8.8.8.8:53: I/O-Timeout
[FEHLER] Plugin/Fehler: 2 2115717704248378980.1120568170924441806. HINFO: Backend nicht erreichbar: udp 10.224.0.3:38819 lesen -> 172.16.254.1:53: I/O-Timeout
........

meine /etc/resolv.com
nicht haben
Nameserver 172.16.254.1 #das ist mein DNS
Nameserver 8.8.8.8 #ein weiterer DNS im Netz
ich renne

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

dann hat der Pod-Neuaufbau nur einen Fehler

[FEHLER] Plugin/Fehler: 2 10594135170717325.8545646296733374240. HINFO: Backend nicht erreichbar: kein Upstream-Host

Ich weiß nicht, ob das normal ist. vielleicht

2、Cordns kann meinen API-Dienst nicht finden. Fehler ist

kube-dns Fehler beim Auflisten von *v1.Endpoints getsockopt: 10.96.0.1:6443 API-Verbindung abgelehnt

coredns starten immer wieder neu, zuletzt wird CrashLoopBackOff

Also muss ich coredns auf dem Master-Knoten ausführen, den ich mache

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

Ich weiß nicht, ob das normal ist

gib endlich meinen env

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

Docker-Version: 18.09.3

[ root@k8smaster00 ~]# Docker-Image ls -a
REPOSITORY-TAG-BILD-ID ERSTELLTE GRÖSSE
k8s.gcr.io/kube-controller-manager v1.13.3 0482f6400933 vor 6 Wochen 146 MB
k8s.gcr.io/kube-proxy v1.13.3 98db19758ad4 vor 6 Wochen 80,3 MB
k8s.gcr.io/kube-apiserver v1.13.3 fe242e556a99 vor 6 Wochen 181 MB
k8s.gcr.io/kube-scheduler v1.13.3 3a6f709e97a0 vor 6 Wochen 79,6 MB
quay.io/coreos/flannel v0.11.0-amd64 ff281650a721 vor 7 Wochen 52,6 MB
k8s.gcr.io/coredns 1.2.6 f59dcacceff4 vor 4 Monaten 40MB
k8s.gcr.io/etcd 3.2.24 3cab8e1b9802 vor 6 Monaten 220 MB
k8s.gcr.io/pause 3.1 da86e6ba6ca1 vor 15 Monaten 742kB

kubenets ist 1.13.3

Ich denke, das ist ein Fehler. Erwarten Sie ein offizielles Update oder eine Lösung

Ich habe dasselbe Problem ...

@mengxifl , Diese Fehler unterscheiden sich erheblich von denen, die in dieser Ausgabe gemeldet und diskutiert werden.

[FEHLER] Plugin/Fehler: 2 2115717704248378980.1120568170924441806. HINFO: Backend nicht erreichbar: udp 10.224.0.3:57088 lesen -> 8.8.8.8:53: I/O-Timeout
[FEHLER] Plugin/Fehler: 2 2115717704248378980.1120568170924441806. HINFO: Backend nicht erreichbar: udp 10.224.0.3:38819 lesen -> 172.16.254.1:53: I/O-Timeout

Diese Fehler bedeuten, dass der CoreDNS-Pod (und wahrscheinlich alle anderen Pods) Ihre Nameserver nicht erreichen können. Dies deutet nach außen auf ein Netzwerkproblem in Ihrem Cluster hin. Möglicherweise Flanell-Fehlkonfiguration oder Firewalls.

Die Cordns können meinen API-Dienst nicht finden ...
Also muss ich coredns auf dem Master-Knoten ausführen

Auch das ist nicht normal. Wenn ich Sie richtig verstehe, sagen Sie, dass CoreDNS die API vom Masterknoten aus kontaktieren kann, aber nicht von anderen Knoten. Dies würde auf Pod-to-Service-Netzwerkprobleme zwischen Knoten innerhalb Ihres Clusters hindeuten – möglicherweise ein Problem mit der Flanell-Konfiguration oder Firewalls.

Ich habe dasselbe Problem ...

@mengxifl , Diese Fehler unterscheiden sich erheblich von denen, die in dieser Ausgabe gemeldet und diskutiert werden.

[FEHLER] Plugin/Fehler: 2 2115717704248378980.1120568170924441806. HINFO: Backend nicht erreichbar: udp 10.224.0.3:57088 lesen -> 8.8.8.8:53: I/O-Timeout
[FEHLER] Plugin/Fehler: 2 2115717704248378980.1120568170924441806. HINFO: Backend nicht erreichbar: udp 10.224.0.3:38819 lesen -> 172.16.254.1:53: I/O-Timeout

Diese Fehler bedeuten, dass der CoreDNS-Pod (und wahrscheinlich alle anderen Pods) Ihre Nameserver nicht erreichen können. Dies deutet nach außen auf ein Netzwerkproblem in Ihrem Cluster hin. Möglicherweise Flanell-Fehlkonfiguration oder Firewalls.

Die Cordns können meinen API-Dienst nicht finden ...
Also muss ich coredns auf dem Master-Knoten ausführen

Auch das ist nicht normal. Wenn ich Sie richtig verstehe, sagen Sie, dass CoreDNS die API vom Masterknoten aus kontaktieren kann, aber nicht von anderen Knoten. Dies würde auf Pod-to-Service-Netzwerkprobleme zwischen Knoten innerhalb Ihres Clusters hindeuten – möglicherweise ein Problem mit der Flanell-Konfiguration oder Firewalls.

Danke für Ihre Antwort

Vielleicht sollte ich meine yaml-Datei hochladen

ich benutze
kubeadm init --config=config.yaml

mein config.yaml-Inhalt ist

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

Mein Fannel Yaml ist Standard

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

systemctl status firewalld
ALLE Knoten sagen
Einheit firewalld.service konnte nicht gefunden werden.

cat /etc/sysconfig/iptables
ALLE Knoten sagen
*Filter
:EINGABE AKZEPTIEREN [0:0]
:WEITER AKZEPTIEREN [0:0]
:AUSGABE AKZEPTIEREN [0:0]
-A EINGABE -p tcp -m tcp --dport 1:65535 -j AKZEPTIEREN
-A EINGABE -m Zustand --Zustand BEZOGEN, HERGESTELLT -j AKZEPTIEREN
-A EINGABE -p icmp -j AKZEPTIEREN
-A EINGABE -i lo -j AKZEPTIEREN
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A AUSGABE -p tcp -m tcp --sport 1:65535 -j AKZEPTIEREN
-A FORWARD -p tcp -m tcp --dport 1:65535 -j ACCEPT
-A WEITER -p tcp -m tcp --sport 1:65535 -j AKZEPTIEREN
KOMM

cat /etc/resolv.conf & ping bing.com
ALLE Knoten sagen
[1] 6330
Nameserver 172.16.254.1
Nameserver 8.8.8.8
PING bing.com (13.107.21.200) 56 (84) Byte Daten.
64 Bytes von 13.107.21.200 (13.107.21.200): icmp_seq=2 ttl=111 time=149 ms

uname -rs
Masternode sagen
Linux 4.20.10-1.el7.elrepo.x86_64

uname -rs
Slave-Knoten sagen
Linux 4.4.176-1.el7.elrepo.x86_64

also glaube ich nicht, dass die Firewall Probleme mit mybe fannel hat? aber ich verwende die Standardkonfiguration. Und vielleicht Linux-Version. ich weiß nicht .

Okay ich laufe
/sbin/iptables -t nat -I POSTROUTING -s 10.224.0.0/16 -j MASQUERADE

auf allen meinen Knoten, die für mich funktionieren. Danke