Căutare DNS în Kubernetes

Notă. transl.: problemă DNS în Kubernetes, sau mai precis, setările parametrilor ndots, este surprinzător de popular și deja Nu primul an. Într-o altă notă pe această temă, autorul său, un inginer DevOps de la o mare companie de brokeraj din India, vorbește într-un mod foarte simplu și concis despre ceea ce este util să știe colegii care operează Kubernetes.

Unul dintre principalele beneficii ale implementării aplicațiilor pe Kubernetes este descoperirea fără întreruperi a aplicațiilor. Interacțiunea intra-cluster este mult simplificată datorită conceptului de serviciu (serviciu), care este un IP virtual care acceptă un set de adrese IP pod. De exemplu, dacă serviciul vanilla dorește să contacteze serviciul chocolate, poate accesa direct IP-ul virtual pentru chocolate. Se pune întrebarea: cui va rezolva în acest caz cererea DNS chocolate Si cum?

Rezoluția numelui DNS este configurată pe un cluster Kubernetes folosind CoreDNS. Kubelet înregistrează un pod cu CoreDNS ca server de nume în fișiere /etc/resolv.conf toate păstăile. Dacă te uiți la conținut /etc/resolv.conf orice pod, va arăta cam așa:

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

Această configurație este utilizată de clienții DNS pentru a redirecționa cereri către serverul DNS. În dosar resolv.conf conține următoarele informații:

• server de nume: server la care vor fi trimise cererile DNS. În cazul nostru, aceasta este adresa serviciului CoreDNS;
• căutare: definește calea de căutare pentru un anumit domeniu. Este interesant că google.com sau mrkaran.dev nu sunt FQDN (nume de domenii complet calificate). Conform convenției standard pe care o urmează majoritatea rezolutorilor DNS, doar cele care se termină cu un punct „.”, reprezentând zona rădăcină, sunt considerate domenii complet calificate (FDQN). Unii rezolutori pot adăuga ei înșiși un punct. Prin urmare, mrkaran.dev. este numele de domeniu complet calificat (FQDN) și mrkaran.dev - Nu;
• ndots: Cel mai interesant parametru (acest articol este despre el). ndots specifică numărul prag de puncte dintr-un nume de solicitare înainte ca acesta să fie considerat un nume de domeniu „complet calificat”. Vom vorbi mai multe despre asta mai târziu când vom analiza secvența de căutare DNS.

Să vedem ce se întâmplă când întrebăm mrkaran.dev în 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

Pentru acest experiment, am setat nivelul de înregistrare CoreDNS la all (ceea ce o face destul de verbosă). Să ne uităm la jurnalele podului 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. Două lucruri vă atrag atenția aici:

• Solicitarea trece prin toate etapele căutării până când răspunsul conține codul NOERROR (Clienții DNS îl înțeleg și îl stochează ca rezultat). NXDOMAIN înseamnă că nu a fost găsită nicio înregistrare pentru numele de domeniu dat. Deoarece mrkaran.dev nu este un nume FQDN (conform ndots=5), resolverul se uită la calea de căutare și determină ordinea solicitărilor;
• Înregistrări А и АААА ajunge în paralel. Faptul este că solicitările unice în /etc/resolv.conf În mod implicit, acestea sunt configurate astfel încât căutările paralele să fie efectuate folosind protocoalele IPv4 și IPv6. Puteți anula acest comportament adăugând opțiunea single-request в resolv.conf.

Nota: glibc poate fi configurat să trimită aceste solicitări secvenţial, şi musl - nu, deci utilizatorii Alpine ar trebui să ia notă.

Experimentarea cu ndots

Să mai experimentăm puțin ndots și să vedem cum se comportă acest parametru. Ideea este simpla: ndots determină dacă clientul DNS va trata domeniul ca absolut sau relativ. De exemplu, în cazul unui simplu client Google DNS, de unde știe dacă acest domeniu este absolut? Dacă setați ndots egal cu 1, clientul va spune: „Oh, în google nu există un singur punct; Cred că voi parcurge întreaga listă de căutare.” Totuși, dacă întrebi google.com, lista de sufixe va fi complet ignorată deoarece numele solicitat îndeplinește pragul ndots (există cel puțin un punct).

Să ne asigurăm de asta:

$ 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

Jurnalele 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

De când în mrkaran nu există un singur punct, căutarea a fost efectuată pe întreaga listă de sufixe.

Notă: în practică valoarea maximă ndots limitat la 15; implicit în Kubernetes este 5.

Aplicare în producție

Dacă o aplicație efectuează multe apeluri de rețea externă, DNS poate deveni un blocaj în cazul traficului activ, deoarece rezoluția numelui face multe interogări inutile (înainte ca sistemul să ajungă la cea potrivită). Aplicațiile de obicei nu adaugă o zonă rădăcină la numele de domenii, dar acest lucru sună ca un hack. Adică, în loc să întrebi api.twitter.com, îl puteți „coda” pe hard api.twitter.com. (cu un punct) în aplicație, care va solicita clienților DNS să efectueze căutări de autoritate direct pe domeniul absolut.

În plus, începând cu Kubernetes versiunea 1.14, extensii dnsConfig и dnsPolicy a primit statut stabil. Astfel, la implementarea unui pod, puteți reduce valoarea ndots, să zicem, până la 3 (și chiar până la 1!). Din acest motiv, fiecare mesaj dintr-un nod va trebui să includă întregul domeniu. Acesta este unul dintre compromisurile clasice atunci când trebuie să alegeți între performanță și portabilitate. Mi se pare că ar trebui să vă faceți griji pentru acest lucru numai dacă latența ultra-scăzută este vitală pentru aplicația dvs., deoarece rezultatele DNS sunt și ele stocate în cache.

referințe

Am aflat prima dată despre această funcție pe K8s-întâlnire, a avut loc pe 25 ianuarie. A fost o discuție despre această problemă, printre altele.

Iată câteva link-uri pentru o explorare suplimentară:

• explicație, de ce ndots=5 în Kubernetes;
• Lucruri minunate modul în care schimbarea ndots afectează performanța aplicației;
• Discrepanțele între rezolutorii musl și glibc.

Notă: am ales să nu folosesc dig în acest articol. dig adaugă automat un punct (identificator de zonă rădăcină), făcând domeniul „complet calificat” (FQDN), nu mai întâi rulând-o prin lista de căutare. A scris despre asta în una dintre publicațiile anterioare. Cu toate acestea, este destul de surprinzător că, în general, trebuie specificat un steag separat pentru comportamentul standard.

DNSing fericit! Ne vedem mai târziu!

PS de la traducator

Citește și pe blogul nostru:

• «Calico pentru networking în Kubernetes: introducere și puțină experiență»;
• «CoreDNS - server DNS pentru lumea nativă cloud și Service Discovery pentru Kubernetes»;
• „Un ghid ilustrat pentru crearea de rețele în Kubernetes”: părțile 1 și 2 (model de rețea, rețele de suprapunere), partea 3 (servicii și procesarea traficului).

Sursa: www.habr.com