🥇Ricerca DNS in Kubernetes

Nota. transl.: Problema di DNS in Kubernetes, o più precisamente, paràmetri di paràmetri ndots, hè sorprendentemente populari, è digià Micca prima annu. In una altra nota nantu à questu tema, u so autore, un ingegnere DevOps da una grande cumpagnia di brokerage in India, parla in una manera assai simplice è cuncisa di ciò chì hè utile per i culleghi chì operanu Kubernetes per sapè.

Unu di i vantaghji principali di implementà l'applicazioni in Kubernetes hè a scuperta di l'applicazioni senza saldatura. L'interazzione intra-cluster hè assai simplificata grazia à u cuncettu di serviziu (Service), chì hè una IP virtuale chì sustene un settore di indirizzi IP pod. Per esempiu, se u serviziu vanilla vole cuntattà u serviziu chocolate, pò accede direttamente à l'IP virtuale per chocolate. A quistione hè: quale in questu casu risolverà a dumanda DNS chocolate È cumu ?

A risoluzione di u nome DNS hè cunfigurata in un cluster Kubernetes utilizendu CoreDNS. Kubelet registra un pod cù CoreDNS cum'è un servitore di nomi in i schedari /etc/resolv.conf tutti i baccelli. Se guardate u cuntenutu /etc/resolv.conf qualsiasi pod, parerà qualcosa cusì:

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

Sta cunfigurazione hè aduprata da i clienti DNS per rinvià e dumande à u servitore DNS. In u schedariu resolv.conf cuntene l'infurmazioni seguenti:

servitore di nomi: servitore à quale seranu mandate e dumande DNS. In u nostru casu, questu hè l'indirizzu di u serviziu CoreDNS;
local: Definisce u percorsu di ricerca per un duminiu specificu. Hè interessante chì google.com o mrkaran.dev ùn sò micca FQDN (nomi di duminiu cumplettamente qualificati). Sicondu a cunvenzione standard chì a maiò parte di i resolutori DNS seguitanu, solu quelli chì finiscinu cù un puntu ".", chì rapprisentanu a zona radicali, sò cunsiderati domini cumpletamente qualificati (FDQN). Certi resolutori ponu aghjunghje un puntu stessu. Cusì, mrkaran.dev. hè u nome di duminiu cumplettamente qualificatu (FQDN), è mrkaran.dev - Innò;
ndots: U paràmetru più interessante (stu articulu hè nantu à questu). ndots specifica u numaru di punti in un nome di dumanda prima ch'ellu sia cunsideratu un nome di duminiu "completamente qualificatu". Parlaremu più nantu à questu dopu quandu analizemu a sequenza di ricerca DNS.

Videmu ciò chì succede quandu dumandemu mrkaran.dev in 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

Per questu esperimentu, aghju stabilitu u livellu di logging CoreDNS à all (chì a rende abbastanza verbose). Fighjemu i logs di u 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

Uff. Dui cose catturà a vostra attenzione quì:

A dumanda passa per tutte e tappe di a ricerca finu à chì a risposta cuntene u codice NOERROR (I clienti DNS capiscenu è l'almacenanu com'è u risultatu). NXDOMAIN significa chì ùn hè statu trovu nisun record per u nome di duminiu datu. Perchè u mrkaran.dev ùn hè micca un nome FQDN (sicondu ndots=5), u resolutore guarda u percorsu di ricerca è determina l'ordine di e dumande;
Posti А и АААА ghjunghje in parallelu. U fattu hè chì e dumande una volta in /etc/resolv.conf Per automaticamente, sò cunfigurati in modu chì e ricerche parallele sò realizate cù i protokolli IPv4 è IPv6. Pudete annullà stu cumpurtamentu aghjunghjendu l'opzione single-request в resolv.conf.

Nutate bè: glibc pò esse cunfigurati per mandà sti richieste sequentially, è musl - nò, cusì l'utilizatori di l'Alpi anu da piglià nota.

