Aici a început investigația: CoreDNS nu a putut funcționa mai mult de câteva secunde, dând următoarele erori:
$ kubectl obține pods --all-namespaces
SPAȚIUL DE NUMELE NUMELE STAREA PREGĂTITĂ REINCEPE VÂRSTA
ingress-nginx ingress-nginx-controller-8xcl9 1/1 Rulează 0 11h
ingress-nginx ingress-nginx-controller-hwhvk 1/1 Rulează 0 11h
ingress-nginx ingress-nginx-controller-xqdqx 1/1 Running 2 (acum 10 ore) 11 ore
kube-system calico-kube-controllers-684bcfdc59-cr7hr 1/1 Rulează 0 11h
kube-system calico-node-62p58 1/1 Running 2 (acum 10 ore) 11 ore
kube-system calico-node-btvdh 1/1 Running 0 11h
kube-system calico-node-q5bkr 1/1 Running 0 11h
kube-system coredns-8474476ff8-dnt6b 0/1 CrashLoopBackOff 1 (acum 3 s) 5 s
kube-system coredns-8474476ff8-ftcbx 0/1 Eroare 1 (acum 2 s) 5 s
kube-system dns-autoscaler-5ffdc7f89d-4tshm 1/1 Running 2 (acum 10 ore) 11 ore
kube-system kube-apiserver-hyzio 1/1 Running 4 (acum 10 ore) 11 ore
kube-system kube-controller-manager-hyzio 1/1 Running 4 (acum 10 ore) 11 ore
kube-system kube-proxy-2d8ls 1/1 Running 0 11h
kube-system kube-proxy-c6c4l 1/1 Running 4 (acum 10 ore) 11 ore
kube-system kube-proxy-nzqdd 1/1 Running 0 11h
kube-system kube-scheduler-hyzio 1/1 Running 5 (acum 10 ore) 11 ore
kube-system kubernetes-dashboard-548847967d-66dwz 1/1 Rulează 0 11 ore
kube-system kubernetes-metrics-scraper-6d49f96c97-r6dz2 1/1 Rulare 0 11h
kube-system nginx-proxy-dyzio 1/1 Running 0 11h
kube-system nginx-proxy-zyzio 1/1 Rulează 0 11h
kube-system nodelocaldns-g9wxh 1/1 Rulează 0 11h
kube-system nodelocaldns-j2qc9 1/1 Running 4 (acum 10 ore) 11 ore
kube-system nodelocaldns-vk84j 1/1 Rulează 0 11 ore
kube-system registry-j5prk 1/1 Rulează 0 11h
kube-system registry-proxy-5wbhq 1/1 Rulează 0 11 ore
kube-system registry-proxy-77lqd 1/1 Rulează 0 11 ore
kube-system registry-proxy-s45p4 1/1 Running 2 (acum 10 ore) 11 ore
kubectl descrie pe acel pod nu a adus mare lucru în imagine:
Evenimente:
Introduceți Motivul Vârsta din mesaj
---- ------ ---- ---- -------
Programator normal programat 67s implicit Alocat cu succes kube-system/coredns-8474476ff8-dnt6b către zyzio
Normal Pulled 25s (x4 over 68s) Kubelet Container imagine „k8s.gcr.io/coredns/coredns:v1.8.0” deja prezentă pe mașină
Normal Creat 25s (x4 peste 68s) kubelet Creat container coredns
Normal Started 25s (x4 over 68s) Kubelet Started container coredns
Avertisment BackOff 6s (x11 over 66s) kubelet Back-off repornirea containerului eșuat
Dar vizualizarea jurnalelor a făcut:
$ kubectl jurnalele coredns-8474476ff8-dnt6b -n kube-system
.:53
[INFO] plugin/reîncărcare: rulează configurația MD5 = 5b233a0166923d642fdbca0794b712ab
CoreDNS-1.8.0
linux/amd64, go1.15.3, 054c9ae
[FATAL] plugin/loop: Bucla (127.0.0.1:49048 -> :53) detectată pentru zona „.”, vezi https://coredns.io/plugins/loop#troubleshooting.Interogare: „HINFO 2906344495550081187.9117452939332601176”.
Este grozav că documentația de depanare a fost legată! Am început să răsfoiesc acea pagină și am descoperit că într-adevăr al meu /etc/resolv.conf conținea IP local problematic serverul de nume 127.0.0.53.
De asemenea, am gasit real IP-uri DNS în /run/systemd/resolve/resolv.conf, dar întrebarea acum este: cum să efectuați acțiunea descrisă în documentația de depanare, spunând:
Adăugați următoarele în configurația kubelet yaml: resolvConf: (sau prin marcajul liniei de comandă --resolv-conf depreciat în 1.10). Soluția dvs. ârealâ este cea care conține IP-urile reale ale serverelor dvs. din amonte și nicio adresă locală/loopback. Acest steag îi spune lui Kubelet să transmită un soluționator alternativ la Pods. Pentru sistemele care utilizează systemd-resolved, /run/systemd/resolve/resolv.conf este de obicei locația „real” resolv.conf, deși aceasta poate fi diferită în funcție de distribuția dvs.
Deci, intrebarile sunt:
- cum să găsești sau unde să creezi yaml de configurare kubelet menționat,
- la ce nivel ar trebui să precizez
rezolvConf valoare, și
- poate accepta mai multe valori? Am două servere de nume definite. Ar trebui să fie date ca intrări separate sau o matrice?
