🥇DNS vyhľadávanie v Kubernetes

Pozn. prekl.: Problém DNS v Kubernetes, presnejšie - nastavenie parametra ndots, - je prekvapivo populárna, a to už nie prvý rok. V ďalšom príspevku na túto tému autor - DevOps inžinier z veľkej brokerskej spoločnosti v Indii - veľmi jednoducho a výstižne vysvetľuje, čo by mali kolegovia používajúci Kubernetes vedieť.

Jednou z hlavných výhod nasadenia aplikácií v Kubernetes je bezproblémové objavovanie aplikácií. Interklastrová interakcia sa výrazne zjednodušuje vďaka konceptu služby (Service), ktorá predstavuje virtuálnu IP adresu podporujúcu súbor IP adries podov. Napríklad, ak služba vanilla chce komunikovať so službou chocolate, môže sa priamo obrátiť na virtuálnu IP pre chocolate. Vzniká otázka: kto v tomto prípade vyřeší DNS dotaz pre chocolate a ako?

Riešenie názvov DNS sa nastavuje v klastri Kubernetes pomocou CoreDNS. Kubelet zapisuje pod s CoreDNS ako server názvov do súborov /etc/resolv.conf všetkých podov. Ak sa pozrieme na obsah /etc/resolv.conf akéhokoľvek podu, bude vyzerať približne takto:

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

Táto konfigurácia sa používa DNS klientmi na presmerovanie dotazov na DNS server. V súbore resolv.conf sa nachádzajú tieto informácie:

nameserver: server, na ktorý budú smerované DNS dotazy. V našom prípade je to adresa služby CoreDNS;
search: určuje cestu hľadania konkrétneho domény. Zaujímavé je, že google.com alebo mrkaran.dev nie sú FQDN (plné doménové mená). Podľa štandardnej dohody, ktorej sa väčšina resolverov DNS riadi, sú plnými (FDQN) doménami len tie, ktoré končia bodkou „.“, predstavujúcou koreňovú zónu. Niektoré resolvery dokážu pridať bodku samy. Takže, mrkaran.dev. je plné doménové meno (FQDN), zatiaľ čo mrkaran.dev nie je;
ndots: Najzaujímavejší parameter (o ktorom je tento článok). ndots určuje prahový počet bodiek v názve dotazu, pri dosiahnutí ktorého je považované za „plné“ doménové meno. O tom sa podrobnejšie porozprávame neskôr, keď budeme analyzovať sekvenciu DNS vyhľadávania.

Pozrime sa, čo sa stane, keď požiadame mrkaran.dev v 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

Pre tento experiment som nastavil úroveň logovania CoreDNS na všetko (čo z neho robí dosť podrobné). Pozrime sa na logy podu 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

Uf. Dve veci tu priťahujú pozornosť:

Žiadosť prechádza všetkými krokmi vyhľadávania, až kým odpoveď nebude obsahovať kód NOERROR (DNS klienti ho chápu a uchovávajú ako výsledok). NXDOMAIN označuje, že pre dané doménové meno záznam nebol nájdený. Keďže mrkaran.dev nie je FQDN názvom (podľa ndots=5), resolver sa pozrie na vyhľadávaciu cestu a určuje poradie požiadaviek;
Záznamy A a AAAAA prichádzajú paralelne. Problém je v tom, že jednorazové požiadavky v /etc/resolv.conf sú predvolene nastavené tak, aby sa paralelne vyhľadávalo cez protokoly IPv4 a IPv6. Tieto správanie môžete zrušiť pridaním možnosti single-request v resolv.conf.

Poznámka: glibc môže byť nastavený na sekvenčné zasielanie týchto požiadaviek, zatiaľ čo musl — nie, takže používateľom Alpine by sa to malo vziať na vedomie.

Experimentujeme s ndots

Poďme ešte trochu experimentovať s ndots a pozrime sa, ako sa tento parameter správa. Myšlienka je jednoduchá: ndots určuje, či bude DNS klient považovať doménu za absolútnu alebo relatívnu. Napríklad, ako zistí jednoduchý google DNS klient, či je táto doména absolútna? Ak nastavíte ndots na 1, klient povie: „O, v google nie je žiadna bodka; asi prebehnem ceľým vyhľadávacím zoznamom“. Avšak ak požiadate o google.com, zoznam sufixov bude úplne ignorovaný, pretože požadované meno spĺňa prah ndots (existuje aspoň jedna bodka).

Uistime sa o tom:

$ 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

Logy CoreDNS:

[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

Keďže v mrkaran nie je žiadna bodka, vyhľadávanie bolo vykonané cez celý zoznam sufixov.

Poznámka: V praxi je maximálna hodnota ndots obmedzená na 15; predvolene je v Kubernetes nastavená na 5.

Použitie v produkcii

Ak aplikácia vykonáva množstvo vonkajších sieťových volaní, DNS sa môže stať úzkym miestom pri aktívnom prenosu, pretože pri rozlíšení mena sa vykonáva množstvo zbytočných požiadaviek (skôr než sa systém dostane k požadovanej). Aplikácie zvyčajne nepridávajú koreňovú zónu k doménovým menám, avšak toto sa dá považovať za hack. Teda namiesto toho, aby ste sa pýtali api.twitter.com, môžete 'hardcode' do aplikácie api.twitter.com. (s bodkou), čo podnieti DNS klientov, aby vykonali autoritatívne hľadanie priamo v absolútnom doméne.

Okrem toho, od verzie Kubernetes 1.14, rozšírenia dnsConfig a dnsPolicy dostali stabilný stav. Týmto spôsobom je možné pri nasadení podu znížiť hodnotu ndots, povedzme, na 3 (a dokonca na 1!). Z tohto dôvodu musí každá správa v rámci uzla obsahovať úplný doménový názov. Toto je jeden z klasických kompromisov, pri ktorých je potrebné vybrať medzi výkonom a prenosnosťou. Myslím, že o to by sme sa mali obávať len v prípade, ak sú extrémne nízke latencie životne dôležité pre vašu aplikáciu, pretože výsledky DNS sú tiež vyrovnávané v pamäti.

Odkazy

O tejto funkcii som sa prvýkrát dozvedel na K8s-meetupu, ktorý sa konal 25. januára. Hovorilo sa tam, vrátane iného, aj o tomto probléme.

Tu je niekoľko odkazov na ďalšie štúdium:

Vysvetlenie, prečo je ndots=5 v Kubernetes;
Skvelý materiál o tom, ako zmena ndots ovplyvňuje výkon aplikácie;
Rozdiely medzi resolvermi musl a glibc.

Poznámka: Rozhodol som sa v tomto článku nepoužívať dig . dig automaticky pridáva bodku (identifikátor koreňovej zóny), čím robí doménu „úplnou“ (FQDN), nie predtým, ako ju spracuje zoznam vyhľadávania. O tom som písal v jednom z predchádzajúcich príspevkov. Napriek tomu je celkom prekvapujúce, že vo všeobecnosti je potrebné nastaviť samostatnú vlajku pre štandardné správanie.

Šťastné DNSovanie! Zatiaľ do skorého videnia!

P.S. od prekladateľa

Prečítajte si tiež na našom blogu:

«Calico pre sieť v Kubernetes: úvod a niečo z praxe»;
«CoreDNS — DNS server pre svet cloud native a Service Discovery pre Kubernetes»;
„Ilustrovaný sprievodca architektúrou siete v Kubernetes“: časť 1 a 2 (sieťový model, overlay sieťe), časť 3 (služby a spracovanie prevádzky).

Zdroj: habr.com