Kubeadm: لم يبدأ CoreDNS بـ k8s 1.11 ونسج (CentOS 7)

@ kubernetes / sig-network-bugs

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)"

تم العثور على مثلين لنفس الأخطاء تم الإبلاغ عنها في سيناريوهات أخرى في الماضي.
قد تحاول إزالة "allowPrivilegeEscalation: false" من نشر CoreDNS لمعرفة ما إذا كان ذلك يساعد.

نفس المشكلة بالنسبة لي. إعداد مماثل CentOS 7.4.1708 ، إصدار Docker 1.13.1 ، build 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"

فقط في حالة وجود selinux في الوضع المتساهل على جميع العقد.

أنا أستخدم كاليكو (وليس نسج مثل carlosmkb).

[ root @ faas-A01 ~] # kubectl logs --namespace = kube-system coredns-78fcdf6894-p4wbl
standard_init_linux.go: 178: تسببت عملية مستخدم exec في "عملية غير مسموح بها"

آه - هذا خطأ من kubectl عند محاولة الحصول على السجلات ، وليس محتويات السجلات ...

chrisohaver يعمل kubectl logs مع كبسولات نظام kube أخرى

حسنًا - هل حاولت إزالة "allowPrivilegeEscalation: false" من نشر CoreDNS لمعرفة ما إذا كان ذلك يساعدك؟

... هل يُظهر kubectl describe من جراب coredns أي شيء مثير للاهتمام؟

نفس المشكلة بالنسبة لي.
إصدار CentOS Linux 7.5.1804 (Core)
إصدار Docker 1.13.1 ، بناء dded712 / 1.13.1
الفانيلا كإضافة 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

لدي نفس المشكلة عندما يكون selinux في وضع مقنع. عندما أقوم بتعطيله في / etc / selinux / conf SELINUX = معطل وإعادة تشغيل الجهاز ، يبدأ الكبسولة.

ريدهات 7.4 ، نواة 3.10.0-693.11.6.el7.x86_64
عامل ميناء 1.13.1-68.gitdded712.el7.x86_64

لمعلوماتك ، يعمل أيضًا معي مع تعطيل SELinux (غير مسموح به ، ولكن _ معطل_).
إصدار Docker 1.13.1 ، بناء 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

نواجه أيضًا هذه المشكلة ، فنحن نوفر البنية التحتية من خلال الأتمتة ، لذا فإن طلب إعادة التشغيل لتعطيل selinux تمامًا أمر غير مقبول. هل هناك أي حلول أخرى لماذا ننتظر حتى يتم إصلاح هذا؟

حاول إزالة "allowPrivilegeEscalation: false" من نشر CoreDNS لمعرفة ما إذا كان ذلك مفيدًا.
قد يساعد أيضًا التحديث إلى إصدار أحدث من docker (من 1.13).

نفس المشكلة هنا
إصدار Docker 1.2.6
CentOS 7
مثل lareeth ، نوفر أيضًا أتمتة kubernetes عند استخدام kubeadm ، كما أن طلب إعادة التشغيل لتعطيل selinux تمامًا أمر غير مقبول.
chrisohaver حاول طلب إعادة التشغيل لتعطيل selinux تمامًا أمر غير مقبول. انها مفيدة. شكرا !
ولكن كما أعلم لم يتم تعيين خيارات coredns في تكوين kubeadm
اليس هنالك طريقة اخرى؟

حاول إزالة "allowPrivilegeEscalation: false" من نشر CoreDNS لمعرفة ما إذا كان ذلك مفيدًا.
قد يساعد أيضًا التحديث إلى إصدار أحدث من docker (على سبيل المثال إلى الإصدار الذي أوصت به k8s).

لقد تحققت من أن إزالة "allowPrivilegeEscalation: false" من نشر النوى يحل المشكلة (مع تمكين SE linux في الوضع المسموح به).

لقد تحققت أيضًا من أن الترقية إلى إصدار من docker أوصت به Kubernetes (عامل الإرساء 17.03) يحل المشكلة ، مع ترك "allowPrivilegeEscalation: false" في مكانه في نشر coredns ، وتمكين SELinux في الوضع المسموح.

لذلك ، يبدو أن هناك عدم توافق بين الإصدارات القديمة من docker و SELinux مع التوجيه allowPrivilegeEscalation الذي يبدو أنه تم حله في الإصدارات الأحدث من عامل الإرساء.

يبدو أن هناك 3 طرق عمل مختلفة:

• قم بالترقية إلى إصدار أحدث من docker ، على سبيل المثال 17.03 ، الإصدار الموصى به حاليًا من قبل k8s
• أو قم بإزالة allowPrivilegeEscalation = false من مواصفات حجرة النشر
• أو قم بتعطيل SELinux

chrisohaver لقد قمت بحل المشكلة عن طريق الترقية إلى الإصدار الأحدث من docker 17.03. شكرا

