CoreDNS kann nicht im Kubernetes-Cluster ausgeführt werden

Question

Ich versuche, einen Kubernetes-Cluster einzurichten, CoreDNS kann jedoch nicht ausgeführt werden. Ich habe folgendes ausgeführt, um den Cluster zu starten:

Sudo swapoff -a Sudo sysctl net.bridge.bridge-nf-call-iptables=1 Sudo kubeadm init mkdir -p $HOME/.kube Sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config Sudo chown $(id -u):$(id -g) $HOME/.kube/config kubectl apply -f "https://cloud.weave.works/k8s/net?k8s- version=$(kubectl version | base64 | tr -d '
')" kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml

Um die PODs mit kubectl get pods --all-namespaces zu überprüfen, bekomme ich

NAMESPACE NAME READY STATUS RESTARTS AGE kube-system coredns-68fb79bcf6-6s5bp 0/1 CrashLoopBackOff 6 10m kube-system coredns-68fb79bcf6-hckxq 0/1 CrashLoopBackOff 6 10m kube-system etcd-myserver 1/1 Running 0 79m kube-system kube-apiserver-myserver 1/1 Running 0 79m kube-system kube-controller-manager-myserver 1/1 Running 0 79m kube-system kube-proxy-9ls64 1/1 Running 0 80m kube-system kube-scheduler-myserver 1/1 Running 0 79m kube-system kubernetes-dashboard-77fd78f978-tqt8m 1/1 Running 0 80m kube-system weave-net-zmhwg 2/2 Running 0 80m

So stürzt CoreDNS immer wieder ab. Die einzigen Fehlermeldungen, die ich finden konnte, waren von /var/log/syslog:

Oct 4 18:06:44 myserver kubelet[16397]: E1004 18:06:44.961409 16397 pod_workers.go:186] Error syncing pod c456a48b-c7c3-11e8-bf23-02426706c77f ("coredns-68fb79bcf6-6s5bp_kube-system(c456a48b-c7c3-11e8-bf23-02426706c77f)"), skipping: failed to "StartContainer" for "coredns" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=coredns pod=coredns-68fb79bcf6-6s5bp_kube-system(c456a48b-c7c3-11e8-bf23-02426706c77f)"

und von kubectl logs coredns-68fb79bcf6-6s5bp -n kube-system:

.:53 2018/10/04 11:04:55 [INFO] CoreDNS-1.2.2 2018/10/04 11:04:55 [INFO] linux/AMD64, go1.11, eb51e8b CoreDNS-1.2.2 linux/AMD64, go1.11, eb51e8b 2018/10/04 11:04:55 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769 2018/10/04 11:04:55 [FATAL] plugin/loop: Seen "HINFO IN 3256902131464476443.1309143030470211725." more than twice, loop detected

Einige Lösungen, die ich gefunden habe, sind auszugeben

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

und /etc/resolv.conf so ändern, dass er auf einen tatsächlichen DNS verweist, nicht auf localhost, was ich auch versucht habe.

Das Problem ist beschrieben in https://kubernetes.io/docs/setup/independent/trtenance-kubeadm/#pods-in-runcontainererror-crashloopbackoff-or-error-state Hilfe.

Ich habe Sudo kubeadm reset && rm -rf ~/.kube/ && Sudo kubeadm init mehrmals ausgeführt.

Ich verwende Ubuntu 16.04, Kubernetes 1.12 und Docker 17.03. Irgendwelche Ideen?

J.OwenShuo · Answer

Ich habe auch das gleiche Problem.

ich löse das problem, indem ich die plugins 'loop' innerhalb der cm von coredns lösche . aber ich weiß nicht, ob diese wolke andere porblems enthält.

1 、 kubectl edit cm coredns -n kube-system

2 、 "Schleife" löschen, speichern und beenden

3. Starten Sie Coredns Pods von ： "kubctel Delete Pod Coredns .... -n kube-system"

Richard Li · Answer

Mit diesem Weg etwas gelöst:

Öffnen und bearbeiten Sie die Configmap von coredns .

kubectl edit cm coredns -n kube-system
"Ersetzen von Proxy. /etc/resolv.conf durch die IP-Adresse Ihres Upstream-DNS, beispielsweise Proxy. 8.8.8.8." Entsprechend dem Link in der Ausgabe von Des Coredns Log (am Ende der Seite)
speichern und schließen.
kubectl get pods -n kube-system -name | grep coredns | xargs kubectl delete -n kube-system