Sperimentendu cù ndots

Sperimentemu un pocu di più ndots è vedemu cumu si cumporta stu paràmetru. L'idea hè simplice: ndots determina se u cliente DNS trattarà u duminiu cum'è assolutu o relativo. Per esempiu, in u casu di un clientu DNS Google simplice, cumu si sà se stu duminiu hè assolutu? Sè avete stabilitu ndots uguale à 1, u cliente dicerà: "Oh, in google ùn ci hè micca un puntu; Pensu chì andaraghju per tutta a lista di ricerca ". Tuttavia, si dumanda google.com, a lista di i suffissi serà completamente ignorata perchè u nome dumandatu scontra u limitu ndots (ci hè almenu un puntu).

Assicuratevi di questu:

$ 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

logs 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

Dapoi in mrkaran ùn ci hè micca un puntu unicu, a ricerca hè stata fatta in tutta a lista di suffissi.

Nota: in pratica u valore massimu ndots limitatu à 15; per difettu in Kubernetes hè 5.

Applicazione in a produzzione

Se una applicazione face assai chjama di rete esterna, DNS pò diventà un collu di buttiglia in u casu di u trafficu attivu, postu chì a risoluzione di u nome fa parechje dumande innecessarii (prima chì u sistema ghjunghje à u dirittu). L'applicazioni di solitu ùn aghjunghjenu micca una zona radicali à i nomi di duminiu, ma questu sona cum'è un pirate. Hè, invece di dumandà api.twitter.com, pudete 'hardcode' api.twitter.com. (cù un puntu) in l'applicazione, chì incitarà i clienti DNS à fà ricerche autoritarii direttamente nantu à u duminiu assolutu.

Inoltre, partendu da a versione Kubernetes 1.14, estensioni dnsConfig и dnsPolicy ricevutu un statutu stabile. Cusì, quandu implementate un pod, pudete riduce u valore ndots, dì, finu à 3 (è ancu finu à 1!). Per quessa, ogni missaghju in un node duverà include u duminiu tutale. Questu hè unu di i cummerci classici quandu avete da sceglie trà u rendiment è a portabilità. Mi pare chì duvete preoccupassi di questu solu se a latenza ultra-bassa hè vitale per a vostra applicazione, postu chì i risultati DNS sò ancu in cache internu.

referenze

Prima aghju amparatu nantu à sta funzione K8s-incontru, tenuta u 25 di ghjennaghju. Ci hè stata una discussione annantu à questu prublema, frà altri cose.

Eccu alcuni ligami per più esplorazione:

Spiegazione, perchè ndots=5 in Kubernetes;
Grande roba cumu u cambiamentu di ndots affetta u rendiment di l'applicazione;
Discrepanzii trà i risolveri musl è glibc.

Nota: aghju sceltu di ùn aduprà dig in questu articulu. dig aghjunghje automaticamente un puntu (identificatore di a zona radicali), facendu u duminiu "cualmente qualificatu" (FQDN), ùn da prima eseguisce à traversu a lista di ricerca. Hà scrittu annantu à questu in una di e publicazioni precedenti. Tuttavia, hè abbastanza surprisante chì, in generale, una bandiera separata deve esse specificatu per u cumpurtamentu standard.

Felice DNSing! A prestu!

PS da u traduttore

Leghjite puru nant'à u nostru blog:

«Calico per a rete in Kubernetes: introduzione è un pocu di sperienza";
«CoreDNS - Servitore DNS per u mondu nativu di nuvola è Service Discovery per Kubernetes";
"Una guida illustrata per a rete in Kubernetes": parte 1 è 2 (mudellu di rete, rete di overlay), parte 3 (servizii è trasfurmazioni di trafficu).

Source: www.habr.com

Ricerca DNS in Kubernetes

Sperimentendu cù ndots

Applicazione in a produzzione

referenze

PS da u traduttore

Add a comment annuler risponde