شكرا على التحقيق chrisohaver : 100:

شكرا ، chrisohaver !

نجح هذا:

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

تضمين التغريدة
هل تعتقد أنه يجب علينا توثيق هذه الخطوة في دليل استكشاف الأخطاء وإصلاحها kubeadm لعقد SELinux في سطور:

coredns pods بها CrashLoopBackOff أو Error حالة

إذا كان لديك عقد تقوم بتشغيل SELinux بإصدار قديم من Docker ، فقد تواجه سيناريو حيث لا تبدأ القرون coredns . لحل هذه المشكلة ، يمكنك تجربة أحد الخيارات التالية:

• الترقية إلى إصدار أحدث من Docker - تم تأكيد عمل 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 -

WDYT؟ يرجى اقتراح تعديلات على النص إذا كنت تعتقد أنه يمكن تحسين شيء ما.

هذا جيد. ربما يجب أن نذكر أن هناك تداعيات أمنية سلبية عند تعطيل SELinux ، أو تغيير إعداد allowPrivilegeEscalation.

الحل الأكثر أمانًا هو ترقية Docker إلى الإصدار الذي يوصي به Kubernetes (17.03)

تضمين التغريدة
مفهومة ، ستقوم بتعديل النسخة وتقديم تصريح إقامة لهذا الغرض.

هناك أيضًا إجابة لذلك في Stackoverflow:
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

بعد القيام بكل ذلك ، أعد تشغيل خدمات systemd لوضع تغييراتك موضع التنفيذ:
إعادة تشغيل systemctl systemd-networkd systemd

بعد ذلك ، تحقق من أن 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 loop ...

لدي نفس المشكلة ومشكلة أخرى
1 ، يعني أنني لا أستطيع العثور على نظام أسماء النطاقات. الخطأ هو
[خطأ] المكون الإضافي / أخطاء: 2 2115717704248378980.1120568170924441806. HINFO: خلفية غير قابلة للوصول: قراءة udp 10.224.0.3:57088->8.8.8.8:53: i / o timeout
[خطأ] المكون الإضافي / أخطاء: 2 2115717704248378980.1120568170924441806. HINFO: خلفية غير قابلة للوصول: قراءة udp 10.224.0.3:38819->172.16.254.1:53: i / o timeout
........

/etc/resolv.com الخاص بي
نولي لديك
خادم الأسماء 172.16.254.1 # هذا هو نظام أسماء النطاقات الخاص بي
خادم الأسماء 8.8.8.8 # نظام أسماء نطاقات أخرى في الشبكة
انا اجري

kubectl -n kube-system احصل على محورية للنشر -o yaml | \
sed 's / allowPrivilegeEscalation: false / allowPrivilegeEscalation: true / g' | \
kubectl تطبيق -f -

ثم جراب إعادة بناء خطأ واحد فقط

[خطأ] المكون الإضافي / أخطاء: 2 10594135170717325.8545646296733374240. HINFO: خلفية لا يمكن الوصول إليها: لا يوجد مضيف علوي

لا أعرف ما إذا كان هذا طبيعيًا. يمكن

2 ، لا يمكن للنواة العثور على خدمة api الخاصة بي. الخطأ

فشل إدراج kube-dns في القائمة * v1.Endpoints getockopt: 10.96.0.1:6443 رفض اتصال api

إعادة تشغيل coredns مرارًا وتكرارًا ، وأخيراً سوف CrashLoopBackOff

لذلك لا بد لي من تشغيل coredns على العقدة الرئيسية أفعل ذلك

kubectl تحرير النشر / coredns --namespace = kube-system
المواصفات
العقدة
node-role.kubernetes.io/master: ""

لا أعرف ما إذا كان هذا طبيعيًا

أخيرًا أعطي حسدتي

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

إصدار عامل ميناء: 18.09.3

[ root @ k8smaster00 ~] # docker image 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 f59dcacceff4 منذ 4 أشهر 40 ميجا بايت
k8s.gcr.io/etcd 3.2.24 3cab8e1b9802 منذ 6 أشهر 220 ميجا بايت
k8s.gcr.io/pause 3.1 da86e6ba6ca1 منذ 15 شهرًا 742kB

kubenets هو 1.13.3

أعتقد أن هذا خطأ توقع تحديثًا رسميًا أو حلًا

لدي نفس المشكلة ...

mengxifl ، تختلف هذه الأخطاء بشكل كبير عن تلك التي تم الإبلاغ عنها ومناقشتها في هذه المشكلة.

[خطأ] المكون الإضافي / أخطاء: 2 2115717704248378980.1120568170924441806. HINFO: خلفية غير قابلة للوصول: قراءة udp 10.224.0.3:57088->8.8.8.8:53: i / o timeout
[خطأ] المكون الإضافي / أخطاء: 2 2115717704248378980.1120568170924441806. HINFO: خلفية غير قابلة للوصول: قراءة udp 10.224.0.3:38819->172.16.254.1:53: i / o timeout

