DNS-Suche in Kubernetes

Anmerkung des Übersetzers.: Ein DNS-Problem in Kubernetes, genauer gesagt - die Konfiguration des Parameters ndots, - ist überraschend populär, und zwar bereits zum ersten Jahr. In einem weiteren Beitrag zu diesem Thema beschreibt der Autor - ein DevOps-Ingenieur von einer großen Brokerage-Firma in Indien - auf sehr einfache und prägnante Weise, was nützlich für Kollegen zu wissen ist, die Kubernetes nutzen.

Einer der Hauptvorteile der Bereitstellung von Anwendungen in Kubernetes ist die problemlose Anwendungserkennung. Die interne Kommunikation zwischen Clustern wird durch das Konzept des Dienstes (Service) erheblich vereinfacht, welches eine virtuelle IP-Adresse darstellt, die eine Gruppe von IP-Adressen der Pods unterstützt. Zum Beispiel, wenn der Dienst vanilla mit dem Dienst chocolate, verbinden möchte, kann er sich direkt an die virtuelle IP für chocolatewenden. Die Frage ist: Wer wird in diesem Fall die DNS-Anfrage zu chocolate auflösen und wie?

Die DNS-Namensauflösung wird im Kubernetes-Cluster mit Hilfe von CoreDNSkonfiguriert. Kubelet trägt den Pod mit CoreDNS als Nameserver in die Dateien /etc/resolv.conf aller Pods ein. Wenn man sich den Inhalt /etc/resolv.conf eines Pods anschaut, sieht er ungefähr folgendermaßen aus:

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 weiterzuleiten. In der Datei resolv.conf befindet sich folgende Information:

• nameserver: der Server, an den die DNS-Anfragen geschickt werden. In unserem Fall ist dies die Adresse des CoreDNS-Dienstes;
• search: definiert den Suchpfad für eine bestimmte Domain. Interessanterweise google.com oder mrkaran.dev ist kein FQDN (vollständiger Domänenname). Laut der Standardvereinbarung, der die meisten DNS-Resolver folgen, gelten nur die Domänen als vollständig (FQDN), die mit einem Punkt „.“ enden, welcher die Wurzelzone repräsentiert. Einige Resolver können selbst einen Punkt hinzufügen. Somit ist mrkaran.dev. ein vollständiger Domänenname (FQDN), während mrkaran.dev nicht ist;
• ndots: Der interessanteste Parameter (darüber handelt dieser Artikel). ndots legt die Schwelle der Punkte im Namensaufruf fest, ab der er als „vollständiger“ Domänenname betrachtet wird. Mehr dazu werden wir später sprechen, wenn wir die DNS-Suchsequenz analysieren.

Lassen Sie uns sehen, was passiert, wenn wir anfordern mrkaran.dev im Pod:

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Nicht-autorisierte Antwort:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001