Die Ursache des Problems wird in link ..__ erläutert. Sie finden diesen Link in der Ausgabe dieses Cmd

kubectl protokolliert coredns-7d9cd4f75b-cpwxp -n kube-system

Diese Verknüpfung befindet sich in der Ausgabe des CoreDNS-1.2.4.

Ich aktualisiere das CoreDNS mit dieser cmd

bereitstellung des Patches für kubectl -n = kube-system coredns -p '{"spec": {"template": {"spec": {"container": [{"image": "k8s.gcr.io/coredns:1.2. 4 "," name ":" coredns "," resources ": {" limits ": {" memory ":" 1Gi "}," request ": {" cpu ":" 100m "," memory ":" 70Mi " }}}}}}}}

VKR · Answer

Ja, du hast recht. Das Problem wurde here und auf GitHub beschrieben. Die Lösung besteht darin, Docker zu aktualisieren, SElinux zu deaktivieren oder allowPrivilegeEscalation in true..__ zu ändern. Heute habe ich jedoch versucht, Ihr Problem zu reproduzieren und konnte dies nicht Hilfe beim Erstellen einer Arbeitsversion von Anfang an.

Docker-Version 17.03.2-ce, Kubernetes v1.12.0, Ubuntu 16.04, CoreDNS-1.2.2, in GCP erstellte Instanz.

#apt-get update && apt-get install -y mc ebtables ethtool docker.io apt-transport-https curl #curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - #cat <<EOF >/etc/apt/sources.list.d/kubernetes.list \ deb http://apt.kubernetes.io/ kubernetes-xenial main \ EOF #apt-get update && apt-get install -y kubelet kubeadm kubectl #kubeadm init $mkdir -p $HOME/.kube $Sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config $Sudo chown $(id -u):$(id -g) $HOME/.kube/config $kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '
')"

serviceaccount/weave-net erstellt

clusterrole.rbac.authorization.k8s.io/weave-net erstellt

clusterrolebinding.rbac.authorization.k8s.io/weave-net erstellt

role.rbac.authorization.k8s.io/weave-net erstellt

rolebinding.rbac.authorization.k8s.io/weave-net erstellt

daemonset.extensions/weave-net erstellt

$kubectl get pods --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE kube-system pod/coredns-576cbf47c7-6qbtq 0/1 Pending 0 79s kube-system pod/coredns-576cbf47c7-jr6hb 0/1 Pending 0 79s kube-system pod/etcd-kube-weave-master-1 1/1 Running 0 38s kube-system pod/kube-apiserver-kube-weave-master-1 1/1 Running 0 28s kube-system pod/kube-controller-manager-kube-weave-master-1 1/1 Running 0 30s kube-system pod/kube-proxy-4p9l5 1/1 Running 0 79s kube-system pod/kube-scheduler-kube-weave-master-1 1/1 Running 0 34s kube-system pod/weave-net-z6mhw 0/2 ContainerCreating 0 8s

Und noch einmal in einer Minute:

$kubectl get pods --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE kube-system pod/coredns-576cbf47c7-6qbtq 1/1 Running 0 98s kube-system pod/coredns-576cbf47c7-jr6hb 1/1 Running 0 98s kube-system pod/etcd-kube-weave-master-1 1/1 Running 0 57s kube-system pod/kube-apiserver-kube-weave-master-1 1/1 Running 0 47s kube-system pod/kube-controller-manager-kube-weave-master-1 1/1 Running 0 49s kube-system pod/kube-proxy-4p9l5 1/1 Running 0 98s kube-system pod/kube-scheduler-kube-weave-master-1 1/1 Running 0 53s kube-system pod/weave-net-z6mhw 2/2 Running 0 27s

Coredns Pod Beschreibung:

