Kubeadm: CoreDNS 不是从 k8s 1.11 和 weave (CentOS 7) 开始的

创建于 2018-07-17  ·  33评论  ·  资料来源: kubernetes/kubeadm

这是错误报告还是功能请求?

错误报告

版本

kubeadm 版本1.11

环境

  • Kubernetes 版本(使用kubectl version ):1.11
  • 云提供商或硬件配置:aws ec2 with (16vcpus 64gb RAM)
  • 操作系统(例如来自 /etc/os-release):centos 7
  • 内核(例如uname -a ):3.10.0-693.17.1.el7.x86_64
  • 其他: weave as cni add-on

发生了什么?

在 kubeadm init 之后,coreos pod 停留在错误中

NAME                                   READY     STATUS    RESTARTS   AGE
coredns-78fcdf6894-ljdjp               0/1       Error     6          9m
coredns-78fcdf6894-p6flm               0/1       Error     6          9m
etcd-master                            1/1       Running   0          8m
heapster-5bbdfbff9f-h5h2n              1/1       Running   0          9m
kube-apiserver-master                  1/1       Running   0          8m
kube-controller-manager-master         1/1       Running   0          8m
kube-proxy-5642r                       1/1       Running   0          9m
kube-scheduler-master                  1/1       Running   0          8m
kubernetes-dashboard-6948bdb78-bwkvx   1/1       Running   0          9m
weave-net-r5jkg                        2/2       Running   0          9m

两个 pod 的日志显示如下:
standard_init_linux.go:178: exec user process caused "operation not permitted"

kindocumentation lifecyclactive prioritimportant-soon

最有用的评论

谢谢, @chrisohaver

这有效:

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

所有33条评论

@kubernetes/sig-network-bugs

@carlosmkb ,你的 docker 版本是什么?

我觉得这很难相信,我们对 CentOS 7 进行了广泛的测试。

你有系统和 pod 日志吗?

@dims有道理,我试试

@neolit123@timothysc

docker版本:docker-1.13.1-63.git94f4240.el7.centos.x86_64

coredns pod 日志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,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 日志 --namespace=kube-system coredns-78fcdf6894-p4wbl
standard_init_linux.go:178: exec 用户进程导致“操作不允许”

啊 - 这是 kubectl 在尝试获取日志时的错误,而不是日志的内容......

@chrisohaver kubectl logs与另一个 kube-system pod 一起使用

好的 - 您是否尝试过从 CoreDNS 部署中删除“allowPrivilegeEscalation: false”以查看是否有帮助?

... coredns pod 的kubectl describe有什么有趣的地方吗?

对我来说同样的问题。
CentOS Linux 版本 7.5.1804(核心)
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 处于 permissive 模式时,我遇到了同样的问题。 当我在 /etc/selinux/conf SELINUX=disabled 中禁用它并重新启动机器时,pod 会启动。

红帽 7.4,内核 3.10.0-693.11.6.el7.x86_64
docker-1.13.1-68.gitdded712.el7.x86_64

仅供参考,在禁用 SELinux 的情况下也适用于我(不允许,但_disabled_)。
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 是不可接受的。 是否有任何其他解决方法,为什么我们要等待这个问题得到修复?

尝试从 CoreDNS 部署中删除“allowPrivilegeEscalation: false”,看看是否有帮助。
更新到更新版本的 docker(比 1.13)也可能有所帮助。

同样的问题在这里
Docker 版本 1.2.6
CentOS 7
@lareeth一样,我们也在使用 kubeadm 时提供 kubernetes 自动化,并且还要求重新启动以完全禁用 selinux 是不可接受的。
@chrisohaver尝试要求重新启动以完全禁用 selinux 是不可接受的。 它有用。 谢谢 !
但据我所知,coredns 选项未在 kubeadm 配置中设置
难道没有别的办法了吗?

尝试从 CoreDNS 部署中删除“allowPrivilegeEscalation: false”,看看是否有帮助。
更新到最新版本的 docker(例如 k8s 推荐的版本)也可能会有所帮助。

我验证从 coredns 部署中删除“allowPrivilegeEscalation:false”可以解决问题(在许可模式下启用 SE linux)。

我还验证了升级到 Kubernetes 推荐的 docker 版本(docker 17.03)可以解决问题,在 coredns 部署中保留“allowPrivilegeEscalation:false”,并在许可模式下启用 SELinux。

因此,旧版本的 docker 和 SELinux 之间似乎存在与 allowPrivilegeEscalation 指令不兼容的问题,该指令显然已在更高版本的 docker 中得到解决。

似乎有3种不同的解决方法:

  • 升级到更新版本的docker,例如17.03,k8s目前推荐的版本
  • 或者从部署的 pod 规范中删除 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 -

@chrisohaver
您是否认为我们应该在 SELinux 节点的kubeadm 故障排除指南中记录以下步骤:


coredns pod 具有CrashLoopBackOffError状态

如果您的节点使用旧版本的 Docker 运行 SELinux,您可能会遇到coredns pod 未启动的情况。 要解决此问题,您可以尝试以下选项之一:

  • 升级到更新版本的 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)

@chrisohaver
明白了,会修改副本并为此提交PR。

在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