Für dieses Experiment habe ich die Protokollierungsebene von CoreDNS auf all (was es ziemlich wortreich 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.145091744s

Puh. Zwei Dinge fallen hier auf:

• Die Anfrage durchläuft alle Suchphasen, bis die Antwort keinen Code enthält NOERROR (DNS-Clients verstehen dies und speichern es als Ergebnis). NXDOMAIN bedeutet, dass für diesen Domainnamen kein Eintrag gefunden wurde. Da mrkaran.dev kein FQDN-Name ist (gemäß ndots=5), schaut der Resolver auf den Suchpfad und bestimmt die Reihenfolge der Anfragen;
• Einträge A und AAAA werden parallel verarbeitet. Tatsache ist, dass Einzelanfragen in /etc/resolv.conf standardmäßig so konfiguriert sind, dass eine parallele Suche über die Protokolle IPv4 und IPv6 erfolgt. Dieses Verhalten kann durch Hinzufügen der Option single-request in resolv.conf.

Hinweis: glibc konfiguriert werden, um diese Anfragen nacheinander zu senden, während musl – nicht, daher sollten sich Alpine-Nutzer dessen bewusst sein.

Lassen Sie uns mit ndots experimentieren

Lassen Sie 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 der einfache Google-DNS-Client, ob diese Domain absolut ist? Wenn Sie ndots auf 1 setzen, sagt der Client: „Oh, in google gibt es keinen Punkt; ich werde die gesamte Suchliste durchlaufen“. Wenn jedoch angefordert wird, google.com, wird die Liste der Endungen vollständig ignoriert, da der angeforderte Name den Schwellenwert ndots erfüllt (es gibt mindestens einen Punkt).

Lassen Sie uns das überprüfen:

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53

** server kann mrkaran nicht finden: NXDOMAIN

CoreDNS-Logs:

[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

Da in mrkaran gibt es keinen Punkt, die Suche erfolgte über die gesamte Liste der Endungen.

Hinweis: In der Praxis liegt der Höchstwert ndots bei 15; standardmäßig beträgt er in Kubernetes 5.

Einsatz in der Produktion

Wenn die Anwendung viele externe Netzwerkaufrufe macht, kann DNS bei aktivem Datenverkehr zum Engpass werden, da bei der Namensauflösung viele unnötige Anfragen gestellt werden (bevor das System das Ziel erreicht). Anwendungen fügen in der Regel keine Root-Zone zu Domainnamen hinzu, aber das könnte durchaus als Hack angesehen werden. Das heißt, anstatt api.twitter.com, können Sie 'hardcode' api.twitter.com. (mit Punkt) in der Anwendung, was DNS-Clients dazu anregen wird, sofort eine autoritative Abfrage im absoluten Domainnamen durchzuführen.

Darüber hinaus haben Erweiterungen seit der Version Kubernetes 1.14 den stabilen Status erreicht. Somit kann beim Bereitstellen eines Pods der Wert dnsConfig und dnsPolicy zum Beispiel auf 3 (und sogar auf 1!) verringert werden. Daher muss jede Nachricht innerhalb des Knotens den vollständigen Domainnamen enthalten. Dies ist einer der klassischen Kompromisse, wenn man zwischen Leistung und Portabilität wählen muss. Ich glaube, dass man sich nur dann wirklich Sorgen darum machen sollte, wenn ultra-niedrige Latenzzeiten für Ihre Anwendung von entscheidender Bedeutung sind, da die Ergebnisse von DNS ebenfalls im Speicher gehalten werden. ndotsDas erste Mal habe ich von diesem Feature auf dem

Links

K8s-Meetup , das am 25. Januar stattfand, erfahren. Es wurde auch über dieses Problem gesprochen.Hier sind einige Links für weiterführende Informationen:

Eine Erklärung

• , warum ndots=5 in Kubernetes;Ein großartiges Material
• darüber, wie sich die Änderung von ndots auf die Leistung der Anwendung auswirkt; Unterschiede
• zwischen den Resolvern musl und glibc. Hinweis: Ich habe entschieden, nicht zu verwenden

fügt automatisch einen Punkt hinzu (Identifikator der Root-Zone), wodurch die Domain „vollständig“ (FQDN) wird, dig in diesem Artikel. dig und sie vorher durch die Suchliste zu leiten. Ich habe darüber bereits in nicht einem meiner vorherigen Beiträge geschrieben. Dennoch ist es ziemlich erstaunlich, dass man für das Standardverhalten ein eigenes Flag setzen muss.Gutes DNS-Handling! Bis bald!

🥇DNS-Suche in Kubernetes | ProHoster

P.S. vom Übersetzer

Lesen Sie auch in unserem Blog:

• «Calico für Netzwerke in Kubernetes: Einführung und ein bisschen Erfahrung»;
• «CoreDNS – DNS-Server für die Welt der Cloud-nativen Anwendungen und Service Discovery für Kubernetes»;
• „Illustriertes Handbuch zum Netzwerkaufbau in Kubernetes“: Teil 1 und 2 (Netzwerkmodell, Overlay-Netzwerke), Teil 3 (Dienste und Verkehrsmanagement).

Quelle: habr.com