Notiz. übersetzen: DNS-Problem in Kubernetes, genauer gesagt Parametereinstellungen ndots, ist überraschend beliebt, und das schon jetzt . In einer weiteren Notiz zu diesem Thema spricht der Autor, ein DevOps-Ingenieur eines großen Maklerunternehmens in Indien, auf sehr einfache und prägnante Weise darüber, was Kollegen, die Kubernetes betreiben, wissen sollten.
Einer der Hauptvorteile der Bereitstellung von Anwendungen auf Kubernetes ist die nahtlose Anwendungserkennung. Die Interaktion innerhalb des Clusters wird dank des Servicekonzepts erheblich vereinfacht (), eine virtuelle IP, die eine Reihe von Pod-IP-Adressen unterstützt. Zum Beispiel, wenn der Dienst vanilla möchte den Dienst kontaktieren chocolate, kann es direkt auf die virtuelle IP zugreifen chocolate. Es stellt sich die Frage: An wen wird in diesem Fall die DNS-Anfrage weitergeleitet? chocolate und wie?
Die DNS-Namensauflösung wird auf einem Kubernetes-Cluster mit konfiguriert . Kubelet registriert einen Pod bei CoreDNS als Nameserver in Dateien /etc/resolv.conf alle Hülsen. Wenn man sich den Inhalt anschaut /etc/resolv.conf Wenn Sie einen beliebigen Pod verwenden, sieht er in etwa 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 Anfragen an den DNS-Server weiterzuleiten. Im Ordner resolv.conf enthält folgende Informationen:
- Name Server: Server, an den DNS-Anfragen gesendet werden. In unserem Fall ist dies die Adresse des CoreDNS-Dienstes;
- search: Definiert den Suchpfad für eine bestimmte Domäne. Das ist interessant
google.comodermrkaran.devsind kein FQDN (). Gemäß der Standardkonvention, der die meisten DNS-Resolver folgen, gelten nur diejenigen als vollständig qualifizierte (FDQN) Domänen, die mit einem Punkt „.“ enden, der die Stammzone darstellt. Einige Resolver können selbst einen Punkt hinzufügen. Auf diese Weise,mrkaran.dev.ist der vollqualifizierte Domänenname (FQDN) undmrkaran.dev- Nein; - ndots: Der interessanteste Parameter (dieser Artikel handelt davon).
ndotsGibt die Schwellenwertanzahl von Punkten in einem Anforderungsnamen an, bevor dieser als „vollqualifizierter“ Domänenname betrachtet wird. Wir werden später mehr darüber sprechen, wenn wir die DNS-Suchsequenz analysieren.
Mal sehen, was passiert, wenn wir fragen mrkaran.dev im Pod:
$ 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 eingestellt all (was es ziemlich 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.145091744sPuh. Zwei Dinge erregen hier Ihre Aufmerksamkeit:
- Die Anfrage durchläuft alle Phasen der Suche, bis die Antwort den Code enthält
NOERROR(DNS-Clients verstehen es und speichern es als Ergebnis).NXDOMAINbedeutet, dass für den angegebenen Domainnamen kein Eintrag gefunden wurde. Weil dasmrkaran.devist kein FQDN-Name (gemäßndots=5), prüft der Resolver den Suchpfad und bestimmt die Reihenfolge der Anfragen; - Einträge
АиААААkommen parallel an. Tatsache ist, dass einmalige Anfragen in/etc/resolv.confStandardmäßig sind sie so konfiguriert, dass parallele Suchen über die Protokolle IPv4 und IPv6 durchgeführt werden. Sie können dieses Verhalten abbrechen, indem Sie die Option hinzufügensingle-requestвresolv.conf.
Hinweis: glibc kann so konfiguriert werden, dass diese Anfragen nacheinander gesendet werden musl - Nein, also sollten Alpine-Benutzer dies zur Kenntnis nehmen.
Experimentieren mit Ndots
Lasst uns noch ein wenig experimentieren ndots und mal sehen, wie sich dieser Parameter verhält. Die Idee ist einfach: ndots Legt fest, ob der DNS-Client die Domäne als absolut oder relativ behandelt. Woher weiß beispielsweise ein einfacher Google-DNS-Client, ob diese Domain absolut ist? Wenn Sie einstellen ndots gleich 1, wird der Kunde sagen: „Oh, in.“ google es gibt keinen einzigen Punkt; Ich schätze, ich werde die gesamte Suchliste durchgehen.“ Wenn Sie jedoch fragen google.com, wird die Liste der Suffixe vollständig ignoriert, da der angeforderte Name den Schwellenwert erreicht ndots (Es gibt mindestens einen Punkt).
Stellen wir Folgendes sicher:
$ 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: NXDOMAINCoreDNS-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
Seit in mrkaran Es gibt keinen einzigen Punkt, die Suche wurde über die gesamte Liste der Suffixe durchgeführt.
Hinweis: In der Praxis der Maximalwert ndots begrenzt auf 15; Standardmäßig ist es in Kubernetes 5.
Anwendung in der Produktion
Wenn eine Anwendung viele externe Netzwerkaufrufe durchführt, kann DNS bei aktivem Datenverkehr zum Flaschenhals werden, da die Namensauflösung viele unnötige Abfragen macht (bevor das System die richtige Anfrage erhält). Anwendungen fügen Domänennamen normalerweise keine Root-Zone hinzu, aber das klingt nach einem Hack. Das heißt, anstatt zu fragen api.twitter.com, Sie können fest codieren api.twitter.com. (mit einem Punkt) in der Anwendung, wodurch DNS-Clients aufgefordert werden, autorisierende Suchvorgänge direkt in der absoluten Domäne durchzuführen.
Zusätzlich, beginnend mit Kubernetes Version 1.14, Erweiterungen dnsConfig и dnsPolicy stabilen Status erhalten. Somit können Sie bei der Bereitstellung eines Pods den Wert reduzieren ndots, sagen wir, bis zu 3 (und sogar bis zu 1!). Aus diesem Grund muss jede Nachricht innerhalb eines Knotens die vollständige Domäne enthalten. Dies ist einer der klassischen Kompromisse, wenn Sie sich zwischen Leistung und Portabilität entscheiden müssen. Meiner Meinung nach sollten Sie sich darüber nur Sorgen machen, wenn eine extrem niedrige Latenz für Ihre Anwendung von entscheidender Bedeutung ist, da die DNS-Ergebnisse auch intern zwischengespeichert werden.
Referenzen
Ich habe zum ersten Mal von dieser Funktion erfahren , fand am 25. Januar statt. Es gab unter anderem eine Diskussion über dieses Problem.
Hier sind einige Links zur weiteren Erkundung:
- , warum ndots=5 in Kubernetes;
- wie sich das Ändern von Ndots auf die Anwendungsleistung auswirkt;
- zwischen musl- und glibc-Resolvern.
Hinweis: Ich habe mich gegen die Verwendung entschieden dig in diesem Artikel. dig fügt automatisch einen Punkt (Stammzonenkennung) hinzu, wodurch die Domäne „vollständig qualifiziert“ (FQDN) wird. nicht indem Sie es zuerst durch die Suchliste laufen lassen. Habe darüber geschrieben in . Allerdings ist es durchaus verwunderlich, dass für das Standardverhalten generell ein eigenes Flag angegeben werden muss.
Viel Spaß beim DNSing! Bis bald!
PS vom Übersetzer
Lesen Sie auch auf unserem Blog:
- «";
- «";
- „Ein illustrierter Leitfaden zum Netzwerken in Kubernetes“: , .
Source: habr.com