Kubeadm: CoreDNSはk8s1.11およびweave（CentOS 7）で開始されていません
これはバグレポートですか、それとも機能リクエストですか？
バグレポート
バージョン
kubeadmバージョン1.11
環境：
- Kubernetesバージョン（
kubectl versionを使用）：1.11 - クラウドプロバイダーまたはハードウェア構成：aws ec2 with（16vcpus 64gb RAM）
- OS （例：/ etc / os-releaseから）：centos 7
- カーネル（例：
uname -a）：3.10.0-693.17.1.el7.x86_64 - その他：cniアドオンとして織ります
どうしたの？
kubeadm initの後、coreosポッドはエラーのままになります
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
両方のポッドのログは次のことを示しています。
standard_init_linux.go:178: exec user process caused "operation not permitted"
carlosrmendes
全てのコメント33件
@ kubernetes / sig-network-bugs
@ carlosmkb 、Dockerのバージョンは何ですか？
neolit123
2018年07月17日
これは信じがたいことです。私たちはCentOS7をかなり広範囲にテストしています。
システムとポッドのログはありますか？
timothysc
2018年07月17日
dims
2018年07月17日
@dims 、意味があります、私は試してみます
@ neolit123と@timothysc
dockerバージョン：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」を削除して、それが役立つかどうかを確認してみてください。
chrisohaver
2018年07月19日
私にとっても同じ問題です。 同様のセットアップCentOS7.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"
sectorsize512
2018年07月19日
念のため、selinuxはすべてのノードで許可モードになっています。
sectorsize512
2018年07月19日
私はCalicoを使用しています（@carlosmkbとして織りません）。
sectorsize512
2018年07月19日
[ root @ faas-A01〜 ] ＃kubectlログ--namespace = kube-system coredns-78fcdf6894-p4wbl
standard_init_linux.go：178：execユーザープロセスが「操作が許可されていません」を引き起こしました
ああ-これは、ログの内容ではなく、ログを取得しようとしたときのkubectlからのエラーです...
chrisohaver
2018年07月23日
@chrisohaver kubectl logsは別のkubeシステムポッドで動作します
carlosrmendes
2018年07月23日
OK-CoreDNSデプロイメントから「allowPrivilegeEscalation：false」を削除して、それが役立つかどうかを確認しましたか？
chrisohaver
2018年07月23日
... corednsポッドのkubectl describeは何か面白いものを示していますか？
chrisohaver
2018年07月23日
私にとっても同じ問題です。
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
Leozki
2018年07月26日
selinuxがpersmissiveモードのときに同じ問題が発生します。 / etc / selinux / conf SELINUX = disableで無効にしてマシンを再起動すると、ポッドが起動します。
Redhat 7.4、カーネル3.10.0-693.11.6.el7.x86_64
docker-1.13.1-68.gitdded712.el7.x86_64
zimnyjakub
2018年07月27日
参考までに、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を完全に無効にするために再起動を要求することは受け入れられません。 これが修正されるのを待つ理由は他にありますか？
lareeth
2018年07月30日
CoreDNSデプロイメントから「allowPrivilegeEscalation：false」を削除してみて、それが役立つかどうかを確認してください。
最新バージョンのdocker（1.13より）に更新することも役立つ場合があります。
chrisohaver
2018年07月30日
ここで同じ問題
Dockerバージョン1.2.6
CentOS 7
@lareethと同様に、kubeadmの使用時にkubernetesの自動化もプロビジョニングします。また、selinuxを完全に無効にするために再起動を要求することは受け入れられません。
@chrisohaverは、selinuxを完全に無効にするために再起動を要求することは受け入れられません。 それは役に立ちます。 ありがとう ！
しかし、私が知っているように、corednsオプションはkubeadm構成で設定されていません
他に方法はありませんか？
thdrnsdk
2018年08月01日
CoreDNSデプロイメントから「allowPrivilegeEscalation：false」を削除してみて、それが役立つかどうかを確認してください。
Dockerの最新バージョン（k8sで推奨されているバージョンなど）に更新することも役立つ場合があります。
chrisohaver
2018年08月01日
corednsデプロイメントから「allowPrivilegeEscalation：false」を削除すると問題が解決することを確認しました（SE linuxが許可モードで有効になっている場合）。
chrisohaver
2018年08月01日
また、Kubernetesが推奨するバージョンのdocker（docker 17.03）にアップグレードすると、corednsデプロイメントに「allowPrivilegeEscalation：false」が残り、SELinuxが許可モードで有効になるという問題が解決することを確認しました。
chrisohaver
2018年08月01日
そのため、古いバージョンのdockerとSELinuxの間に、後のバージョンのdockerで明らかに解決されたallowPrivilegeEscalationディレクティブとの非互換性があるように見えます。
3つの異なる回避策があるようです。
- Dockerの新しいバージョン（17.03など、現在k8sで推奨されているバージョン）にアップグレードします
- または、デプロイメントのポッド仕様からallowPrivilegeEscalation = falseを削除します
- またはSELinuxを無効にする
chrisohaver
2018年08月01日
@chrisohaver新しいバージョンのdocker17.03にアップグレードすることで、問題を解決しました。 どうも
Leozki
2018年08月01日
調査してくれてありがとう@chrisohaver ：100：
neolit123
2018年08月01日
ありがとう、 @ chrisohaver ！
これはうまくいきました：
kubectl -n kube-system get deployment coredns -o yaml | \
sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
kubectl apply -f -
kuznero
2018年08月10日
@chrisohaver
このステップを、SELinuxノードのkubeadmトラブルシューティングガイドの次の行に文書化する必要があると思いますか？
corednsポッドにはCrashLoopBackOffまたはErrorの状態があります
古いバージョンのDockerでSELinuxを実行しているノードがある場合、 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？ 何か改善できると思われる場合は、テキストの修正を提案してください。
neolit123
2018年08月10日
それはいいです。 SELinuxを無効にしたり、allowPrivilegeEscalation設定を変更したりすると、セキュリティに悪影響が及ぶ可能性があることに注意してください。
最も安全なソリューションは、DockerをKubernetesが推奨するバージョン（17.03）にアップグレードすることです。
chrisohaver
2018年08月10日
@chrisohaver
理解し、コピーを修正し、このためのPRを提出します。
neolit123
2018年08月10日
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です-systemdresolv.confが使用されているかどうかを判断します。
systemdのresolv.confの場合は、次のようにします。
/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を確認し、必要に応じて同じことを行います。 次のように、少なくとも1つまたは2つのDNSサーバーが構成されていることを確認してください。
DNS=1.1.1.1 1.0.0.1
それをすべて行った後、systemdサービスを再起動して、変更を有効にします。
systemctl restart systemd-networkdsystemd-解決済み
その後、 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マネージャー/実装ごとに異なります。
mydockergit
2019年01月23日
ありがとう。 CoreDNSループプラグインのreadmeでも説明されています...
chrisohaver
2019年01月23日
私は同じ問題を抱えています、そして別の問題があります
1、dnsが見つからないことを意味します。 エラーは
[エラー]プラグイン/エラー：22115717704248378980.1120568170924441806。 HINFO：到達不能なバックエンド：UDP 10.224.0.3:57088->8.8.8.8:53を読み取ります：i / oタイムアウト
[エラー]プラグイン/エラー：22115717704248378980.1120568170924441806。 HINFO：到達不能なバックエンド：UDP 10.224.0.3:38819->172.16.254.1:53を読み取ります：i / oタイムアウト
.......。
私の/etc/resolv.com
ない
nameserver 172.16.254.1＃これは私のDNSです
nameserver 8.8.8.8 #another dns in net
走る
kubectl -n kube-system get deploy coredns -o yaml | \
sed's / allowPrivilegeEscalation：false / allowPrivilegeEscalation：true / g '| \
kubectl apply -f-
その後、ポッドの再構築でエラーが1つだけ発生します
[エラー]プラグイン/エラー：210594135170717325.8545646296733374240。 HINFO：到達不能なバックエンド：アップストリームホストがありません
それが正常かどうかはわかりません。 多分
2、corednsは私のAPIサービスを見つけることができません。 エラーは
kube-dnsリストに失敗しました* v1.Endpoints getockopt：10.96.0.1：6443api接続が拒否されました
corednsは何度も再起動し、ついにCrashLoopBackOffになります
マスターノードでcorednsを実行する必要があります
kubectl edit deploy / coredns --namespace = kube-system
spec.template.spec
nodeSelector：
node-role.kubernetes.io/master： ""
それが正常かどうかはわかりません
ついに私の環境を与える
Linux 4.20.10-1.el7.elrepo.x86_64 /// centos 7
dockerバージョン：18.09.3
[ root @ k8smaster00〜 ] ＃docker image ls -a
リポジトリタグの画像ID作成サイズ
k8s.gcr.io/kube-controller-manager v1.13.3 0482f64009336週間前146MB
k8s.gcr.io/kube-proxy v1.13.3 98db19758ad46週間前80.3MB
k8s.gcr.io/kube-apiserver v1.13.3 fe242e556a996週間前181MB
k8s.gcr.io/kube-scheduler v1.13.3 3a6f709e97a06週間前79.6MB
quay.io/coreos/flannel v0.11.0-amd64 ff281650a7217週間前52.6MB
k8s.gcr.io/coredns 1.2.6 f59dcacceff44か月前40MB
k8s.gcr.io/etcd 3.2.24 3cab8e1b98026か月前220MB
k8s.gcr.io/pause 3.1 da86e6ba6ca115か月前742kB
kubenetsは1.13.3です
これはバグだと思います公式アップデートまたは解決策を期待してください
mengxifl
2019年03月20日
私は同じ問題を抱えています...
@mengxifl 、これらのエラーは、この問題で報告および説明されているエラーとは大幅に異なります。
[エラー]プラグイン/エラー：22115717704248378980.1120568170924441806。 HINFO：到達不能なバックエンド：UDP 10.224.0.3:57088->8.8.8.8:53を読み取ります：i / oタイムアウト
[エラー]プラグイン/エラー：22115717704248378980.1120568170924441806。 HINFO：到達不能なバックエンド：UDP 10.224.0.3:38819->172.16.254.1:53を読み取ります：i / oタイムアウト
これらのエラーは、CoreDNSポッド（およびおそらく他のすべてのポッド）がネームサーバーに到達できないことを意味します。 これは、クラスター内のネットワークの問題が外部にあることを示しています。 フランネルの設定ミスまたはファイアウォールの可能性があります。
corednsが私のAPIサービスを見つけることができません...
マスターノードでcorednsを実行する必要があります
これも正常ではありません。 私があなたを正しく理解しているなら、あなたはCoreDNSがマスターノードからAPIに接続できるが、他のノードからは接続できないと言っています。 これは、クラスター内のノード間のポッドからサービスへのネットワークの問題を示唆します。おそらく、フランネル構成またはファイアウォールの問題です。
chrisohaver
2019年03月20日
私は同じ問題を抱えています...
@mengxifl 、これらのエラーは、この問題で報告および説明されているエラーとは大幅に異なります。
[エラー]プラグイン/エラー：22115717704248378980.1120568170924441806。 HINFO：到達不能なバックエンド：UDP 10.224.0.3:57088->8.8.8.8:53を読み取ります：i / oタイムアウト
[エラー]プラグイン/エラー：22115717704248378980.1120568170924441806。 HINFO：到達不能なバックエンド：UDP 10.224.0.3:38819->172.16.254.1:53を読み取ります：i / oタイムアウトこれらのエラーは、CoreDNSポッド（およびおそらく他のすべてのポッド）がネームサーバーに到達できないことを意味します。 これは、クラスター内のネットワークの問題が外部にあることを示しています。 フランネルの設定ミスまたはファイアウォールの可能性があります。
corednsが私のAPIサービスを見つけることができません...
マスターノードでcorednsを実行する必要がありますこれも正常ではありません。 私があなたを正しく理解しているなら、あなたはCoreDNSがマスターノードからAPIに接続できるが、他のノードからは接続できないと言っています。 これは、クラスター内のノード間のポッドからサービスへのネットワークの問題を示唆します。おそらく、フランネル構成またはファイアウォールの問題です。
お返事ありがとうございます
多分私は私の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
私のファンネルyamlはデフォルトです
https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
systemctl status firewalld
すべてのノードは言う
ユニットfirewalld.serviceが見つかりませんでした。
cat /etc/sysconfig/iptables
すべてのノードは言う
*フィルター
：INPUT ACCEPT [0：0]
：FORWARD ACCEPT [0：0]
：OUTPUT ACCEPT [0：0]
-A INPUT -p tcp -m tcp --dport 1：65535 -j ACCEPT
-A INPUT -m state --state RELATED、ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 1：65535 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 1：65535 -j ACCEPT
-A FORWARD -p tcp -m tcp --sport 1：65535 -j ACCEPT
COMMI
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ファンネルを発行しているとは思わないのですか？ しかし、私はデフォルトの設定を使用します。 そして多分Linuxバージョン。 わからない 。
OK実行します/sbin/iptables -t nat -I POSTROUTING -s 10.224.0.0/16 -j MASQUERADE
私のために働くすべての私のノードで。 ありがとう
mengxifl
2019年03月21日
関連する問題
cnmade
·
4コメント
jbrandes
·
4コメント
luxas
·
3コメント
imedaouidene
·
3コメント
mattmoyer
·
4コメント
最も参考になるコメント
ありがとう、 @ chrisohaver ！
これはうまくいきました：