Mein Microk8s-Cluster läuft auf einer CentOS8-VM und ich habe einige Probleme mit der DNS-Auflösung meiner Pods. Die Nameserver sind bei x.x.x.101und x.x.x.100beide sind von den Pods aus pingbar und ich kann auch pingen8.8.8.8
nslookup innerhalb eines Pods sieht folgendermaßen aus:
root@debug-7857894f66-mnklp:/# nslookup kubernetes.default
Server: 10.152.183.10
Address: 10.152.183.10#53
Name: kubernetes.default.svc.cluster.local
Address: 10.152.183.1
Die Coredns-Konfiguration sieht folgendermaßen aus:
apiVersion: v1
data:
Corefile: ".:53 {\n errors\n health {\n lameduck 5s\n }\n ready\n
\ log . {\n class error\n }\n kubernetes cluster.local in-addr.arpa
ip6.arpa {\n pods insecure\n fallthrough in-addr.arpa ip6.arpa\n }\n
\ prometheus :9153\n forward . x.x.x.101 x.x.x.100 \n cache 30\n
\ loop\n reload\n loadbalance\n}\n"
kind: ConfigMap
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","data":{"Corefile":".:53 {\n errors\n health {\n lameduck 5s\n }\n ready\n log . {\n class error\n }\n kubernetes cluster.local in-addr.arpa ip6.arpa {\n pods insecure\n fallthrough in-addr.arpa ip6.arpa\n }\n prometheus :9153\n forward . x.x.x.101 x.x.x.100 \n cache 30\n loop\n reload\n loadbalance\n}\n"},"kind":"ConfigMap","metadata":{"annotations":{},"labels":{"addonmanager.kubernetes.io/mode":"EnsureExists","k8s-app":"kube-dns"},"name":"coredns","namespace":"kube-system"}}
creationTimestamp: "2021-08-31T08:57:27Z"
labels:
addonmanager.kubernetes.io/mode: EnsureExists
k8s-app: kube-dns
name: coredns
namespace: kube-system
resourceVersion: "2420090"
selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
uid: 471b258a-253d-4b51-aaf7-7e934ab300d1
das /etc/resolv.confsieht in meinen Pods so aus:
search default.svc.cluster.local svc.cluster.local cluster.local xxx.xxxxx
nameserver 10.152.183.10
options ndots:5
wenn ich mir die Protokolle meines Kube-DNS anschaue, $ microk8s kubectl logs --namespace=kube-system -l k8s-app=kube-dnserhalte ich die folgende Antwort:
[INFO] 10.1.107.105:47549 - 5288 "AAAA IN www.google.com. udp 36 false 512" NOERROR - 0 0.000256103s
[ERROR] plugin/errors: 2 www.google.com. AAAA: read udp 10.1.107.127:51486->x.x.x.101:53: read: no route to host
DNS-Dienst ist aktiv:
$ microk8s kubectl get svc --namespace=kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
[...]
kube-dns ClusterIP 10.152.183.10 <none> 53/UDP,53/TCP,9153/TCP 21d
DNS-Endpunkte werden verfügbar gemacht:
$ microk8s kubectl get endpoints kube-dns --namespace=kube-system
NAME ENDPOINTS AGE
kube-dns 10.1.107.127:53,10.1.107.127:53,10.1.107.127:9153 21d
Die virtuelle Maschine, auf der der Cluster läuft, verwendet problemlos denselben Nameserver. Muss ich unsere Administratoren deswegen belästigen oder übersehe ich etwas, das falsch konfiguriert ist?
BEARBEITEN:
Okay, ich habe noch ein bisschen mehr ausprobiert und es gibt ein seltsames Verhalten, das meiner Meinung nach damit zu tun hat, dass ich die corednsKonfigurationsdatei falsch erstellt habe. Ich habe den Cluster vollständig zurückgesetzt und es erneut versucht, immer noch derselbe Fehler, wenn ich 8.8.8.8 oder 8.8.4.4 als DNS-Server verwende. Aber wenn ich den folgenden Befehl ausführe: $ microk8s enable dns:x.x.x.101,x.x.x.100funktioniert es endlich. Dann habe ich versucht, dies mit zu konfigurieren $ microk8s kubectl -n kube-system edit configmap/corednsund beide DNS zur Konfiguration hinzuzufügen, es funktioniert nicht mehr und ich erhalte erneut den Fehler: [ERROR] plugin/errors: 2 www.google.com. AAAA: read udp 10.1.107.127:51486->x.x.x.101:53: read: no route to hostWas ist also falsch an meiner Konfiguration, die automatisch richtig mit eingestellt wird $ microk8s enable dns:x.x.x.101,x.x.x.100?
2. Bearbeitung
Ich habe versucht, hier dig zu verwenden, aber wenn ich einen DNS-Server angebe, funktioniert es nicht. Gibt es einen Grund, warum Ping durchgehen könnte, DNS aber vom System blockiert wird? Das passiert nur auf dem microk8s clusterHostsystem, das Fin Docker läuft einwandfrei ... hier sind die Ausdrucke: das hier ist aus dem Pod:
root@debug-865cb7fb4-wfhw4:/# dig www.google.com
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> www.google.com
;; global options: +cmd
;; connection timed out; no servers could be reached
root@debug-865cb7fb4-wfhw4:/# dig @x.x.x.101 www.google.com
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> @x.x.x.101 www.google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
root@debug-865cb7fb4-wfhw4:/# dig @8.8.8.8 www.google.com
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> @8.8.8.8 www.google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
root@debug-865cb7fb4-wfhw4:/# dig @x.x.x.100 www.google.com
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> @x.x.x.100 www.google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
und dies ist vom Hostsystem:
$ dig www.google.com
; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8_3.1 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25735
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.google.com. IN A
;; ANSWER SECTION:
www.google.com. 113 IN A 142.250.185.228
;; Query time: 0 msec
;; SERVER: x.x.x.101#53(x.x.x.101)
;; WHEN: Fri Oct 08 15:10:21 CEST 2021
;; MSG SIZE rcvd: 59
$ dig @8.8.8.8 www.google.com
; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8_3.1 <<>> @8.8.8.8 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3924
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.google.com. IN A
;; ANSWER SECTION:
www.google.com. 300 IN A 142.250.185.228
;; Query time: 34 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Oct 08 15:10:49 CEST 2021
;; MSG SIZE rcvd: 59
$ dig @x.x.x.101 www.google.com
; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8_3.1 <<>> @x.x.x.101 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60305
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.google.com. IN A
;; ANSWER SECTION:
www.google.com. 70 IN A 142.250.185.228
;; Query time: 0 msec
;; SERVER: x.x.x.101#53(x.x.x.101)
;; WHEN: Fri Oct 08 15:11:04 CEST 2021
;; MSG SIZE rcvd: 59
Ich habe keine Ahnung, was hier los zu sein scheint …
Antwort1
Ich habe eine Community-Wiki-Antwort für bessere Sichtbarkeit gepostet.Thagorhat im Kommentar erwähnt, das Problem sei gelöst und bezog sich auf externes DNS:
Ich baue den Cluster in einer Infrastruktur neu auf, die vollständig unter meiner Kontrolle steht und in der DNS funktioniert.
Versuchen Sie, die iptables und die Firewall auf dem Host zu deaktivieren, und prüfen Sie, ob dies über die Coredns-Konfiguration möglich ist.
Weitere Informationen zum DNS finden Sie im offiziellenDokumentation.