CoreDNS ne parvient pas à s'exécuter dans le cluster Kubernetes
J'essaie de configurer un cluster Kubernetes, mais je ne parviens pas à faire fonctionner CoreDNS. J'ai exécuté ce qui suit pour démarrer le cluster:
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 '\n')"
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml
Pour vérifier les POD avec kubectl get pods --all-namespaces, je reçois
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
Donc, CoreDNS ne cesse de planter. Les seuls messages d'erreur que j'ai trouvés provenaient de /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)"
et à partir de 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
Certaines solutions que j'ai trouvées sont à émettre
kubectl -n kube-system get deployment coredns -o yaml | \
sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
kubectl apply -f -
et de modifier /etc/resolv.conf pour qu'il pointe vers un DNS réel, et non vers localhost, ce que j'ai également essayé.
Le problème est décrit dans https://kubernetes.io/docs/setup/independent/troubleshooting-kubeadm/#pods-in-runcontainererror-crashloopbackoff-or-error-state et j'ai essayé plusieurs réseaux de pods différents Aidez-moi.
J'ai exécuté Sudo kubeadm reset && rm -rf ~/.kube/ && Sudo kubeadm init plusieurs fois.
Je suis sous Ubuntu 16.04, Kubernetes 1.12 et Docker 17.03. Des idées?
J'ai aussi le même problème.
je résous le problème en supprimant la "boucle" des plugins dans le cm de coredns . mais je ne sais pas si ce nuage a d'autres cas.
1 kubectl modifier cm coredns -n kube-system
2 supprimer ‘boucle’, enregistrer et quitter
3 、 redémarrez coredns pods by ： "kubctel delete pod coredns .... -n kube-system"
Un peu résolu en utilisant cette façon:
- ouvrez et éditez le configmap de coredns .
kubectl edit cm coredns -n kube-system - "remplacement du proxy. /etc/resolv.conf par l’adresse IP de votre DNS en amont, par exemple le proxy. 8.8.8.8." Selon le lien dans la sortie de The coredns log (à la fin de la page)
- sauvegarder et quitter.
kubectl obtenir des pods -n kube-system -oname | grep coredns | xargs kubectl delete -n kube-system
La raison du problème est expliquée dans le link . Vous pouvez trouver ce lien dans la sortie de cette cmd
kubectl enregistre coredns-7d9cd4f75b-cpwxp -n système kube
Ce lien se trouve dans la sortie de CoreDNS-1.2.4.
J'améliore le CoreDNS en utilisant cette cmd
déploiement du correctif kubectl -n = kube-system coredns -p '{"spéc": {"modèle": {"spéc": {"conteneurs": [{"image": "k8s.gcr.io/coredns:1.2. 4 "," name ":" coredns "," resources ": {" limits ": {" memory ":" 1Gi "}," requêtes ": {" cpu ":" 100m "," memory ":" 70Mi " }}}]}}}} '
Oui, tu as raison. La question a été décrite ici et sur GitHub . Et la solution consiste à mettre à niveau Docker, à désactiver SElinux ou à modifier allowPrivilegeEscalation en true. Cependant, aujourd’hui, j’ai essayé de reproduire votre problème et je n’étais pas capable de le faire . En vous fournissant des commandes et une sortie, peut-être que vous aider à créer une version de travail depuis le début.
Docker version 17.03.2-ce, Kubernetes v1.12.0, Ubuntu 16.04, CoreDNS-1.2.2, instance créée dans GCP.
#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 '\n')"
compte de service/réseau-tissage créé
clusterrole.rbac.authorization.k8s.io/weave-net créé
clusterrolebinding.rbac.authorization.k8s.io/weave-net créé
role.rbac.authorization.k8s.io/weave-net créé
rolebinding.rbac.authorization.k8s.io/weave-net créé
daemonset.extensions/weave-net créé
$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
Et encore dans une 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
Description de la corède:
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
Indiquez également votre config.yaml utilisé par kubeadm init --config config.yaml pour mieux comprendre votre problème avec la spécification de l'emplacement du fichier de configuration.
Je pense que simplement supprimer la fonction loop de Kubernetes n’est pas une approche propre. CoreDNS Github fournit en fait des instructions pour résoudre ce problème.
Ils suggèrent dans leur directive environ 3 approches
- Ajoutez ce qui suit à kubelet: --resolv-conf. Votre "vrai" resolv.conf est celui qui contient les adresses IP réelles de vos serveurs en amont, et aucune adresse locale/bouclée. Cet indicateur indique à kubelet de transmettre un autre fichier resolv.conf aux pods. Pour les systèmes utilisant systemd-resolu, /run/systemd/resolve/resolv.conf correspond généralement à l'emplacement du "réel" resolv.conf, même s'il peut varier en fonction de votre distribution.
- Désactivez le cache DNS local sur les nœuds hôtes et restaurez le fichier /etc/resolv.conf à l'original.
- Une solution rapide et incorrecte consiste à modifier votre fichier Corefile, en remplacement du proxy. /etc/resolv.conf avec l'adresse IP de votre DNS en amont, par exemple un proxy. 8.8.8.8. Mais cela ne résout que le problème pour CoreDNS, kubelet continuera à transmettre le résolv.conf non valide à tous les pods dnsPolicy par défaut, les empêchant de résoudre le DNS.
J'ai aussi le même problème.
**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 ~]#