🥇DNS hledání v Kubernetes

Pozn. přek.: Problém DNS v Kubernetes, konkrétně - nastavení parametru ndots, - je překvapivě populární, a to už neprvní rok. V dalším článku na toto téma jeho autor - DevOps inženýr z velké brokerské společnosti v Indii - velmi jednoduše a lakonicky popisuje, co by měli vědět kolegové, kteří využívají Kubernetes.

Jednou z hlavních výhod nasazení aplikací v Kubernetes je bezproblémové objevování aplikací. Vnitřní interakce v clusteru je značně zjednodušená díky konceptu služby (Služba), která představuje virtuální IP podporující sadu IP adres podů. Například, pokud služba vanilla chce komunikovat se službou chocolate, může se přímo obrátit na virtuální IP pro chocolate. Vzniká otázka: kdo v tomto případě vyřeší DNS dotaz na chocolate a jak?

Řešení názvů DNS se konfiguruje v Kubernetes clusterech pomocí CoreDNS. Kubelet zapisuje pod s CoreDNS jako server názvů do souborů /etc/resolv.conf všech podů. Pokud se podíváme na obsah /etc/resolv.conf jakéhokoli podu, bude vypadat zhruba takto:

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

Tato konfigurace se používá DNS klienty k přesměrování dotazů na DNS server. V souboru resolv.conf se nachází následující informace:

nameserver: server, na který budou směřovány DNS dotazy. V našem případě je to adresa služby CoreDNS;
search: určuje cestu pro hledání určité domény. Zajímavé je, že google.com nebo mrkaran.dev nejsou FQDN (úplná doménová jména). Podle standardního ujednání, které dodržuje většina resolverů DNS, jsou úplnými (FQDN) doménami pouze ty, které končí tečkou „.“, což představuje kořenovou zónu. Někteří resolvery umějí tečku přidávat samostatně. Takže mrkaran.dev. je úplné doménové jméno (FQDN), zatímco mrkaran.dev není;
ndots: Nejzajímavější parametr (o kterém je tento článek). ndots určuje prahové číslo teček v názvu dotazu, při jehož dosažení je považováno za „úplné“ doménové jméno. O tom si povíme více později, když budeme analyzovat postup DNS hledání.

Podívejme se, co se stane, když požádáme o mrkaran.dev v podu:

$ 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

Pro tento experiment jsem nastavil úroveň logování CoreDNS na all (což dělá jeho výstup velmi podrobným). Podívejme se na protokoly 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. Dvě věci zde upoutávají pozornost:

Dotaz prochází všemi fázemi vyhledávání, dokud odpověď neobsahuje kód NOERROR (DNS klienti to chápou a uchovávají jako výsledek). NXDOMAIN to znamená, že pro toto doménové jméno záznam nebyl nalezen. Protože mrkaran.dev není FQDN jméno (podle ndots=5), resolver se podívá na vyhledávací cestu a určuje pořadí dotazů;
Záznamy A a AAAA se zasílají paralelně. Věc se má tak, že jednorázové dotazy v /etc/resolv.conf jsou ve výchozím nastavení nakonfigurovány tak, aby prováděly paralelní vyhledávání přes protokoly IPv4 a IPv6. Toto chování lze zrušit přidáním možnosti single-request v resolv.conf.

Poznámka: glibc může být nakonfigurováno pro sekvenční odesílání těchto dotazů, a musl — není, takže uživatelé Alpine by to měli mít na paměti.

Experimentujeme s ndots

Pojďme ještě trochu experimentovat s ndots a podívat se, jak se tento parametr chová. Myšlenka je jednoduchá: ndots určuje, zda bude DNS klient považovat doménu za absolutní nebo relativní. Například, jak se v případě jednoduchého google DNS klienta zjistí, zda je toto doménové jméno absolutní? Pokud nastavíte ndots na 1, klient řekne: „O, v google není žádná tečka; asi projdu celý seznam vyhledávání“. Pokud však dotazujete google.com, seznam sufixů bude zcela ignorován, protože požadované jméno splňuje práh ndots (existuje alespoň jedna tečka).

Podívejme se na to:

$ 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

Jelikož v mrkaran není žádná tečka, vyhledávání probíhalo přes celý seznam sufixů.

Poznámka: v praxi je maximální hodnota ndots omezená na 15; ve výchozím nastavení v Kubernetes je nastavena na 5.

Použití v produkci

Pokud aplikace provádí mnoho externích síťových volání, může se DNS stát úzkým hrdlem při vysokém zatížení, protože při řešení názvu dochází k mnoha nadbytečným dotazům (než se systém dostane k zamýšlenému). Aplikace obvykle nepřidávají kořenovou zónu k doménovým jménům, ale to se dá považovat za hack. To znamená, že místo aby žádali api.twitter.com, můžete 'hardcodovat' api.twitter.com. (s tečkou) do aplikace, což přiměje DNS klienty provádět autoritativní dotaz přímo v absolutní doméně.

Navíc, od verze Kubernetes 1.14, rozšíření dnsConfig a dnsPolicy získala status stabilních. Takže při nasazení podu lze hodnotu snížit ndots, dejme tomu, na 3 (a dokonce na 1!). Díky tomu musí každá zpráva uvnitř uzlu obsahovat plnou doménu. To je jeden z klasických kompromisů, kdy se musíte rozhodnout mezi výkonem a přenositelností. Myslím, že o to byste měli mít starosti jen tehdy, pokud jsou extrémně nízké latence zásadní pro vaši aplikaci, protože výsledky DNS se také ukládají do mezipaměti.

Odkazy

Poprvé jsem se o této funkci dozvěděl na K8s-meetupu, který se konal 25. ledna. Hovořilo se tam o této otázce.

Zde je několik odkazů pro další studium:

Vysvětlení, proč ndots=5 v Kubernetes;
Skvělý materiál o tom, jak změna ndots ovlivňuje výkon aplikace;
Rozdíly mezi resolver'y musl a glibc.

Poznámka: Rozhodl jsem se to v tomto článku nepoužívat. dig automaticky přidává tečku (identifikátor kořenové zóny), čímž se doména stává 'úplnou' (FQDN), dig předtím ji projíždí přes seznam hledání. O tom jsem psal v ne jednom z předchozích příspěvků. Nicméně je poněkud překvapující, že pro standardní chování je nutné nastavit samostatnou vlajku.Přeji dobré DNS! Na shledanou!

„Ilustrovaný průvodce nastavením sítě v Kubernetes“: