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;
- Suche: 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
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
