Hinweis.: Das DNS-Problem in Kubernetes, genauer gesagt — die Einstellung des Parameters ndots, — ist überraschend populär und das bereits . In einem weiteren Artikel zu diesem Thema erklärt der Autor — ein DevOps-Ingenieur aus einer großen Brokerfirma in Indien — auf sehr einfache und prägnante Weise, was Kolleginnen und Kollegen, die Kubernetes betreiben, nützlich wissen sollten.
Einer der größten Vorteile beim Bereitstellen von Anwendungen in Kubernetes ist die mühelose Entdeckung von Anwendungen. Die interne Clusterkommunikation wird Dank des Konzepts des Dienstes (), welcher eine virtuelle IP repräsentiert, die eine Gruppe von Pod-IP-Adressen unterstützt, erheblich vereinfacht. Zum Beispiel, wenn der Dienst vanilla den Dienst chocolate, kontaktieren möchte, kann er direkt die virtuelle IP für chocolateansprechen. Die Frage ist: Wer wird in diesem Fall die DNS-Anfrage an chocolate auflösen und wie?
Die DNS-Namensauflösung wird im Kubernetes-Cluster mittels konfiguriert. Kubelet trägt den Pod mit CoreDNS als Nameserver in den Dateien /etc/resolv.conf aller Pods ein. Wenn man den Inhalt von /etc/resolv.conf einem beliebigen Pod betrachtet, wird dieser ungefähr folgendermassen aussehen:
search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5 Diese Konfiguration wird von DNS-Clients verwendet, um Anfragen an den DNS-Server umzuleiten. In der Datei resolv.conf befindet sich die folgende Information:
- nameserver: der Server, an den die DNS-Anfragen weitergeleitet werden. In unserem Fall ist dies die Adresse des CoreDNS-Dienstes;
- search: definiert den Suchpfad für eine bestimmte Domäne. Interessanterweise
google.comodermrkaran.devsind keine FQDN (). Nach dem Standardabkommen, dem die meisten DNS-Resolver folgen, gelten als vollständige (FQDN) Domänen nur diejenigen, die mit einem Punkt „.“ enden, der die Wurzelzone darstellt. Einige Resolver können selbstständig einen Punkt hinzufügen. Somit istmrkaran.dev.— ein vollständiger Domänenname (FQDN), währendmrkaran.dev— es nicht ist; - ndots: Der interessanteste Parameter (darum geht es in diesem Artikel).
ndotslegt die Schwellenanzahl von Punkten im Anfragenamen fest, ab der dieser als „vollständiger“ Domänenname betrachtet wird. Darauf werden wir später eingehen, wenn wir die DNS-Abfragestruktur analysieren.
Lassen Sie uns ansehen, was passiert, wenn wir anfragen mrkaran.dev im Pod:
$ nslookup mrkaran.dev
Server: 10.152.183.10
Adresse: 10.152.183.10#53
Nicht-autoritative Antwort:
Name: mrkaran.dev
Adresse: 157.230.35.153
Name: mrkaran.dev
Adresse: 2400:6180:0:d1::519:6001 Für dieses Experiment habe ich das Protokollierungslevel von CoreDNS auf all (was es ziemlich ausführlich macht). Werfen wir einen Blick auf die Logs des Pods coredns:
[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744sPuh. Zwei Dinge fallen hier auf:
- Die Anfrage durchläuft alle Stadien der Suche, bis die Antwort den Code
NOERROR(DNS-Clients verstehen dies und speichern es als Ergebnis).NXDOMAINbedeutet, dass für diesen Domänennamen kein Eintrag gefunden wurde. Damrkaran.devkein FQDN-Name ist (entsprechendndots=5), schaut der Resolver auf den Suchpfad und bestimmt die Reihenfolge der Anfragen; - Einträge
AundAAAAwerden parallel verarbeitet. Das Besondere dabei ist, dass einmalige Anfragen in/etc/resolv.confstandardmäßig so konfiguriert sind, dass sie parallel über die Protokolle IPv4 und IPv6 gesucht werden. Dieses Verhalten kann durch Hinzufügen der Optionsingle-requestinresolv.conf.
Hinweis: glibc. so eingestellt werden, dass diese Anfragen nacheinander gesendet werden, und musl — Nein, Nutzer von Alpine sollten dies berücksichtigen.
Experimentieren wir mit ndots
Lass uns noch ein wenig mit ndots experimentieren und sehen, wie sich dieser Parameter verhält. Die Idee ist einfach: ndots bestimmt, ob der DNS-Client die Domain als absolut oder relativ betrachtet. Zum Beispiel, wie erkennt ein einfacher Google-DNS-Client, ob diese Domain absolut ist? Wenn wir ndots auf 1 setzen, sagt der Client: „Oh, es gibt keinen Punkt; ich werde die gesamte Suchliste durchlaufen.“ Wenn jedoch Google , wird die Liste der Suftixe vollständig ignoriert, da der angeforderte Name den Schwellenwert google.comerfüllt (es gibt mindestens einen Punkt). ndots Lass uns das überprüfen:
$ cat /etc/resolv.conf options ndots:1 $ nslookup mrkaran Server: 10.152.183.10 Adresse: 10.152.183.10#53** Server kann mrkaran nicht finden: NXDOMAIN
CoreDNS-Protokolle:[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s [INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s [INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s [INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s
mrkaran Da in es gibt keinen Punkt, die Suche wurde über die gesamte Liste der Suftixe durchgeführt. Hinweis: In der Praxis ist der maximale Wert
Примечание: на практике максимальное значение ndots maximal 15; standardmäßig in Kubernetes beträgt dieser Wert 5.
Einsatz in der Produktion
Wenn eine Anwendung viele externe Netzwerkaufrufe durchführt, kann DNS bei hohem Datenverkehr zum Engpass werden, da viele unnötige Abfragen stattfinden, bevor das System die gewünschte Adresse erreicht. Anwendungen fügen normalerweise keine Root-Zone zu Domainnamen hinzu, dies könnte jedoch als Hack angesehen werden. Anstatt also api.twitter.com, könnten Sie 'hardcode'n api.twitter.com. (mit Punkt) in die Anwendung, was DNS-Clients dazu bringt, sofort in der absoluten Domäne eine autoritative Suche durchzuführen.
Darüber hinaus haben mit Version 1.14 von Kubernetes die Erweiterungen dnsConfig und dnsPolicy den Status stabil erhalten. So kann beim Bereitstellen eines Pods der Wert verringert werden. ndots, sagen wir, bis zu 3 (oder sogar bis zu 1!). Daher muss jede Nachricht innerhalb des Knotens die vollständige Domain enthalten. Dies ist einer der klassischen Kompromisse, wenn man zwischen Leistung und Portabilität wählen muss. Ich denke, dass man sich nur dann Gedanken darüber machen sollte, wenn extrem niedrige Latenzen für Ihre Anwendung entscheidend sind, da DNS-Ergebnisse ebenfalls zwischengespeichert werden.
Links
Zum ersten Mal erfuhr ich von diesem Merkmal auf , das am 25. Januar stattfand. Dort wurde auch dieses Problem angesprochen.
Hier sind einige Links für weiterführende Informationen:
- , warum ndots=5 in Kubernetes;
- darüber, wie sich die Änderung von ndots auf die Leistung der Anwendung auswirkt;
- zwischen den Resolvern musl und glibc.
Hinweis: Ich habe es vorgezogen, nicht zu verwenden dig in diesem Artikel. dig fügt automatisch einen Punkt hinzu (Root-Zonen-Identifikator), wodurch die Domain „vollständig“ (FQDN) wird, nicht indem ich sie vorher durch die Suche-Liste geleitet habe. Ich habe darüber in . Dennoch ist es ziemlich erstaunlich, dass man für das Standardverhalten ein separates Flag setzen muss.
Gutes DNS! Bis bald!
P.S. vom Übersetzer
Lesen Sie auch in unserem Blog:
- «»;
- «»;
- „Illustriertes Handbuch zur Netzwerkausstattung in Kubernetes“: , .
Quelle: habr.com
