Opomba. prevod: Težava z DNS v Kubernetesu ali natančneje z nastavitvami parametrov ndots, je presenetljivo priljubljena in že Ne prviletnik. V drugi opombi na to temo njen avtor, inženir DevOps iz velike posredniške družbe v Indiji, na zelo preprost in jedrnat način govori o tem, kaj je koristno vedeti za kolege, ki upravljajo Kubernetes.
Ena od glavnih prednosti uvajanja aplikacij v Kubernetes je brezhibno odkrivanje aplikacij. Interakcija znotraj grozda je močno poenostavljena zahvaljujoč konceptu storitev (Service), ki je navidezni IP, ki podpira niz naslovov IP sklopa. Na primer, če storitev vanilla želi stopiti v stik s servisom chocolate, lahko neposredno dostopa do virtualnega IP-ja za chocolate. Postavlja se vprašanje, komu bo v tem primeru rešil zahtevo DNS chocolate In kako?
Ločljivost imen DNS je konfigurirana v gruči Kubernetes z uporabo CoreDNS. Kubelet registrira pod s CoreDNS kot imenski strežnik v datotekah /etc/resolv.conf vse stroke. Če pogledate vsebino /etc/resolv.conf kateri koli pod, bo videti nekako takole:
To konfiguracijo uporabljajo odjemalci DNS za posredovanje zahtev strežniku DNS. V datoteki resolv.conf vsebuje naslednje podatke:
imenski strežnik: strežnik, na katerega bodo poslane zahteve DNS. V našem primeru je to naslov storitve CoreDNS;
Iskanje: Določa iskalno pot za določeno domeno. Zanimivo je, da google.com ali mrkaran.dev niso FQDN (popolnoma kvalificirana imena domen). V skladu s standardno konvencijo, ki ji sledi večina razreševalcev DNS, samo tiste, ki se končajo s piko ".", ki predstavlja korensko območje, veljajo za popolnoma kvalificirane (FDQN) domene. Nekateri razreševalci lahko sami dodajo točko. torej mrkaran.dev. je popolnoma kvalificirano ime domene (FQDN) in mrkaran.dev - Ne;
ndots: Najbolj zanimiv parameter (o njem govori ta članek). ndots določa mejno število pik v imenu zahteve, preden se šteje za "popolnoma kvalificirano" ime domene. O tem bomo več govorili kasneje, ko bomo analizirali zaporedje iskanja DNS.
Poglejmo, kaj se zgodi, ko vprašamo mrkaran.dev v pod:
Za ta poskus sem nastavil raven beleženja CoreDNS na all (zaradi česar je precej besedno). Poglejmo dnevnike stroka 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. Tukaj pritegneta vašo pozornost dve stvari:
Zahteva gre skozi vse stopnje iskanja, dokler odgovor ne vsebuje kode NOERROR (Odjemalci DNS to razumejo in kot rezultat shranijo). NXDOMAIN pomeni, da za dano ime domene ni bil najden zapis. Zaradi mrkaran.dev ni ime FQDN (v skladu z ndots=5), razreševalec pogleda iskalno pot in določi vrstni red zahtev;
Vpisi А и АААА pridejo vzporedno. Dejstvo je, da enkratne zahteve v /etc/resolv.conf Privzeto so nastavljeni tako, da se vzporedna iskanja izvajajo s protokoloma IPv4 in IPv6. To vedenje lahko prekličete tako, da dodate možnost single-request в resolv.conf.
Opomba: glibc je mogoče konfigurirati za zaporedno pošiljanje teh zahtev in musl - ne, zato naj uporabniki Alpine to upoštevajo.
Eksperimentiranje z ndots
Eksperimentirajmo še malo ndots in poglejmo, kako se ta parameter obnaša. Ideja je preprosta: ndots določa, ali bo odjemalec DNS obravnaval domeno kot absolutno ali relativno. Kako na primer v primeru preprostega Googlovega odjemalca DNS ve, ali je ta domena absolutna? Če nastavite ndots enako 1, bo stranka rekla: "Oh, noter google ni niti ene točke; Predvidevam, da bom šel skozi celoten iskalni seznam." Vendar, če vprašate google.com, bo seznam pripon popolnoma prezrt, ker zahtevano ime dosega prag ndots (obstaja vsaj ena točka).
[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 leta mrkaran ni niti ene točke, iskanje je potekalo po celotnem seznamu končnic.
Opomba: v praksi največja vrednost ndots omejeno na 15; privzeto v Kubernetesu je 5.
Uporaba v proizvodnji
Če aplikacija opravi veliko zunanjih omrežnih klicev, lahko DNS postane ozko grlo v primeru aktivnega prometa, saj razrešitev imen povzroča veliko nepotrebnih poizvedb (preden sistem pride do prave). Aplikacije običajno ne dodajo korenskega območja domenskim imenom, vendar se to sliši kot kramp. Se pravi, namesto da bi vprašal api.twitter.com, ga lahko 'trdo kodirate' api.twitter.com. (s piko) v aplikaciji, kar bo pozvalo odjemalce DNS, da izvedejo avtoritativno iskanje neposredno na absolutni domeni.
Poleg tega, začenši z različico Kubernetes 1.14, razširitve dnsConfig и dnsPolicy dobil stabilen status. Tako lahko pri uvajanju stroka zmanjšate vrednost ndots, recimo do 3 (in celo do 1!). Zaradi tega bo moralo vsako sporočilo v vozlišču vključevati celotno domeno. To je eden od klasičnih kompromisov, ko morate izbirati med zmogljivostjo in prenosljivostjo. Zdi se mi, da bi vas to moralo skrbeti le, če je izjemno nizka zakasnitev bistvenega pomena za vašo aplikacijo, saj so rezultati DNS tudi interno predpomnjeni.
reference
Za to funkcijo sem prvič izvedel na K8s-srečanje, ki je potekal 25. januarja. O tem problemu je med drugim tekla razprava.
Opomba: Odločil sem se, da ne bom uporabljal dig v tem članku. dig samodejno doda piko (identifikator korenskega območja), zaradi česar je domena "popolnoma kvalificirana" (FQDN), ne tako, da ga najprej poženete po iskalnem seznamu. O tem je pisal v ena od prejšnjih objav. Vendar pa je precej presenetljivo, da je treba na splošno določiti ločeno zastavo za standardno vedenje.