تعني هذه الأخطاء أن جراب CoreDNS (وربما جميع البودات الأخرى) لا يمكنه الوصول إلى خوادم الأسماء الخاصة بك. يشير هذا إلى وجود مشكلة في التواصل في مجموعتك مع العالم الخارجي. ربما خطأ في تكوين الفانيلا أو جدران الحماية.

لا تستطيع النوى العثور على خدمة api الخاصة بي ...
لذلك لا بد لي من تشغيل coredns على العقدة الرئيسية

هذا ايضا ليس طبيعيا إذا كنت أفهمك بشكل صحيح ، فأنت تقول أن CoreDNS يمكنه الاتصال بواجهة برمجة التطبيقات من العقدة الرئيسية ولكن ليس من العقد الأخرى. قد يشير هذا إلى وجود جراب لخدمة مشاكل الشبكة بين العقد داخل المجموعة الخاصة بك - ربما تكون هناك مشكلة في تكوين الفانيلا أو جدران الحماية.

لدي نفس المشكلة ...

mengxifl ، تختلف هذه الأخطاء بشكل كبير عن تلك التي تم الإبلاغ عنها ومناقشتها في هذه المشكلة.

[خطأ] المكون الإضافي / أخطاء: 2 2115717704248378980.1120568170924441806. HINFO: خلفية غير قابلة للوصول: قراءة udp 10.224.0.3:57088->8.8.8.8:53: i / o timeout
[خطأ] المكون الإضافي / أخطاء: 2 2115717704248378980.1120568170924441806. HINFO: خلفية غير قابلة للوصول: قراءة udp 10.224.0.3:38819->172.16.254.1:53: i / o timeout

تعني هذه الأخطاء أن جراب CoreDNS (وربما جميع البودات الأخرى) لا يمكنه الوصول إلى خوادم الأسماء الخاصة بك. يشير هذا إلى وجود مشكلة في التواصل في مجموعتك مع العالم الخارجي. ربما خطأ في تكوين الفانيلا أو جدران الحماية.

لا تستطيع النوى العثور على خدمة api الخاصة بي ...
لذلك لا بد لي من تشغيل coredns على العقدة الرئيسية

هذا ايضا ليس طبيعيا إذا كنت أفهمك بشكل صحيح ، فأنت تقول أن CoreDNS يمكنه الاتصال بواجهة برمجة التطبيقات من العقدة الرئيسية ولكن ليس من العقد الأخرى. قد يشير هذا إلى وجود جراب لخدمة مشاكل الشبكة بين العقد داخل المجموعة الخاصة بك - ربما تكون هناك مشكلة في تكوين الفانيلا أو جدران الحماية.

شكرا لك على الرد

ربما ينبغي أن أطرح ملف yaml الخاص بي

أنا أستعمل
kubeadm 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

my fannel yaml هو الافتراضي

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

systemctl status firewalld
كل العقدة تقول
تعذر العثور على وحدة جدار الحماية.

cat /etc/sysconfig/iptables
كل العقدة تقول
*منقي
: قبول الإدخال [0: 0]
: FORWARD ACCEPT [0: 0]
: قبول الإخراج [0: 0]
-A INPUT -p tcp -m tcp --dport 1: 65535 -j قبول
-حالة الإدخال -m- ذات الصلة بالدولة ، تأسست -ج قبول
-A المدخلات -p icmp -j قبول
-A المدخلات -i lo -j قبول
-A INPUT -p tcp -m state -state NEW -m tcp -dport 22 -j ACCEPT
-A الإخراج -p tcp -m tcp --sport 1: 65535 -j قبول
-A FORWARD -p tcp -m tcp --dport 1: 65535 -j قبول
-A FORWARD -p tcp -m tcp --sport 1: 65535 -j قبول
كوممي

cat /etc/resolv.conf & ping bing.com
كل العقدة تقول
[1] 6330
خادم الأسماء 172.16.254.1
خادم الأسماء 8.8.8.8
PING bing.com (13.107.21.200) 56 (84) بايت من البيانات.
64 بايت من 13.107.21.200 (13.107.21.200): icmp_seq = 2 ttl = 111 الوقت = 149 مللي ثانية

uname -rs
العقدة الرئيسية تقول
Linux 4.20.10-1.el7.elrepo.x86_64

uname -rs
عقدة الرقيق تقول
Linux 4.4.176-1.el7.elrepo.x86_64

لذلك لا أعتقد أن جدار الحماية لديه مشكلة mybe fannel؟ لكني استخدم التكوين الافتراضي. وربما نسخة لينكس. لا أدري، لا أعرف .

حسنا أنا أركض
/sbin/iptables -t nat -I POSTROUTING -s 10.224.0.0/16 -j MASQUERADE

على كل ما عندي من العقدة التي تعمل بالنسبة لي. شكرا