Get best of the week

DNS-Suche in Kubernetes

Hinweis perev. : Das DNS-Problem in Kubernetes bzw. Parametereinstellungen ndotsist überraschend beliebt, und dies ist nicht das erste Jahr . In einem anderen Artikel zu diesem Thema erklärt der Autor, DevOps-Ingenieur eines großen Maklerunternehmens in Indien, auf sehr einfache und präzise Weise, was es für Kollegen, die Kubernetes verwenden, nützlich ist, dies zu wissen.



Einer der Hauptvorteile der Bereitstellung von Anwendungen in Kubernetes ist die nahtlose Erkennung von Anwendungen. Die Intracluster-Interaktion wird durch das Servicekonzept ( Service ), eine virtuelle IP, die eine Reihe von Pod'ov-IP-Adressen unterstützt,erheblich vereinfacht. Wenn ein Dienst beispielsweisevanillaKontakt mit demDienst aufnehmenmöchtechocolate, kann er direkt auf die virtuelle IP zugreifenchocolate. Es stellt sich die Frage: An wen wird in diesem Fall die DNS-Abfrage aufgelöst chocolateund wie?

Die DNS-Namensauflösung wird im Kubernetes-Cluster mithilfe von CoreDNS konfiguriert . Kubelet registriert Pods mit CoreDNS als Nameserver in den Dateien /etc/resolv.confaller Pods. Wenn Sie sich den Inhalt eines /etc/resolv.confPods ansehen, sieht er ungefähr so ​​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 Anforderungen an einen DNS-Server umzuleiten. Die Datei resolv.confenthält die folgenden Informationen:

  • Nameserver : Der Server, an den DNS-Abfragen weitergeleitet werden. In unserem Fall ist dies die Adresse des CoreDNS-Dienstes.
  • search: . , google.com mrkaran.dev FQDN ( ). , resolver' DNS, (FDQN) , «.», . resolver' . , mrkaran.dev. — (FQDN), mrkaran.dev — ;
  • ndots: ( ). ndots , «» . , DNS-.



Mal sehen, was passiert, wenn wir mrkaran.devim Pod anfordern :

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

Non-authoritative answer:
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 CoreDNS-Protokollierungsstufe auf gesetzt all(was es sehr ausführlich macht). Schauen wir uns die Protokolle des Pods an 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

Fuh. Zwei Dinge werden hier beachtet:

  • Die Anforderung durchläuft alle Phasen der Suche, bis die Antwort einen Code enthält NOERROR(DNS-Clients verstehen ihn und speichern ihn als Ergebnis). NXDOMAINbedeutet, dass für diesen Domainnamen kein Eintrag gefunden wurde. Da mrkaran.deves sich (gemäß ndots=5) nicht um einen vollqualifizierten Domänennamen handelt , überprüft der Resolver den Suchpfad und bestimmt die Reihenfolge der Abfragen.
  • . , /etc/resolv.conf , IPv4 IPv6. , single-request resolv.conf.

: glibc , musl — , Alpine .

ndots


Lassen Sie uns mit etwas mehr experimentieren ndotsund sehen, wie sich dieser Parameter verhält. Die Idee ist einfach: Sie ndotsbestimmt, ob der DNS-Client die Domäne als absolut oder relativ betrachtet. Woher weiß der DNS-Client beispielsweise bei einfachem Google, ob diese Domain absolut ist? Wenn ndotsauf 1 gesetzt, sagt der Client: „Oh, googlees gibt keinen einzigen Punkt; Ich werde wahrscheinlich die gesamte Suchliste durchgehen. " Auf Anfrage google.comwird die Liste der Suffixe jedoch vollständig ignoriert, da der angeforderte Name den Schwellenwert erfüllt ndots(es gibt mindestens einen Punkt).

Stellen wir sicher, dass:

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

** server can't find mrkaran: 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

Da es mrkarankeinen einzigen Punkt gibt, wurde die Suche in der gesamten Liste der Suffixe durchgeführt.

Hinweis: In der Praxis ist der Maximalwert ndotsauf 15 begrenzt. Kubernetes ist standardmäßig 5.

Produktionsanwendung


Wenn die Anwendung viele externe Netzwerkanrufe tätigt, kann DNS bei aktivem Datenverkehr zu einem Engpass werden, da beim Auflösen eines Namens viele unnötige Abfragen ausgeführt werden (bevor das System den richtigen findet). Anwendungen fügen Domain-Namen normalerweise keine Root-Zone hinzu, dies ist jedoch ein ziemlicher Hack. Das heißt, anstatt zu fragen api.twitter.com, können Sie api.twitter.com.in der Anwendung einen Hardcode (mit einem Punkt ) erstellen, der DNS-Clients auffordert , sofort autorisierende Suchvorgänge in der absoluten Domäne durchzuführen.

Ab Version Kubernetes 1.14 wird außerdem der Status eines Stables erweitert dnsConfigund dnsPolicygewährt. Daher können Sie beim Bereitstellen eines Pods den Wert verringernndotssagen wir bis zu 3 (und sogar bis zu 1!). Aus diesem Grund muss jede Nachricht innerhalb des Knotens eine vollständige Domäne enthalten. Dies ist einer der klassischen Kompromisse, wenn Sie zwischen Leistung und Portabilität wählen müssen. Es scheint mir, dass dies nur dann erforderlich ist, wenn für Ihre Anwendung äußerst niedrige Latenzen von entscheidender Bedeutung sind, da DNS-Ergebnisse auch intern zwischengespeichert werden.

Verweise


Zum ersten Mal habe ich diese Funktion beim K8s-Treffen am 25. Januar erfahren . Dort gab es eine Diskussion, auch über dieses Problem.

Hier sind einige Links für weitere Studien:

  • Erklärung, warum ndots = 5 in Kubernetes;
  • Großartige Informationen darüber, wie sich das Ändern von ndots auf die Anwendungsleistung auswirkt.
  • Diskrepanzen zwischen Resol Musls und Glibc.

Hinweis: Ich habe digdiesen Artikel nicht verwendet . digFügt automatisch einen Punkt (Root-Zonen-ID) hinzu, wodurch die Domain "voll" (FQDN) wird, ohne sie zuvor in der Suchliste auszuführen. Er schrieb darüber in einer der vorherigen Veröffentlichungen . Es ist jedoch ziemlich überraschend, dass im Allgemeinen ein Standardflag für das Standardverhalten gesetzt werden muss.

Gutes DNS! Bis bald!

PS vom Übersetzer


Lesen Sie auch in unserem Blog:

More articles:


All Articles