Kubeadm: CoreDNS k8s 1.11 और बुनाई के साथ प्रारंभ नहीं हुआ (CentOS 7)

@ कुबेरनेट्स/सिग-नेटवर्क-बग

@carlosmkb , आपका डॉकर संस्करण क्या है?

मुझे इस पर विश्वास करना कठिन लगता है, हम अपनी तरफ से CentOS 7 का व्यापक रूप से परीक्षण करते हैं।

क्या आपके पास सिस्टम और पॉड लॉग हैं?

यह वाला? https://stackoverflow.com/questions/44127247/does-Anyone-know-a-workAround-FOR-NO-NEW-PRIVILEGES-BLOCKING-SELINUX-TRANSITIONS

@dims , समझ में आ सकता है, मैं कोशिश करूँगा

@neolit123 और @timothysc

डोकर संस्करण: docker-1.13.1-63.git94f4240.el7.centos.x86_64

coredns पॉड लॉग : standard_init_linux.go:178: exec user process caused "operation not permitted"
सिस्टम लॉग 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)"

अतीत में अन्य परिदृश्यों में रिपोर्ट की गई समान त्रुटियों के कुछ उदाहरण मिले।
CoreDNS परिनियोजन से "allowPrivilegeEscalation: false" को हटाने का प्रयास कर सकते हैं यह देखने के लिए कि क्या इससे मदद मिलती है।

