Vyhledávání DNS v Kubernetes

Poznámka. přel.: Problém DNS v Kubernetes, přesněji nastavení parametrů ndots, je překvapivě populární a již Ne první rok. V další poznámce na toto téma její autor, inženýr DevOps z velké makléřské společnosti v Indii, velmi jednoduchým a výstižným způsobem hovoří o tom, co je užitečné pro kolegy provozující Kubernetes vědět.

Jednou z hlavních výhod nasazení aplikací na Kubernetes je bezproblémové zjišťování aplikací. Interakce v rámci clusteru je výrazně zjednodušena díky konceptu služeb (Servis), což je virtuální IP, která podporuje sadu IP adres podu. Například pokud služba vanilla chce kontaktovat službu chocolate, může přímo přistupovat k virtuální IP adrese chocolate. Nabízí se otázka, komu v tomto případě vyřeší požadavek DNS chocolate A jak?

Překlad názvů DNS je nakonfigurován v clusteru Kubernetes pomocí CoreDNS. Kubelet registruje pod s CoreDNS jako jmenný server v souborech /etc/resolv.conf všechny lusky. Pokud se podíváte na obsah /etc/resolv.conf jakýkoli modul, bude vypadat nějak takto:

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

Tuto konfiguraci používají klienti DNS k předávání požadavků na server DNS. V souboru resolv.conf obsahuje následující informace:

• jmenný server: server, na který budou odesílány požadavky DNS. V našem případě se jedná o adresu služby CoreDNS;
• hledat: Definuje vyhledávací cestu pro konkrétní doménu. To je zajímavé google.com nebo mrkaran.dev nejsou FQDN (plně kvalifikovaná doménová jména). Podle standardní konvence, kterou se řídí většina překladačů DNS, jsou za plně kvalifikované (FDQN) domény považovány pouze ty, které končí tečkou ".", představující kořenovou zónu. Někteří řešitelé si mohou bod přidat sami. Tím pádem, mrkaran.dev. je plně kvalifikovaný název domény (FQDN) a mrkaran.dev - Ne;
• ndots: Nejzajímavější parametr (o tom je tento článek). ndots určuje prahový počet teček v názvu požadavku, než bude považován za „plně kvalifikovaný“ název domény. Více o tom promluvíme později, až budeme analyzovat sekvenci vyhledávání DNS.

Uvidíme, co se stane, když se zeptáme 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ň protokolování CoreDNS na all (což je docela upovídané). Podívejme se na protokoly modulu 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

Fuj. Zde upoutají vaši pozornost dvě věci:

• Požadavek prochází všemi fázemi vyhledávání, dokud odpověď neobsahuje kód NOERROR (DNS klienti tomu rozumí a ve výsledku to ukládají). NXDOMAIN znamená, že pro daný název domény nebyl nalezen žádný záznam. Protože mrkaran.dev není název FQDN (podle ndots=5), resolver se podívá na vyhledávací cestu a určí pořadí požadavků;
• Записи А и АААА dorazit paralelně. Faktem je, že jednorázové žádosti v /etc/resolv.conf Ve výchozím nastavení jsou nakonfigurovány tak, že paralelní vyhledávání probíhá pomocí protokolů IPv4 a IPv6. Toto chování můžete zrušit přidáním možnosti single-request в resolv.conf.

Poznámka: glibc lze nakonfigurovat tak, aby tyto požadavky posílaly postupně, a musl - ne, takže uživatelé Alpine by to měli vzít na vědomí.

Experimentování s ndots

Pojďme trochu více experimentovat ndots a podívejme se, jak se tento parametr chová. Myšlenka je jednoduchá: ndots určuje, zda bude klient DNS považovat doménu za absolutní nebo relativní. Jak například v případě jednoduchého klienta google DNS pozná, zda je tato doména absolutní? Pokud nastavíte ndots rovná 1, klient řekne: „Aha, dovnitř google není tam jediný bod; Myslím, že projdu celý seznam hledání." Pokud se však ptáte google.com, bude seznam přípon zcela ignorován, protože požadovaný název splňuje prahovou hodnotu ndots (je tam alespoň jeden bod).

Přesvědčte se 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

Protokoly 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

Od r mrkaran není tam ani jeden bod, vyhledávání bylo provedeno napříč celým seznamem přípon.

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

Aplikace ve výrobě

Pokud aplikace provádí mnoho externích síťových volání, DNS se může stát úzkým hrdlem v případě aktivního provozu, protože překlad názvů vytváří mnoho zbytečných dotazů (než se systém dostane k tomu správnému). Aplikace obvykle nepřidávají kořenovou zónu k názvům domén, ale zní to jako hack. Tedy místo aby se zeptal api.twitter.com, můžete to 'pevně' kódovat api.twitter.com. (s tečkou) v aplikaci, která vyzve klienty DNS k provádění autoritativního vyhledávání přímo v absolutní doméně.

Navíc, počínaje Kubernetes verze 1.14, rozšíření dnsConfig и dnsPolicy získal stabilní stav. Při nasazení modulu tedy můžete snížit hodnotu ndotsřekněme až 3 (a dokonce až 1!). Z tohoto důvodu bude muset každá zpráva v rámci uzlu obsahovat celou doménu. To je jeden z klasických kompromisů, kdy si musíte vybrat mezi výkonem a přenosností. Zdá se mi, že byste se toho měli obávat pouze v případě, že je pro vaši aplikaci životně důležitá ultra nízká latence, protože výsledky DNS jsou také interně ukládány do mezipaměti.

reference

Poprvé jsem se o této funkci dozvěděl na K8s-setkání, která se konala 25. ledna. O tomto problému se mimo jiné diskutovalo.

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

• Vysvětlení, proč ndots=5 v Kubernetes;
• Skvělý materiál jak změna ndots ovlivňuje výkon aplikace;
• Nesrovnalosti mezi musl a glibc resolvery.

Poznámka: Rozhodl jsem se nepoužívat dig v tomto článku. dig automaticky přidá tečku (identifikátor kořenové zóny), čímž se doména stane „plně kvalifikovanou“ (FQDN), ne tak, že jej nejprve projdete vyhledávacím seznamem. Psali o tom v jedna z předchozích publikací. Je však docela překvapivé, že obecně musí být pro standardní chování specifikován samostatný příznak.

Šťastné DNSing! Uvidíme se později!

PS od překladatele

Přečtěte si také na našem blogu:

• «Calico pro networking v Kubernetes: úvod a malá zkušenost";
• «CoreDNS – DNS server pro cloudový nativní svět a Service Discovery pro Kubernetes";
• "Ilustrovaný průvodce sítí v Kubernetes": části 1 a 2 (model sítě, překryvné sítě), část 3 (služby a zpracování provozu).

Zdroj: www.habr.com