Kubeadm: CoreDNS tidak dimulai dengan k8s 1.11 dan weave (CentOS 7)

@kubernetes/sig-network-bugs

@carlosmkb , apa versi buruh pelabuhan Anda?

Saya merasa ini sulit dipercaya, kami menguji CentOS 7 secara ekstensif di pihak kami.

Apakah Anda memiliki sistem dan pod log?

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

@dims , bisa masuk akal, saya akan mencoba

@neolit123 dan @timothysc

versi buruh pelabuhan: buruh pelabuhan-1.13.1-63.git94f4240.el7.centos.x86_64

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

Menemukan beberapa contoh kesalahan yang sama yang dilaporkan dalam skenario lain di masa lalu.
Mungkin mencoba menghapus "allowPrivilegeEscalation: false" dari penerapan CoreDNS untuk melihat apakah itu membantu.

Masalah yang sama untuk saya. Pengaturan serupa CentOS 7.4.1708, Docker versi 1.13.1, build 94f4240/1.13.1 (dilengkapi dengan 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"

untuk jaga-jaga, selinux dalam mode permisif di semua node.

Saya menggunakan Calico (bukan menenun sebagai @carlosmkb).

[ root@faas-A01 ~]# kubectl logs --namespace=kube-system coredns-78fcdf6894-p4wbl
standard_init_linux.go:178: proses pengguna exec menyebabkan "operasi tidak diizinkan"

Ah - Ini adalah kesalahan dari kubectl ketika mencoba untuk mendapatkan log, bukan isi dari log...

@chrisohaver kubectl logs bekerja dengan pod sistem kube lain

Oke - sudahkah Anda mencoba menghapus "allowPrivilegeEscalation: false" dari penerapan CoreDNS untuk melihat apakah itu membantu?

... apakah kubectl describe dari pod coredns menunjukkan sesuatu yang menarik?

Masalah yang sama untuk saya.
CentOS Linux rilis 7.5.1804 (Inti)
Docker versi 1.13.1, build dded712/1.13.1
kain flanel sebagai pengaya 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

Saya memiliki masalah yang sama ketika selinux dalam mode permisif. Ketika saya menonaktifkannya di /etc/selinux/conf SELINUX=disabled dan me-reboot mesin, pod dijalankan.

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

FYI, Juga berfungsi untuk saya dengan SELinux dinonaktifkan (tidak permisif, tetapi _disabled_).
Docker versi 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

Kami juga mengalami masalah ini, kami menyediakan infrastruktur melalui otomatisasi, sehingga memerlukan restart untuk menonaktifkan selinux sepenuhnya tidak dapat diterima. Apakah ada solusi lain mengapa kami menunggu ini diperbaiki?

Coba hapus "allowPrivilegeEscalation: false" dari penerapan CoreDNS untuk melihat apakah itu membantu.
Memperbarui ke versi buruh pelabuhan yang lebih baru (dari 1.13) juga dapat membantu.

Masalah yang sama di sini
Docker versi 1.2.6
CentOS 7
seperti @lareeth kami juga menyediakan otomatisasi kubernetes saat menggunakan kubeadm, dan juga memerlukan restart untuk menonaktifkan selinux sepenuhnya tidak dapat diterima.
@chrisohaver mencoba meminta restart untuk sepenuhnya menonaktifkan selinux tidak dapat diterima. itu berguna. Terima kasih !
Tapi seperti yang saya tahu opsi coredns tidak diatur dalam konfigurasi kubeadm
Apakah tidak ada cara lain?

Coba hapus "allowPrivilegeEscalation: false" dari penerapan CoreDNS untuk melihat apakah itu membantu.
Memperbarui ke versi buruh pelabuhan yang lebih baru (misalnya ke versi yang direkomendasikan oleh k8s) juga dapat membantu.

Saya memverifikasi bahwa menghapus "allowPrivilegeEscalation: false" dari penyebaran coredns menyelesaikan masalah (dengan SE linux diaktifkan dalam mode permisif).

Saya juga memverifikasi bahwa memutakhirkan ke versi buruh pelabuhan yang direkomendasikan oleh Kubernetes ( buruh pelabuhan 17.03 ) menyelesaikan masalah, dengan "allowPrivilegeEscalation: false" dibiarkan di tempat dalam penyebaran coredns, dan SELinux diaktifkan dalam mode permisif.

Jadi, sepertinya ada ketidakcocokan antara versi lama buruh pelabuhan dan SELinux dengan direktif allowPrivilegeEscalation yang tampaknya telah diselesaikan di versi buruh pelabuhan yang lebih baru.

Tampaknya ada 3 solusi yang berbeda:

• Tingkatkan ke versi buruh pelabuhan yang lebih baru, misalnya 17.03, versi yang saat ini direkomendasikan oleh k8s
• Atau hapus allowPrivilegeEscalation=false dari spesifikasi pod penerapan
• Atau nonaktifkan SELinux

@chrisohaver Saya telah menyelesaikan masalah dengan memutakhirkan ke versi yang lebih baru dari buruh pelabuhan 17.03. Terima kasih

terima kasih atas penyelidikannya @chrisohaver :100:

Terima kasih, @chrisohaver !

Ini berhasil:

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

@chrisohaver
menurut Anda apakah kami harus mendokumentasikan langkah ini dalam panduan pemecahan masalah kubeadm untuk node SELinux di baris:

coredns memiliki status CrashLoopBackOff atau Error

Jika Anda memiliki node yang menjalankan SELinux dengan versi Docker yang lebih lama, Anda mungkin mengalami skenario di mana pod coredns tidak dimulai. Untuk mengatasinya, Anda dapat mencoba salah satu opsi berikut:

• Tingkatkan ke versi Docker yang lebih baru - 17.03 dipastikan berfungsi.
• Nonaktifkan SELinux.
• Ubah penerapan coredns untuk menetapkan allowPrivilegeEscalation menjadi true :

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

WDYT? tolong sarankan mengubah teks jika Anda berpikir sesuatu dapat diperbaiki.

Tidak apa-apa. Kami mungkin harus menyebutkan bahwa ada implikasi keamanan negatif saat menonaktifkan SELinux, atau mengubah pengaturan allowPrivilegeEscalation.

Solusi paling aman adalah memutakhirkan Docker ke versi yang direkomendasikan Kubernetes (17.03)

@chrisohaver
dipahami, akan mengubah salinan dan menyerahkan PR untuk ini.

Ada juga jawaban untuk itu di stackoverflow:
https://stackoverflow.com/questions/53075796/coredns-pods-have-crashloopbackoff-or-error-state

kesalahan ini

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

disebabkan ketika CoreDNS mendeteksi loop dalam konfigurasi penyelesaian, dan itu adalah perilaku yang diinginkan. Anda mengalami masalah ini:

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

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

Solusi peretasan: Nonaktifkan deteksi loop CoreDNS

Edit peta konfigurasi CoreDNS:

kubectl -n kube-system edit configmap coredns

Hapus atau komentari baris dengan loop , simpan dan keluar.

Kemudian hapus pod CoreDNS, sehingga yang baru dapat dibuat dengan konfigurasi baru:

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

Semua harus baik-baik saja setelah itu.

Solusi Pilihan: Hapus loop dalam konfigurasi DNS

Pertama, periksa apakah Anda menggunakan systemd-resolved . Jika Anda menjalankan Ubuntu 18.04, mungkin itu masalahnya.

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

Jika ya, periksa file resolv.conf mana yang digunakan cluster Anda sebagai referensi:

ps auxww | grep kubelet

Anda mungkin melihat garis seperti:

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

Bagian yang penting adalah --resolv-conf - kita mencari tahu apakah systemd resolv.conf digunakan, atau tidak.

Jika resolv.conf dari systemd , lakukan hal berikut:

Periksa konten /run/systemd/resolve/resolv.conf untuk melihat apakah ada catatan seperti:

nameserver 127.0.0.1

Jika ada 127.0.0.1 , itu yang menyebabkan loop.

Untuk menghilangkannya, Anda tidak boleh mengedit file itu, tetapi periksa tempat lain untuk membuatnya dibuat dengan benar.

Periksa semua file di bawah /etc/systemd/network dan jika Anda menemukan catatan seperti

DNS=127.0.0.1

menghapus catatan itu. Periksa juga /etc/systemd/resolved.conf dan lakukan hal yang sama jika diperlukan. Pastikan Anda memiliki setidaknya satu atau dua server DNS yang dikonfigurasi, seperti:

DNS=1.1.1.1 1.0.0.1

Setelah melakukan semua itu, mulai ulang layanan systemd untuk menerapkan perubahan Anda:
systemctl restart systemd-networkd systemd-resolved

Setelah itu, verifikasi bahwa DNS=127.0.0.1 tidak ada lagi di file resolv.conf :

cat /run/systemd/resolve/resolv.conf

Terakhir, picu pembuatan ulang pod DNS

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

Ringkasan: Solusinya adalah dengan menyingkirkan apa yang tampak seperti loop pencarian DNS dari konfigurasi DNS host. Langkah-langkah bervariasi antara manajer/implementasi resolv.conf yang berbeda.

Terima kasih. Itu juga tercakup dalam readme plugin loop CoreDNS ...

Saya memiliki masalah yang sama, dan masalah lain
1、berarti saya tidak dapat menemukan dns. kesalahannya adalah
Plugin/kesalahan [ERROR]: 2 2115717704248378980.1120568170924441806. HINFO: backend tidak terjangkau: baca udp 10.224.0.3:57088->8.8.8.8:53: i/o timeout
Plugin/kesalahan [ERROR]: 2 2115717704248378980.1120568170924441806. HINFO: backend tidak terjangkau: baca udp 10.224.0.3:38819->172.16.254.1:53: i/o timeout
........

/etc/resolv.com saya
hanya punya
nameserver 172.16.254.1 #ini dns saya
nameserver 8.8.8.8 #dns lain di net
saya berlari

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

maka pod membangun kembali hanya memiliki satu kesalahan

Plugin/kesalahan [ERROR]: 2 10594135170717325.8545646296733374240. HINFO: backend tidak terjangkau: tidak ada host upstream

Saya tidak tahu apakah itu normal. mungkin

2、the coredns tidak dapat menemukan layanan api saya. kesalahan adalah

kube-dns Gagal membuat daftar *v1.Endpoints getockopt: 10.96.0.1:6443 koneksi api ditolak

coredns restart lagi dan lagi, akhirnya akan CrashLoopBackOff

jadi saya harus menjalankan coredns pada master node saya melakukan itu

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

Saya tidak tahu apakah itu normal

akhirnya memberikan env saya

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

Versi buruh pelabuhan: 18.09.3

[ root@k8smaster00 ~]# gambar buruh pelabuhan ls -a
UKURAN GAMBAR ID TAG REPOSITORY DIBUAT
k8s.gcr.io/kube-controller-manager v1.13.3 0482f6400933 6 minggu yang lalu 146MB
k8s.gcr.io/kube-proxy v1.13.3 98db19758ad4 6 minggu yang lalu 80.3MB
k8s.gcr.io/kube-apiserver v1.13.3 fe242e556a99 6 minggu lalu 181MB
k8s.gcr.io/kube-scheduler v1.13.3 3a6f709e97a0 6 minggu yang lalu 79.6MB
quay.io/coreos/flannel v0.11.0-amd64 ff281650a721 7 minggu yang lalu 52.6MB
k8s.gcr.io/coredns 1.2.6 f59dcacceff4 4 bulan lalu 40MB
k8s.gcr.io/etcd 3.2.24 3cab8e1b9802 6 bulan lalu 220MB
k8s.gcr.io/pause 3.1 da86e6ba6ca1 15 bulan yang lalu 742kB

kubenet adalah 1.13.3

Saya pikir ini adalah bug. Harapkan pembaruan resmi atau solusi

saya punya masalah yang sama...

@mengxifl , Kesalahan itu sangat berbeda dari yang dilaporkan dan dibahas dalam masalah ini.

Plugin/kesalahan [ERROR]: 2 2115717704248378980.1120568170924441806. HINFO: backend tidak terjangkau: baca udp 10.224.0.3:57088->8.8.8.8:53: i/o timeout
Plugin/kesalahan [ERROR]: 2 2115717704248378980.1120568170924441806. HINFO: backend tidak terjangkau: baca udp 10.224.0.3:38819->172.16.254.1:53: i/o timeout

Kesalahan tersebut berarti bahwa pod CoreDNS (dan mungkin semua pod lainnya) tidak dapat menjangkau server nama Anda. Ini menunjukkan masalah jaringan di cluster Anda ke dunia luar. Kemungkinan kesalahan konfigurasi flanel atau firewall.

coredns tidak dapat menemukan layanan api saya ...
jadi saya harus menjalankan coredns di master node

Ini juga tidak normal. Jika saya memahami Anda dengan benar, Anda mengatakan bahwa CoreDNS dapat menghubungi API dari node master tetapi tidak dari node lain. Ini akan menyarankan pod untuk melayani masalah jaringan antar node dalam cluster Anda - mungkin masalah dengan konfigurasi flanel atau firewall.

saya punya masalah yang sama...

@mengxifl , Kesalahan itu sangat berbeda dari yang dilaporkan dan dibahas dalam masalah ini.

Plugin/kesalahan [ERROR]: 2 2115717704248378980.1120568170924441806. HINFO: backend tidak terjangkau: baca udp 10.224.0.3:57088->8.8.8.8:53: i/o timeout
Plugin/kesalahan [ERROR]: 2 2115717704248378980.1120568170924441806. HINFO: backend tidak terjangkau: baca udp 10.224.0.3:38819->172.16.254.1:53: i/o timeout

Kesalahan tersebut berarti bahwa pod CoreDNS (dan mungkin semua pod lainnya) tidak dapat menjangkau server nama Anda. Ini menunjukkan masalah jaringan di cluster Anda ke dunia luar. Kemungkinan kesalahan konfigurasi flanel atau firewall.

coredns tidak dapat menemukan layanan api saya ...
jadi saya harus menjalankan coredns di master node

Ini juga tidak normal. Jika saya memahami Anda dengan benar, Anda mengatakan bahwa CoreDNS dapat menghubungi API dari node master tetapi tidak dari node lain. Ini akan menyarankan pod untuk melayani masalah jaringan antar node dalam cluster Anda - mungkin masalah dengan konfigurasi flanel atau firewall.

Terimakasih atas balasan anda

mungkin saya harus memasang file yaml saya

saya menggunakan
kubeadm init --config=config.yaml

konten config.yaml saya adalah

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 fannel saya adalah default

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

systemctl status firewalld
SEMUA simpul mengatakan
Unit firewalld.service tidak dapat ditemukan.

cat /etc/sysconfig/iptables
SEMUA simpul mengatakan
*Saring
:MASUKKAN TERIMA [0:0]
:TERIMA MENERIMA [0:0]
:OUTPUT MENERIMA [0:0]
-MASUKKAN -p tcp -m tcp --dport 1:65535 -j TERIMA
-A INPUT -m state --state TERKAIT,ESTABLISHED -j ACCEPT
-MASUKKAN -p icmp -j TERIMA
-A INPUT -i lo -j TERIMA
-A INPUT -p tcp -m state --state BARU -m tcp --dport 22 -j MENERIMA
-A OUTPUT -p tcp -m tcp --sport 1:65535 -j TERIMA
-MAJU -p tcp -m tcp --dport 1:65535 -j TERIMA
-MAJU -p tcp -m tcp --sport 1:65535 -j TERIMA
KOMI

cat /etc/resolv.conf & ping bing.com
SEMUA simpul mengatakan
[1] 6330
server nama 172.16.254.1
server nama 8.8.8.8
PING bing.com (13.107.21.200) 56(84) byte data.
64 byte dari 13.107.21.200 (13.107.21.200): icmp_seq=2 ttl=111 waktu=149 mdtk

uname -rs
simpul utama mengatakan
Linux 4.20.10-1.el7.elrepo.x86_64

uname -rs
simpul budak mengatakan
Linux 4.4.176-1.el7.elrepo.x86_64

jadi saya tidak berpikir firewall memiliki masalah mybe fannel? tapi saya menggunakan konfigurasi default. Dan mungkin versi linux. saya tidak tahu .

oke aku lari
/sbin/iptables -t nat -I POSTROUTING -s 10.224.0.0/16 -j MASQUERADE

pada semua simpul saya yang berfungsi untuk saya. Terima kasih