DNS Lookup zu Kubernetes

Note. iwwersat.: DNS Problem an Kubernetes, oder méi präzis, Parameter Astellungen ndots, ass iwwerraschend populär, a schonn Net éischt Joer. An enger anerer Notiz zu dësem Thema schwätzt säin Auteur, en DevOps Ingenieur vun enger grousser Brokeragefirma an Indien, op eng ganz einfach a präzis Manéier iwwer wat nëtzlech ass fir Kollegen déi Kubernetes operéieren ze wëssen.

Ee vun den Haaptvirdeeler fir Uwendungen op Kubernetes z'installéieren ass eng nahtlos Applikatioun Entdeckung. Intra-Cluster Interaktioun ass vill vereinfacht dank dem Servicekonzept (Service), wat eng virtuell IP ass, déi e Set vu Pod IP Adressen ënnerstëtzt. Zum Beispill, wann de Service vanilla wëll de Service kontaktéieren chocolate, et kann direkt Zougang zu der virtueller IP fir chocolate. D'Fro stellt sech: wien an dësem Fall d'DNS Ufro léist chocolate A wéi?

DNS Numm Resolutioun ass op engem Kubernetes Cluster konfiguréiert benotzt CoreDNS. Kubelet registréiert e Pod mat CoreDNS als Nummserver an Dateien /etc/resolv.conf all Poppen. Wann Dir den Inhalt kuckt /etc/resolv.conf all Pod, et wäert sou ausgesinn:

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

Dës Konfiguratioun gëtt vun DNS Cliente benotzt fir Ufroen un den DNS Server weiderzebréngen. Am Dossier resolv.conf enthält folgend Informatiounen:

• Nummserver: Server un deen DNS Ufroe geschéckt ginn. An eisem Fall ass dëst d'Adress vum CoreDNS Service;
• Sich: Definéiert de Sichwee fir eng spezifesch Domain. Et ass interessant dat google.com oder mrkaran.dev sinn net FQDN (voll qualifizéiert Domain Nimm). No der Standardkonventioun, déi déi meescht DNS-Resolvere verfollegen, ginn nëmmen déi, déi mat engem Punkt "." ophalen, déi d'Rootzone representéiert, als vollqualifizéiert (FDQN) Domainen ugesinn. E puer Resolvere kënnen e Punkt selwer addéieren. Also, mrkaran.dev. ass de voll qualifizéierten Domain Numm (FQDN), an mrkaran.dev - Nee;
• ndts: Déi interessantst Parameter (dësen Artikel ass doriwwer). ndots spezifizéiert d'Schwellzuel vun de Punkten an engem Ufronumm ier et als "voll qualifizéiert" Domain Numm ugesi gëtt. Mir schwätze méi iwwer dëst méi spéit wa mir d'DNS Lookup Sequenz analyséieren.

Loosst eis kucken wat geschitt wa mir froen mrkaran.dev am 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

Fir dëst Experiment hunn ech de CoreDNS Logniveau op gesat all (wat et ganz verbose mécht). Loosst eis d'Logbicher vum Pod kucken 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

Pff. Zwou Saache fänken Är Opmierksamkeet hei:

• D'Ufro geet duerch all Etappe vun der Sich bis d'Äntwert de Code enthält NOERROR (DNS Clienten verstinn et a späicheren et als Resultat). NXDOMAIN heescht datt kee Rekord fir de bestëmmten Domain Numm fonnt gouf. Well déi mrkaran.dev ass keen FQDN Numm (geméiss ndots=5), Resolver kuckt op de Sichwee a bestëmmt d'Uerdnung vun den Ufroen;
• Posts А и АААА parallel kommen. D'Tatsaach ass, datt eemoleg Ufroen an /etc/resolv.conf Par défaut si se sou konfiguréiert datt parallel Siche mat den IPv4- an IPv6-Protokoller duerchgefouert ginn. Dir kënnt dëst Verhalen annuléieren andeems Dir d'Optioun bäidréit single-request в resolv.conf.

Opgepasst: glibc kann konfiguréiert ginn dës Demanden sequenziell ze schécken, an musl - nee, also Alpine Benotzer sollen oppassen.