Hacky 解决方案:禁用 CoreDNS 循环检测

编辑 CoreDNS 配置图:

kubectl -n kube-system edit configmap coredns

使用loop删除或注释掉该行,保存并退出。

然后删除 CoreDNS pod,以便可以使用新配置创建新的:

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.confsystemd ,请执行以下操作:

查看/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 restart systemd-networkd systemd-resolved

之后,验证DNS=127.0.0.1不再在resolv.conf文件中:

cat /run/systemd/resolve/resolv.conf

最后,触发重新创建 DNS pod

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

简介:该解决方案涉及从主机 DNS 配置中摆脱看起来像 DNS 查找循环的内容。 不同的 resolv.conf 管理器/实现之间的步骤有所不同。

谢谢。 它也包含在 CoreDNS 循环插件自述文件中......

我有同样的问题,还有另一个问题
1、意思是我找不到dns。 错误是
[错误] 插件/错误:2 2115717704248378980.1120568170924441806。 HINFO:无法访问后端:读取 udp 10.224.0.3:57088->8.8.8.8:53:i/o 超时
[错误] 插件/错误:2 2115717704248378980.1120568170924441806。 HINFO:无法访问后端:读取 udp 10.224.0.3:38819->172.16.254.1:53:i/o 超时
...........

我的 /etc/resolv.com
没有
名称服务器 172.16.254.1 #这是我的 dns
nameserver 8.8.8.8 #another dns in net
我跑

kubectl -n kube-system 获取部署 coredns -o yaml | \
sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
kubectl 应用 -f -

然后 pod rebuild 只有一个错误

[错误] 插件/错误:2 10594135170717325.8545646296733374240。 HINFO:无法访问后端:没有上游主机

我不知道这是否正常。 可能是

2、coredns找不到我的api服务。 错误是

kube-dns 无法列出 *v1.Endpoints getsockopt: 10.96.0.1:6443 api 连接被拒绝

coredns一次又一次重启,最后会CrashLoopBackOff

所以我必须在主节点上运行 coredns 我这样做

kubectl 编辑部署/coredns --namespace=kube-system
规范模板规范
节点选择器:
节点角色.kubernetes.io/master:“”

我不知道这是否正常

最后给我的环境

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

码头工人版本:18.09.3

[ root@k8smaster00 ~]# docker image ls -a
存储库标签图像 ID 创建大小
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 个月前 40MB
k8s.gcr.io/etcd 3.2.24 3cab8e1b9802 6 个月前 220MB
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 超时
[错误] 插件/错误:2 2115717704248378980.1120568170924441806。 HINFO:无法访问后端:读取 udp 10.224.0.3:38819->172.16.254.1:53:i/o 超时

这些错误意味着 CoreDNS pod(可能还有所有其他 pod)无法访问您的名称服务器。 这表明您的集群中存在与外界的网络问题。 可能是法兰绒配置错误或防火墙。

coredns 找不到我的 api 服务...
所以我必须在主节点上运行 coredns

这也不正常。 如果我理解正确,您是说 CoreDNS 可以从主节点而不是其他节点联系 API。 这将建议 pod 为集群内节点之间的网络问题提供服务 - 可能是法兰绒配置或防火墙的问题。

我有同样的问题...

@mengxifl ,这些错误与本期报告和讨论的错误有很大不同。

[错误] 插件/错误:2 2115717704248378980.1120568170924441806。 HINFO:无法访问后端:读取 udp 10.224.0.3:57088->8.8.8.8:53:i/o 超时
[错误] 插件/错误:2 2115717704248378980.1120568170924441806。 HINFO:无法访问后端:读取 udp 10.224.0.3:38819->172.16.254.1:53:i/o 超时

这些错误意味着 CoreDNS pod(可能还有所有其他 pod)无法访问您的名称服务器。 这表明您的集群中存在与外界的网络问题。 可能是法兰绒配置错误或防火墙。

coredns 找不到我的 api 服务...
所以我必须在主节点上运行 coredns

这也不正常。 如果我理解正确,您是说 CoreDNS 可以从主节点而不是其他节点联系 API。 这将建议 pod 为集群内节点之间的网络问题提供服务 - 可能是法兰绒配置或防火墙的问题。

感谢你的回复

也许我应该把我的 yaml 文件

我用
kubeadm 初始化 --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

我的 fannel 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]
-A 输入 -p tcp -m tcp --dport 1:65535 -j 接受
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-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 转发 -p tcp -m tcp --dport 1:65535 -j 接受
-A 转发 -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) 字节数据。
来自 13.107.21.200 (13.107.21.200) 的 64 个字节:icmp_seq=2 ttl=111 time=149 ms

uname -rs
主节点说
Linux 4.20.10-1.el7.elrepo.x86_64

uname -rs
从节点说
Linux 4.4.176-1.el7.elrepo.x86_64

所以我认为防火墙没有问题 mybe fannel ? 但我使用默认配置。 也许是 linux 版本。 我不知道 。

好的,我跑
/sbin/iptables -t nat -I POSTROUTING -s 10.224.0.0/16 -j MASQUERADE

在我所有为我工作的节点上。 谢谢

此页面是否有帮助?
0 / 5 - 0 等级