मेरे लिए वही मुद्दा। समान सेटअप CentOS 7.4.1708, Docker संस्करण 1.13.1, बिल्ड 94f4240/1.13.1 (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"

बस मामले में, सेलिनक्स सभी नोड्स पर अनुमेय मोड में है।

मैं कैलिको का उपयोग कर रहा हूं (@carlosmkb के रूप में बुनाई नहीं)।

[ रूट@faas-A01 ~]# kubectl logs --namespace=kube-system coredns-78fcdf6894-p4wbl
Standard_init_linux.go:178: निष्पादन उपयोगकर्ता प्रक्रिया के कारण "ऑपरेशन की अनुमति नहीं है"

आह - लॉग प्राप्त करने का प्रयास करते समय यह Kubectl से एक त्रुटि है, लॉग की सामग्री नहीं ...

@chrisohaver kubectl logs दूसरे क्यूब-सिस्टम पॉड्स के साथ काम करता है

ठीक है - क्या आपने CoreDNS परिनियोजन से "allowPrivilegeEscalation: false" को हटाने का प्रयास किया है यह देखने के लिए कि क्या इससे मदद मिलती है?

... क्या कोर्डन्स पॉड का kubectl describe कुछ दिलचस्प दिखाता है?

मेरे लिए वही मुद्दा।
CentOS Linux रिलीज़ 7.5.1804 (कोर)
डॉकर संस्करण 1.13.1, dded712/1.13.1 . का निर्माण करें
सीएनआई ऐड-ऑन के रूप में फलालैन

[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

मेरे पास एक ही समस्या है जब सेलिनक्स पर्समिसिव मोड में है। जब मैं इसे /etc/selinux/conf SELINUX=disabled और रीबूट मशीन में अक्षम करता हूं तो पॉड शुरू हो जाता है।

रेडहैट 7.4, कर्नेल 3.10.0-693.11.6.el7.x86_64
docker-1.13.1-68.gitdded712.el7.x86_64

एफवाईआई, मेरे लिए SELinux अक्षम के साथ भी काम करता है (अनुमेय नहीं, लेकिन _disabled_)।
डॉकर संस्करण 1.13.1, dded712/1.13.1 . का निर्माण करें
सेंटोस 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

हम भी इस समस्या का सामना कर रहे हैं, हम स्वचालन के माध्यम से बुनियादी ढांचे का प्रावधान करते हैं, इसलिए सेलिनक्स को पूरी तरह से अक्षम करने के लिए पुनरारंभ की आवश्यकता स्वीकार्य नहीं है। क्या कोई अन्य समाधान है कि हम इसके ठीक होने की प्रतीक्षा क्यों करते हैं?

यह देखने के लिए कि क्या यह मदद करता है, CoreDNS परिनियोजन से "allowPrivilegeEscalation: false" को हटाने का प्रयास करें।
डॉकर के नवीनतम संस्करण (1.13 से अधिक) में अपडेट करने से भी मदद मिल सकती है।

यहाँ एक ही मुद्दा
डॉकर संस्करण 1.2.6
सेंटोस 7
@lareeth की तरह हम भी Kubeadm के उपयोग पर Kubernetes स्वचालन का प्रावधान करते हैं, और selinux को पूरी तरह से अक्षम करने के लिए पुनरारंभ की आवश्यकता भी स्वीकार्य नहीं है।
@chrisohaver सेलिनक्स को पूरी तरह से अक्षम करने के लिए पुनरारंभ करने की आवश्यकता है, स्वीकार्य नहीं है। यह मददगार का उपयोग करता है। धन्यवाद !
लेकिन जैसा कि मुझे पता है कि कुबेदम कॉन्फ़िगरेशन में कोर्डन विकल्प सेट नहीं हो रहे हैं
क्या कोई दूसरा रास्ता नहीं है?

यह देखने के लिए कि क्या यह मदद करता है, CoreDNS परिनियोजन से "allowPrivilegeEscalation: false" को हटाने का प्रयास करें।
डॉकर के अधिक हाल के संस्करण (उदाहरण के लिए k8s द्वारा अनुशंसित संस्करण) में अपडेट करने से भी मदद मिल सकती है।

मैंने सत्यापित किया है कि कोर्डन्स परिनियोजन से "allowPrivilegeEscalation: false" को हटाने से समस्या हल हो जाती है (SE linux अनुमेय मोड में सक्षम होने के साथ)।

मैंने यह भी सत्यापित किया कि कुबेरनेट्स (डॉकर 17.03) द्वारा अनुशंसित डॉकटर के एक संस्करण में अपग्रेड करने से समस्या का समाधान हो जाता है, जिसमें "allowPrivilegeEscalation: false" कोर्डन्स परिनियोजन में छोड़ दिया जाता है, और SELinux अनुमेय मोड में सक्षम होता है।

इसलिए, ऐसा प्रतीत होता है कि docker और SELinux के पुराने संस्करणों के बीच allowPrivilegeEscalation निर्देश के साथ असंगति है जिसे स्पष्ट रूप से docker के बाद के संस्करणों में हल किया गया है।

3 अलग-अलग कामकाज प्रतीत होते हैं:

• डॉकर के नए संस्करण में अपग्रेड करें, उदाहरण के लिए 17.03, वर्तमान में k8s . द्वारा अनुशंसित संस्करण
• या परिनियोजन के पॉड स्पेक से allowPrivilegeEscalation=false हटाएं
• या SELinux अक्षम करें

@chrisohaver मैंने डॉकर 17.03 के नए संस्करण में अपग्रेड करके इस मुद्दे को हल किया है। धन्यवाद

जांच के लिए धन्यवाद @chrisohaver : 100:

धन्यवाद, @chrisohaver !

यह काम किया:

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

@ क्रिसोहावर
क्या आपको लगता है कि हमें SELinux नोड्स के लिए kubeadm समस्या निवारण मार्गदर्शिका में इस चरण का दस्तावेजीकरण करना चाहिए:

coredns पॉड्स में CrashLoopBackOff या Error स्थिति होती है

यदि आपके पास Docker के पुराने संस्करण के साथ SELinux चलाने वाले नोड हैं, तो आप एक ऐसे परिदृश्य का अनुभव कर सकते हैं जहाँ coredns पॉड शुरू नहीं हो रहे हैं। इसे हल करने के लिए आप निम्न विकल्पों में से किसी एक को आजमा सकते हैं:

• डॉकर के एक नए संस्करण में अपग्रेड करें - 17.03 काम करने की पुष्टि की है।
• SELinux को अक्षम करें।
• coredns परिनियोजन को allowPrivilegeEscalation से true पर सेट करने के लिए संशोधित करें:

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

डब्ल्यूडीवाईटी? कृपया सुझाव दें कि पाठ में संशोधन करें यदि आपको लगता है कि कुछ सुधार किया जा सकता है।

कोई बात नहीं। हमें शायद यह उल्लेख करना चाहिए कि SELinux को अक्षम करते समय, या allowPrivilegeEscalation सेटिंग को बदलते समय नकारात्मक सुरक्षा प्रभाव पड़ते हैं।

सबसे सुरक्षित समाधान डॉकर को कुबेरनेट्स द्वारा अनुशंसित संस्करण में अपग्रेड करना है (17.03)

@ क्रिसोहावर
समझा जाएगा, कॉपी में संशोधन करेगा और इसके लिए एक पीआर जमा करेगा।

इसके लिए स्टैक ओवरफ्लो में भी उत्तर है:
https://stackoverflow.com/questions/53075796/coredns-pods-have-crashloopbackoff-or-error-state

यह गलती

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

ऐसा तब होता है जब CoreDNS रिज़ॉल्यूशन कॉन्फ़िगरेशन में लूप का पता लगाता है, और यह इच्छित व्यवहार है। आप इस मुद्दे को मार रहे हैं:

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

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

हैकी समाधान: CoreDNS लूप डिटेक्शन को अक्षम करें

CoreDNS कॉन्फिगमैप संपादित करें:

kubectl -n kube-system edit configmap coredns

loop के साथ लाइन को हटाएं या टिप्पणी करें, सहेजें और बाहर निकलें।

फिर CoreDNS पॉड्स को हटा दें, ताकि नए कॉन्फिगर के साथ नए बनाए जा सकें:

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

उसके बाद सब ठीक होना चाहिए।

पसंदीदा समाधान: DNS कॉन्फ़िगरेशन में लूप निकालें

सबसे पहले, जांचें कि क्या आप systemd-resolved का उपयोग कर रहे हैं। यदि आप Ubuntu 18.04 चला रहे हैं, तो शायद ऐसा ही है।

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

यदि ऐसा है, तो जांचें कि आपका क्लस्टर किस resolv.conf फ़ाइल को संदर्भ के रूप में उपयोग कर रहा है:

ps auxww | grep kubelet

आप की तरह एक लाइन देख सकते हैं:

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

महत्वपूर्ण हिस्सा --resolv-conf है - हम यह पता लगाते हैं कि systemd resolv.conf का उपयोग किया गया है या नहीं।

यदि यह resolv.conf का systemd है, तो निम्न कार्य करें:

यह देखने के लिए /run/systemd/resolve/resolv.conf की सामग्री जांचें कि क्या ऐसा कोई रिकॉर्ड है:

nameserver 127.0.0.1

यदि 127.0.0.1 है, तो यह लूप का कारण बनता है।

इससे छुटकारा पाने के लिए, आपको उस फ़ाइल को संपादित नहीं करना चाहिए, बल्कि अन्य स्थानों की जाँच करके इसे ठीक से जनरेट करना चाहिए।

/etc/systemd/network के तहत सभी फाइलों की जांच करें और यदि आपको कोई रिकॉर्ड मिलता है

DNS=127.0.0.1

उस रिकॉर्ड को हटा दें। /etc/systemd/resolved.conf भी चेक करें और जरूरत पड़ने पर ऐसा ही करें। सुनिश्चित करें कि आपके पास कम से कम एक या दो DNS सर्वर कॉन्फ़िगर किए गए हैं, जैसे

DNS=1.1.1.1 1.0.0.1

यह सब करने के बाद, अपने परिवर्तनों को प्रभावी बनाने के लिए सिस्टमड सेवाओं को पुनरारंभ करें:
systemctl पुनरारंभ systemd-networkd systemd-resolved

उसके बाद, सत्यापित करें कि DNS=127.0.0.1 अब resolv.conf फ़ाइल में नहीं है:

cat /run/systemd/resolve/resolv.conf

अंत में, DNS पॉड्स के पुन: निर्माण को ट्रिगर करें

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

सारांश: समाधान में होस्ट DNS कॉन्फ़िगरेशन से DNS लुकअप लूप की तरह दिखने वाली चीज़ों से छुटकारा पाना शामिल है। विभिन्न resolv.conf प्रबंधकों/कार्यान्वयन के बीच चरण भिन्न होते हैं।

धन्यवाद। यह CoreDNS लूप प्लगइन रीडमी में भी शामिल है ...

मुझे एक ही समस्या है, और दूसरी समस्या है
1、मतलब मुझे डीएनएस नहीं मिला। त्रुटि है
[त्रुटि] प्लगइन / त्रुटियाँ: 2 2115717704248378980.120568170924441806। HINFO: पहुंच से बाहर बैकएंड: udp 10.224.0.3:57088->8.8.8.8:53 पढ़ें: i/o टाइमआउट
[त्रुटि] प्लगइन / त्रुटियाँ: 2 2115717704248378980.120568170924441806। HINFO: पहुंच से बाहर बैकएंड: udp 10.224.0.3:38819->172.16.254.1:53 पढ़ें: i/o टाइमआउट
........

मेरा /etc/resolv.com
नोली हैव
नेमसर्वर 172.16.254.1 #यह मेरा डीएनएस है
नेमसर्वर 8.8.8.8 #नेट में एक और डीएनएस
मै भागा

kubectl -n kube-system को परिनियोजन प्राप्त करें coredns -o yaml | \
sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
Kubectl लागू -f -

तब पॉड पुनर्निर्माण में केवल एक त्रुटि होती है

[त्रुटि] प्लगइन/त्रुटियां: 2 10594135170717325.8545646296733374240। HINFO: अगम्य बैकएंड: कोई अपस्ट्रीम होस्ट नहीं

मुझे नहीं पता कि क्या यह सामान्य है। शायद

2、 the coredns को मेरी एपीआई सेवा नहीं मिल सकती है। त्रुटि है

क्यूब-डीएनएस सूचीबद्ध करने में विफल *v1.Endpoints getockopt: 10.96.0.1:6443 एपीआई कनेक्शन अस्वीकृत

coredns बार-बार पुनरारंभ होता है, अंत में CrashLoopBackOff होगा

इसलिए मुझे मास्टर नोड पर कोर्डन्स चलाना है, मैं वह करता हूँ

kubectl परिनियोजन/coredns संपादित करें --namespace=kube-system
कल्पना.टेम्पलेट.कल्पना
नोड चयनकर्ता:
node-role.kubernetes.io/master: ""

मुझे नहीं पता कि क्या यह सामान्य है

अंत में मेरा env . दे

लिनक्स 4.20.10-1.el7.elrepo.x86_64 /// सेंटोस 7

डॉकर संस्करण: 18.09.3

[ रूट@k8smaster00 ~]# डॉकर छवि ls -a
रिपोजिटरी टैग छवि आईडी बनाया गया आकार
k8s.gcr.io/kube-controller-manager v1.13.3 0482f6400933 6 सप्ताह पहले 146MB
k8s.gcr.io/kube-proxy v1.13.3 98db19758ad4 6 सप्ताह पहले 80.3MB
k8s.gcr.io/kube-apiserver v1.13.3 fe242e556a99 6 सप्ताह पहले 181MB
k8s.gcr.io/kube-scheduler v1.13.3 3a6f709e97a0 6 सप्ताह पहले 79.6MB
quay.io/coreos/flannel v0.11.0-amd64 ff281650a721 7 सप्ताह पहले 52.6MB
k8s.gcr.io/coredns 1.2.6 f59dccceff4 4 महीने पहले 40MB
k8s.gcr.io/etcd 3.2.24 3cab8e1b9802 6 महीने पहले 220MB
k8s.gcr.io/pause 3.1 da86e6ba6ca1 15 महीने पहले 742kB

क्यूबनेट 1.13.3 . है

मुझे लगता है कि यह एक बग है एक आधिकारिक अद्यतन या समाधान की अपेक्षा करें

मुझे एक ही समस्या है ...

@mengxifl , वे त्रुटियां इस मुद्दे में रिपोर्ट की गई और चर्चा की गई त्रुटियों से काफी भिन्न हैं।

[त्रुटि] प्लगइन / त्रुटियाँ: 2 2115717704248378980.120568170924441806। HINFO: पहुंच से बाहर बैकएंड: udp 10.224.0.3:57088->8.8.8.8:53 पढ़ें: i/o टाइमआउट
[त्रुटि] प्लगइन / त्रुटियाँ: 2 2115717704248378980.120568170924441806। HINFO: पहुंच से बाहर बैकएंड: udp 10.224.0.3:38819->172.16.254.1:53 पढ़ें: i/o टाइमआउट

उन त्रुटियों का मतलब है कि CoreDNS पॉड (और शायद अन्य सभी पॉड) आपके नेमसर्वर तक नहीं पहुंच सकते। यह आपके क्लस्टर में बाहरी दुनिया के लिए एक नेटवर्किंग समस्या का सुझाव देता है। संभवतः फलालैन गलत विन्यास या फायरवॉल।

कोर्डन्स को मेरी एपीआई सेवा नहीं मिली ...
इसलिए मुझे मास्टर नोड पर कोर्डन्स चलाना है

यह भी सामान्य नहीं है। अगर मैं आपको सही ढंग से समझता हूं, तो आप कह रहे हैं कि CoreDNS मास्टर नोड से एपीआई से संपर्क कर सकता है लेकिन अन्य नोड्स से नहीं। यह आपके क्लस्टर के भीतर नोड्स के बीच नेटवर्किंग समस्याओं को सेवा देने के लिए पॉड का सुझाव देगा - शायद फलालैन कॉन्फ़िगरेशन या फ़ायरवॉल के साथ कोई समस्या।

मुझे एक ही समस्या है ...

@mengxifl , वे त्रुटियां इस मुद्दे में रिपोर्ट की गई और चर्चा की गई त्रुटियों से काफी भिन्न हैं।

[त्रुटि] प्लगइन / त्रुटियाँ: 2 2115717704248378980.120568170924441806। HINFO: पहुंच से बाहर बैकएंड: udp 10.224.0.3:57088->8.8.8.8:53 पढ़ें: i/o टाइमआउट
[त्रुटि] प्लगइन / त्रुटियाँ: 2 2115717704248378980.120568170924441806। HINFO: पहुंच से बाहर बैकएंड: udp 10.224.0.3:38819->172.16.254.1:53 पढ़ें: i/o टाइमआउट

उन त्रुटियों का मतलब है कि CoreDNS पॉड (और शायद अन्य सभी पॉड) आपके नेमसर्वर तक नहीं पहुंच सकते। यह आपके क्लस्टर में बाहरी दुनिया के लिए एक नेटवर्किंग समस्या का सुझाव देता है। संभवतः फलालैन गलत विन्यास या फायरवॉल।

कोर्डन्स को मेरी एपीआई सेवा नहीं मिली ...
इसलिए मुझे मास्टर नोड पर कोर्डन्स चलाना है

यह भी सामान्य नहीं है। अगर मैं आपको सही ढंग से समझता हूं, तो आप कह रहे हैं कि CoreDNS मास्टर नोड से एपीआई से संपर्क कर सकता है लेकिन अन्य नोड्स से नहीं। यह आपके क्लस्टर के भीतर नोड्स के बीच नेटवर्किंग समस्याओं को सेवा देने के लिए पॉड का सुझाव देगा - शायद फलालैन कॉन्फ़िगरेशन या फ़ायरवॉल के साथ कोई समस्या।

आपके जवाब के लिए धन्यवाद

शायद मुझे अपनी yaml फ़ाइल डालनी चाहिए

मैं उपयोग करता हूं
कुबेदम init --config=config.yaml

मेरी 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

मेरा फ़नल yaml डिफ़ॉल्ट है

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

systemctl status firewalld
सभी नोड कहते हैं
इकाई Firewalld.service नहीं मिल सका।

cat /etc/sysconfig/iptables
सभी नोड कहते हैं
*फ़िल्टर
: इनपुट स्वीकार [0:0]
: आगे स्वीकार करें [0:0]
: आउटपुट स्वीकार [0:0]
-एक इनपुट -पी टीसीपी -एम टीसीपी --dport 1:65535 -j स्वीकार करें
-एक इनपुट-एम राज्य - संबंधित राज्य, स्थापित -जे स्वीकार करें
-एक इनपुट-पी आईसीएमपी-जे स्वीकार करें
-एक इनपुट-आई लो-जे स्वीकार करें
-ए इनपुट-पी टीसीपी-एम स्टेट-स्टेट न्यू-एम टीसीपी--डीपोर्ट 22-जे स्वीकार करें
-ए आउटपुट-पी टीसीपी-एम टीसीपी --स्पोर्ट 1: 65535 -जे स्वीकार करें
-ए फॉरवर्ड-पी टीसीपी-एम टीसीपी -पोर्ट 1: 65535 -जे स्वीकार करें
-ए फॉरवर्ड-पी टीसीपी-एम टीसीपी --स्पोर्ट 1: 65535 -जे स्वीकार करें
COMMI

cat /etc/resolv.conf & ping bing.com
सभी नोड कहते हैं
[1] 6330
नेमसर्वर 172.16.254.1
नेमसर्वर 8.8.8.8
पिंग bing.com (13.107.21.200) 56 (84) डेटा के बाइट्स।
13.107.21.200 (13.107.21.200) से 64 बाइट्स: icmp_seq=2 ttl=111 समय=149 ms

uname -rs
मास्टर नोड कहो
लिनक्स 4.20.10-1.el7.elrepo.x86_64

uname -rs
गुलाम नोड कहो
लिनक्स 4.4.176-1.el7.elrepo.x86_64

तो मुझे नहीं लगता कि फ़ायरवॉल ने mybe fannel जारी किया है? लेकिन मैं डिफ़ॉल्ट कॉन्फ़िगरेशन का उपयोग करता हूं। और शायद लिनक्स संस्करण। मुझें नहीं पता ।

ठीक है मैं दौड़ता हूँ
/sbin/iptables -t nat -I POSTROUTING -s 10.224.0.0/16 -j MASQUERADE

मेरे सभी नोड पर जो मेरे लिए काम करता है। धन्यवाद