ProHoster > Blog > Administrácia > DNS vyhľadávanie v Kubernetes

DNS vyhľadávanie v Kubernetes

Poznámka. preklad.: Problém DNS v Kubernetes, alebo presnejšie, nastavenia parametrov ndots, je prekvapivo populárny a už Nie prvý rok. V ďalšej poznámke k tejto téme jej autor, inžinier DevOps z veľkej maklérskej spoločnosti v Indii, veľmi jednoducho a stručne hovorí o tom, čo je užitočné pre kolegov prevádzkujúcich Kubernetes vedieť.

DNS vyhľadávanie v Kubernetes

Jednou z hlavných výhod nasadzovania aplikácií na Kubernetes je bezproblémové zisťovanie aplikácií. Interakcia v rámci klastra je výrazne zjednodušená vďaka konceptu služieb (Služba sa), čo je virtuálna adresa IP, ktorá podporuje množinu adries IP pod. Napríklad, ak služba vanilla chce kontaktovať servis chocolate, môže priamo pristupovať k virtuálnej IP adrese chocolate. Vynára sa otázka: komu v tomto prípade vyrieši požiadavku DNS chocolate A ako?

Rozlíšenie názvov DNS je nakonfigurované v klastri Kubernetes pomocou CoreDNS. Kubelet registruje pod s CoreDNS ako nameserver v súboroch /etc/resolv.conf všetky struky. Ak sa pozriete na obsah /etc/resolv.conf akýkoľvek modul, bude to vyzerať asi takto:

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

Túto konfiguráciu používajú klienti DNS na posielanie požiadaviek na server DNS. V súbore resolv.conf obsahuje nasledujúce informácie:

  • menný server: server, na ktorý sa budú odosielať požiadavky DNS. V našom prípade ide o adresu služby CoreDNS;
  • vyhľadávanie: Definuje cestu vyhľadávania pre konkrétnu doménu. To je zaujímavé google.com alebo mrkaran.dev nie sú FQDN (plne kvalifikované názvy domén). Podľa štandardnej konvencie, ktorou sa riadi väčšina DNS resolverov, sa za plne kvalifikované (FDQN) domény považujú len tie, ktoré končia bodkou ".", ktorá predstavuje koreňovú zónu. Niektorí riešitelia si môžu bod pridať sami. teda mrkaran.dev. je plne kvalifikovaný názov domény (FQDN) a mrkaran.dev - Nie;
  • ndots: Najzaujímavejší parameter (je o ňom tento článok). ndots určuje prahový počet bodiek v názve požiadavky predtým, ako sa bude považovať za „plne kvalifikovaný“ názov domény. Viac si o tom povieme neskôr, keď budeme analyzovať sekvenciu vyhľadávania DNS.

DNS vyhľadávanie v Kubernetes

Uvidíme, čo sa stane, keď sa opýtame 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ň protokolovania CoreDNS na all (čo ho robí dosť podrobným). Pozrime sa na denníky pod 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. Tu upútajú vašu pozornosť dve veci:

  • Požiadavka prechádza všetkými fázami vyhľadávania, kým odpoveď neobsahuje kód NOERROR (DNS klienti tomu rozumejú a vo výsledku to ukladajú). NXDOMAIN znamená, že pre daný názov domény nebol nájdený žiadny záznam. Pretože mrkaran.dev nie je názov FQDN (podľa ndots=5), resolver sa pozrie na cestu vyhľadávania a určí poradie požiadaviek;
  • Príspevky А и АААА prichádzať paralelne. Faktom je, že jednorazové žiadosti v /etc/resolv.conf Štandardne sú nakonfigurované tak, že paralelné vyhľadávanie sa vykonáva pomocou protokolov IPv4 a IPv6. Toto správanie môžete zrušiť pridaním možnosti single-request в resolv.conf.

Poznámka: glibc môžu byť nakonfigurované tak, aby odosielali tieto požiadavky postupne, a musl - Nie, používatelia Alpine by to mali vziať na vedomie.

Experimentovanie s ndots

Poďme trochu viac experimentovať ndots a uvidíme, ako sa tento parameter správa. Myšlienka je jednoduchá: ndots určuje, či DNS klient bude považovať doménu za absolútnu alebo relatívnu. Napríklad v prípade jednoduchého klienta google DNS, ako zistí, či je táto doména absolútna? Ak nastavíte ndots rovná 1, klient povie: „Ach, v google nie je tam ani jeden bod; Myslím, že si prejdem celý zoznam vyhľadávania." Ak sa však pýtate google.com, bude zoznam prípon úplne ignorovaný, pretože požadovaný názov spĺňa prahovú hodnotu ndots (je tam aspoň jeden bod).

Presvedčime 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

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 nie je tam ani jeden bod, vyhľadávanie sa uskutočnilo v celom zozname prípon.

Poznámka: v praxi maximálna hodnota ndots obmedzený na 15; v predvolenom nastavení v Kubernetes je to 5.

Aplikácia vo výrobe

Ak aplikácia vykonáva veľa externých sieťových hovorov, DNS sa môže stať prekážkou v prípade aktívnej prevádzky, pretože rozlíšenie mien vytvára veľa zbytočných dopytov (predtým, než sa systém dostane k tomu správnemu). Aplikácie zvyčajne nepridávajú koreňovú zónu k názvom domén, ale to znie ako hack. Teda namiesto pýtania api.twitter.com, môžete ho „napevno zakódovať“. api.twitter.com. (s bodkou) v aplikácii, ktorá vyzve klientov DNS, aby vykonali autoritatívne vyhľadávanie priamo v absolútnej doméne.

Okrem toho, počnúc verziou Kubernetes 1.14, rozšírenia dnsConfig и dnsPolicy získal stabilný stav. Pri nasadzovaní modulu teda môžete znížiť hodnotu ndotspovedzme až 3 (a dokonca až 1!). Z tohto dôvodu bude musieť každá správa v rámci uzla obsahovať celú doménu. Toto je jeden z klasických kompromisov, keď si musíte vybrať medzi výkonom a prenosnosťou. Zdá sa mi, že by ste sa toho mali obávať iba vtedy, ak je pre vašu aplikáciu životne dôležitá ultranízka latencia, pretože výsledky DNS sa ukladajú aj interne.

referencie

Prvýkrát som sa o tejto funkcii dozvedel na K8s-stretnutie, ktorá sa konala 25. januára. Diskutovalo sa okrem iného aj o tomto probléme.

Tu je niekoľko odkazov na ďalšie preskúmanie:

Poznámka: Rozhodol som sa nepoužiť dig v tomto článku. dig automaticky pridá bodku (identifikátor koreňovej zóny), čím sa doména stane „plne kvalifikovanou“ (FQDN), nie tak, že ho najprv prejdete cez zoznam vyhľadávania. Napísali o tom v jedna z predchádzajúcich publikácií. Je však celkom prekvapujúce, že vo všeobecnosti musí byť pre štandardné správanie špecifikovaný samostatný príznak.

Šťastné DNSing! Vidíme sa neskôr!

PS od prekladateľa

Prečítajte si aj na našom blogu:

Zdroj: hab.com

Pridať komentár