Opomba. prevod: Težava z DNS v Kubernetesu ali natančneje z nastavitvami parametrov ndots, je presenetljivo priljubljena in že . 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 (), 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 . 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:
search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5
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.comalimrkaran.devniso FQDN (). 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. torejmrkaran.dev.je popolnoma kvalificirano ime domene (FQDN) inmrkaran.dev- Ne; - ndots: Najbolj zanimiv parameter (o njem govori ta članek).
ndotsdoloč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:
$ 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
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.145091744sFuj. 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).NXDOMAINpomeni, da za dano ime domene ni bil najden zapis. Zaradimrkaran.devni ime FQDN (v skladu zndots=5), razreševalec pogleda iskalno pot in določi vrstni red zahtev; - Vpisi
АиААААpridejo vzporedno. Dejstvo je, da enkratne zahteve v/etc/resolv.confPrivzeto so nastavljeni tako, da se vzporedna iskanja izvajajo s protokoloma IPv4 in IPv6. To vedenje lahko prekličete tako, da dodate možnostsingle-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).
Prepričajmo se o tem:
$ 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: NXDOMAINDnevniki 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 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 , ki je potekal 25. januarja. O tem problemu je med drugim tekla razprava.
Tukaj je nekaj povezav za nadaljnje raziskovanje:
- , zakaj ndots=5 v Kubernetesu;
- kako spreminjanje ndot vpliva na delovanje aplikacije;
- med razreševalcema musl in glibc.
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 . Vendar pa je precej presenetljivo, da je treba na splošno določiti ločeno zastavo za standardno vedenje.
Srečno DNS! Se vidimo kasneje!
PS od prevajalca
Preberite tudi na našem blogu:
- «»;
- «»;
- "Ilustriran vodnik za mreženje v Kubernetesu": , .
Vir: www.habr.com