Experimentéiere mat ndots

Loosst eis e bësse méi experimentéieren mat ndots a loosst eis kucken wéi dësen Parameter sech behält. D'Iddi ass einfach: ndots bestëmmt ob den DNS Client d'Domain als absolut oder relativ behandelt. Zum Beispill, am Fall vun engem einfachen Google DNS Client, wéi weess et ob dëst Domain absolut ass? Wann Dir setzt ndots gläich wéi 1, wäert de Client soen: "Oh, an google et gëtt keen eenzege Punkt; Ech denken, ech wäert déi ganz Sichlëscht duerchgoen. Wéi och ëmmer, wann Dir frot google.com, gëtt d'Lëscht vun de Suffixe komplett ignoréiert, well den ugefrote Numm der Schwell entsprécht ndots (et gëtt op d'mannst ee Punkt).

Loosst eis dëst sécher stellen:

$ 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 Logbicher:

[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

Zënter an mrkaran et gëtt keen eenzege Punkt, d'Sich gouf iwwer déi ganz Lëscht vun de Suffixen duerchgefouert.

Notiz: an der Praxis de maximale Wäert ndots limitéiert op 15; Par défaut a Kubernetes ass et 5.

Applikatioun an der Produktioun

Wann eng Applikatioun vill externen Netzwierkappellen mécht, kann DNS e Flaschenhals am Fall vum aktive Traffic ginn, well d'Nummresolutioun vill onnéideg Ufroen mécht (ier de System op déi richteg ass). Uwendungen fügen normalerweis keng Rootzone un Domain Nimm, awer dëst kléngt wéi en Hack. Dat ass, amplaz ze froen api.twitter.com, Dir kënnt hardcode api.twitter.com. (mat engem Punkt) an der Applikatioun, déi DNS Clienten freet autoritär Lookups direkt op den absoluten Domain auszeféieren.

Zousätzlech, ugefaange mat Kubernetes Versioun 1.14, Extensiounen dnsConfig и dnsPolicy stabile Status kritt. Also, wann Dir e Pod ofsetzt, kënnt Dir de Wäert reduzéieren ndots, soen, bis zu 3 (a souguer bis zu 1!). Dofir muss all Message an engem Node de ganzen Domain enthalen. Dëst ass ee vun de klassesche Trade-offs wann Dir tëscht Leeschtung a Portabilitéit muss wielen. Et schéngt mir datt Dir Iech nëmmen iwwer dëst sollt Suergen maachen wann ultra-niddereg latency wesentlech fir Är Applikatioun ass, well d'DNS Resultater och intern cache sinn.

Referenze

Ech geléiert éischt iwwer dës Fonktioun op K8s-Meetup, stattfonnt de 25. Januar. Iwwert dee Problem gouf ënner anerem diskutéiert.

Hei sinn e puer Links fir weider Exploratioun:

• Erklärung, firwat ndots = 5 zu Kubernetes;
• Flott Saachen wéi änneren ndots Applikatioun Leeschtung Afloss;
• Ënnerscheeder tëscht Musl an Glibc Resolver.

Notiz: Ech hu gewielt net ze benotzen dig an dësem Artikel. dig füügt automatesch e Punkt derbäi (Root Zone Identifizéierer), wat d'Domain "voll qualifizéiert" mécht (FQDN), Net andeems Dir et als éischt duerch d'Sichlëscht leeft. Iwwer dëst geschriwwen an eng vun de fréiere Publikatiounen. Wéi och ëmmer, et ass ganz iwwerraschend datt allgemeng e separate Fändel fir de Standardverhalen spezifizéiert muss ginn.

Happy DNSing! Bis herno!

PS vum Iwwersetzer

Liest och op eisem Blog:

• «Calico fir Vernetzung zu Kubernetes: Aféierung an e bëssen Erfahrung";
• «CoreDNS - DNS Server fir d'Cloud native Welt a Service Discovery fir Kubernetes";
• "En Illustréierte Guide fir Netzwierker a Kubernetes": Deeler 1 an 2 (Netzmodell, Overlay Netzwierker), Deel 3 (Servicer a Verkéiersveraarbechtung).

Source: will.com