DNS iskanje v Kubernetesu

Op. prev.: Težava z DNS-om v Kubernetesu, natančneje - nastavitev parametra Iz priručnika za, - je presenetljivo priljubljena, pravzaprav že ne prvi letno. V novem zapisu na to temo njegov avtor - DevOps inženir iz velike borznoposredniške družbe v Indiji - na zelo preprost in jedrnat način opisuje, kaj je dobro vedeti kolegom, ki uporabljajo Kubernetes.

Ena glavnih prednosti nameščanja aplikacij v Kubernetesu je brezskrbno odkrivanje aplikacij. Znotrajklasterska interakcija se močno poenostavi zahvaljujoč konceptu storitve (Storitev), ki predstavlja virtualni IP naslov, ki podpira nabor IP naslovov podov. Na primer, če želi služba vanilla stopiti v stik s službo chocolate, se lahko poveže neposredno na virtualni IP za chocolate. Pojavi se vprašanje: kdo bo v tem primeru razrešil DNS poizvedbo za chocolate in kako?

Razreševanje DNS imen se nastavi v Kubernetesu s pomočjo CoreDNS. Kubelet zabeleži pod z CoreDNS kot strežnik imen v datotekah /etc/resolv.conf vseh podih. Če pogledamo vsebino /etc/resolv.conf kateregakoli poda, bo videti približno takole:

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

Ta konfiguracija se uporablja z DNS strankami za preusmerjanje poizvedb na DNS strežnik. V datoteki resolv.conf je naslednja informacija:

• nameserver: strežnik, na katerega bodo usmerjene DNS poizvedbe. V našem primeru je to naslov storitve CoreDNS;
• Postoji opcija: določa način iskanja določenega domenskega imena. Zanimivo je, da google.com ili mrkaran.dev ni FQDN (polna domena). Po standardnem sporazumu, ki se ga drži večina DNS resolverjev, so polne (FDQN) domene le tiste, ki se končajo s piko „.“, ki predstavlja korensko cono. Nekateri resolverji sami dodajajo piko. Tako je mrkaran.dev. polno domensko ime (FQDN), medtem ko mrkaran.dev ni;
• Iz priručnika za: Najpomembnejši parameter (ta članek govori prav o njem). Iz priručnika za določa mejno število pik v imenu poizvedbe, pri doseganju katerega se to obravnava kot „polno“ domensko ime. O tem bomo govorili kasneje, ko bomo analizirali zaporedje DNS iskanja.

Poglejmo, kaj se zgodi, ko poizvedujemo mrkaran.dev v podu:

$ nslookup mrkaran.dev
Strežnik: 10.152.183.10
Naslov: 10.152.183.10#53

Neavtoriziran odgovor:
Ime: mrkaran.dev
Naslov: 157.230.35.153
Ime: mrkaran.dev
Naslov: 2400:6180:0:d1::519:6001

Za ta eksperiment sem nastavil raven beleženja CoreDNS na all (kar pomeni, da je precej obsežno). Poglejmo na zapise 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

Uf. Dve stvari tukaj pritegnejo pozornost:

• Zahteva poteka skozi vse faze iskanja, dokler odgovor ne vsebuje kode NOERROR (DNS odjemalci ga razumejo in ga shranijo kot rezultat). NXDOMAIN pomeni, da za to domeno zapis ni bil najden. Ker mrkaran.dev ni FQDN ime (v skladu z ndots=5), resolver gleda na iskalno pot in določa vrstni red zahtevkov;
• Zapisi A in AAAA pridejo hkrati. Dejstvo je, da so enkratne zahteve v /etc/resolv.conf privzeto nastavljene tako, da se izvede iskanje hkrati po protokolih IPv4 in IPv6. To obnašanje lahko onemogočite z dodajanjem možnosti single-request u resolv.conf.

Opomba: glibc lahko konfigurirate za zaporedno pošiljanje teh zahtevkov, medtem ko musl — ne, zato naj uporabniki Alpine to upoštevajo.