kubectl describe pod/coredns-576cbf47c7-6qbtq -n kube-system Name: coredns-576cbf47c7-6qbtq Namespace: kube-system Priority: 0 PriorityClassName: <none> Node: kube-weave-master-1/10.154.0.8 Start Time: Fri, 05 Oct 2018 11:06:54 +0000 Labels: k8s-app=kube-dns pod-template-hash=576cbf47c7 Annotations: <none> Status: Running IP: 10.32.0.3 Controlled By: ReplicaSet/coredns-576cbf47c7 Containers: coredns: Container ID: docker://db1712600b4c927b99063fa41bc36c3346c55572bd63730fc993f03379fa457b Image: k8s.gcr.io/coredns:1.2.2 Image ID: docker-pullable://k8s.gcr.io/coredns@sha256:3e2be1cec87aca0b74b7668bbe8c02964a95a402e45ceb51b2252629d608d03a Ports: 53/UDP, 53/TCP, 9153/TCP Host Ports: 0/UDP, 0/TCP, 0/TCP Args: -conf /etc/coredns/Corefile State: Running Started: Fri, 05 Oct 2018 11:06:57 +0000 Ready: True Restart Count: 0 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-wp7tm (ro) Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True Volumes: config-volume: Type: ConfigMap (a volume populated by a ConfigMap) Name: coredns Optional: false coredns-token-wp7tm: Type: Secret (a volume populated by a Secret) SecretName: coredns-token-wp7tm 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 23m (x12 over 24m) default-scheduler 0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate. Normal Scheduled 23m default-scheduler Successfully assigned kube-system/coredns-576cbf47c7-6qbtq to kube-weave-master-1 Normal Pulled 23m kubelet, kube-weave-master-1 Container image "k8s.gcr.io/coredns:1.2.2" already present on machine Normal Created 23m kubelet, kube-weave-master-1 Created container Normal Started 23m kubelet, kube-weave-master-1 Started container

Geben Sie außerdem Ihren config.yaml an, der von kubeadm init --config config.yaml verwendet wird, um Ihr Problem bei der Angabe des Speicherorts der Konfigurationsdatei besser zu verstehen.

Jiashen Cao · Answer

Ich denke, einfach die Funktion loop von Kubernetes löschen ist kein sauberer Ansatz. CoreDNS Github enthält einige Richtlinien zur Fehlerbehebung für dieses Problem.

Sie schlagen in ihrer Richtlinie drei Ansätze vor

Fügen Sie kubelet folgendes hinzu: --resolv-conf. Ihre "echte" resolv.conf ist die, die die tatsächlichen IPs Ihrer Upstream-Server und keine lokale/Loopback-Adresse enthält. Dieses Flag weist kubelet an, eine alternative resolv.conf an Pods zu übergeben. Bei Systemen, die systemd-resolution verwenden, ist /run/systemd/resolve/resolv.conf normalerweise der Speicherort der "echten" resolv.conf, obwohl dies je nach Ihrer Distribution unterschiedlich sein kann.

Deaktivieren Sie den lokalen DNS-Cache auf den Hostknoten und stellen Sie die Datei /etc/resolv.conf auf dem ursprünglichen Wert wieder her.

Eine schnelle und schmutzige Lösung besteht darin, Ihr Corefile zu bearbeiten und Proxy zu ersetzen. /etc/resolv.conf mit der IP-Adresse Ihres Upstream-DNS, z. B. Proxy. 8.8.8.8. Dies behebt jedoch nur das Problem für CoreDNS, da kubelet die ungültige resolv.conf weiterhin an alle standardmäßigen dnsPolicy-Pods weiterleitet, sodass DNS nicht aufgelöst werden kann.

luisfernando · Answer

Meine Lösung war, --network-plugin=cni In /var/lib/kubelet/kubeadm-flags.env Zu löschen.

Dean · Answer

Ich habe auch das gleiche Problem.

**Running**: 1 master + 2 nodes (all on Red Hat Enterprise Linux Server release 7.5 (Maipo)) **Docker**: 18.06.1-ce **Kubernete**s- Client Version: v1.12.0 Server Version: v1.12.0 **Core DNS**: CoreDNS-1.2.2 **Errors**: [root@kubemast ~]# kubectl logs coredns-68fb79bcf6-2lk8k -n=kube-system .:53 2018/10/05 15:14:30 [INFO] CoreDNS-1.2.2 2018/10/05 15:14:30 [INFO] linux/AMD64, go1.11, eb51e8b CoreDNS-1.2.2 linux/AMD64, go1.11, eb51e8b 2018/10/05 15:14:30 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769 2018/10/05 15:14:36 [FATAL] plugin/loop: Seen "HINFO IN 5745769668098465527.4020143478923175228." more than twice, loop detected [root@kubemast ~]#