Eksperimentiramo z ndots

Poglejmo še malo, kako se obnaša ta parameter. Ideja je preprosta: Iz priručnika za določa, ali bo DNS odjemalec domensko ime štel za absolutno ali relativno. Na primer, kako vlagatelj Google DNS ugotovi, ali je to domensko ime absolutno? Če se nastavi Iz priručnika za na 1, bo odjemalec rekel: „O, v Iz priručnika za ni nobene pike; morda bom preletel celotno iskalno listo“. Vendar pa, če je zahtevano google , bo celoten seznam sufiksov ignoriran, ker zahtevano ime izpolnjuje prag google.com(ima vsaj eno piko). Iz priručnika za Poskrbimo, da bo tako:

$ cat /etc/resolv.conf options ndots:1 $ nslookup mrkaran Strežnik: 10.152.183.10 Naslov: 10.152.183.10#53** strežnik ne more najti mrkaran: NXDOMAIN

Zapisi CoreDNS:

Lepi 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

Ker v mrkaran ni nobene pike, je bila iskanja opravljena po celotni iskalni listi.

Opomba: v praksi je največja vrednost Iz priručnika za omejeno na 15; privzeto je v Kubernetesu 5.

Uporaba v proizvodnji

Če aplikacija izvaja številne zunanje omrežne klice, lahko DNS postane ozko grlo pri aktivnem prometu, saj se pri razreševanju imena izvede več nepotrebnih poizvedb (preden sistem pride do pravega). Aplikacije običajno ne dodajo koreninske cone k imenom domen, vendar je to vsekakor v domeni hekanja. Torej namesto, da bi zahtevali api.twitter.com, lahko 'hardcodate' api.twitter.com. (s piko) v aplikacijo, kar bo spodbudilo DNS-odjemalce, da takoj izvedo avtoritativno iskanje v absolutni domeni.

Poleg tega so od različice Kubernetes 1.14 razširitve dnsConfig in ClusterFirst dobile stabilen status. Tako lahko pri razporejanju poda znižate vrednost Iz priručnika za, recimo, na 3 (in celo na 1!). Zaradi tega mora vsako sporočilo znotraj vozlišča vključevati celotno domeno. To je ena klasičnih kompromisov, ko morate izbirati med zmogljivostjo in prenosljivostjo. Menim, da je skrb zaradi tega smiselna le, če so izjemno nizke latence ključnega pomena za vašo aplikacijo, saj so rezultati DNS tudi predpomnjeni znotraj.

Povezave

Prvič sem s to lastnostjo izvedel na K8s-meetupu, ki je potekal 25. januarja. Tam je bila med drugim obravnavana tudi ta težava.

Tukaj je nekaj povezav za nadaljnje raziskovanje:

• Razlaga, zakaj ndots=5 v Kubernetesu;
• Odličen material o tem, kako sprememba ndots vpliva na zmogljivost aplikacije;
• Razlike med resolverji musl in glibc.

Opomba: Raje nisem uporabljal dig v tem članku. dig samodejno doda piko (identifikator koreninske cone), kar naredi domeno 'popolno' (FQDN), ne ko jo najprej pregleda skozi seznam iskanja. O tem sem pisal v eni od prejšnjih objav. Kljub temu je presenetljivo, da je za privzeto obnašanje treba nastaviti ločeno oznako.

Dober DNS-ing! Se vidimo kmalu!

P.S. od prevajalca

Preberite tudi na našem blogu:

• «Calico для сети в Kubernetes: знакомство и немного из опыта»;
• «CoreDNS — DNS strežnik za svet cloud native in service discovery za Kubernetes»;
• «Иллюстрированное руководство по устройству сети в Kubernetes»: части 1 и 2 (сетевая модель, оверлейные сети), часть 3 (сервисы и обработка трафика).

Izvor: habr.com