DNS-sökning i Kubernetes

Obs. övers.: DNS-problemet i Kubernetes, mer specifikt - inställning av parameter Från manualen för, - är förvånansvärt populärt, och det har redan inte första år. I en ny artikel om detta ämne berättar författaren - en DevOps-ingenjör från ett stort mäklarföretag i Indien - på ett mycket enkelt och koncist sätt vad kollegor som använder Kubernetes behöver känna till.

En av de främsta fördelarna med att distribuera applikationer i Kubernetes är det problemfria upptäckandet av applikationer. Den interna kommunikation inom klustret förenklas avsevärt tack vare tjänstkonceptet (Tjänst), vilket representerar en virtuell IP som stöder en uppsättning IP-adresser av poddar. Till exempel, om tjänsten vanilla vill kommunicera med tjänsten chocolate, kan den direkt hänvisa till den virtuella IP-adressen för chocolate. Frågan uppstår: vem kommer i detta fall att lösa DNS-förfrågan till chocolate och hur?

Namnupplösningen DNS konfigureras i Kubernetes-klustret med hjälp av CoreDNS. Kubelet registrerar podden med CoreDNS som namnserver i filerna /etc/resolv.conf av alla poddar. Om du tittar på innehållet i /etc/resolv.conf vilken pod som helst, kommer det att se ut ungefär så här:

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

Denna konfiguration används av DNS-klienter för att omdirigera förfrågningar till DNS-servern. I filen resolv.conf finns följande information:

• nameserver: servern som DNS-förfrågningar kommer att riktas till. I vårt fall är detta adressen till CoreDNS-tjänsten;
• Det finns en option: definierar sökvägen för ett visst domännamn. Det är intressant att google.com eller mrkaran.dev inte är FQDN (fullständiga domännamn). Enligt den standard som de flesta DNS-resolvrar följer anses fullständiga (FDQN) domäner endast vara de som slutar med en punkt «.», vilket representerar rotzonen. Vissa resolvrar kan lägga till punkten själva. Således är mrkaran.dev. ett fullständigt domännamn (FQDN), medan mrkaran.dev inte är det;
• Från manualen för: Den mest intressanta parametern (denna artikel handlar just om den). Från manualen för anger det tröskelnummer av punkter i namnfrågan, vid vilken den betraktas som ett «fullständigt» domännamn. Mer om detta kommer vi att diskutera senare när vi analyserar sekvensen av DNS-sökningar.

Låt oss titta på vad som händer när vi begär mrkaran.dev i podden:

$ 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

För detta experiment har jag ställt in loggnivån för CoreDNS på all (vilket gör att det blir ganska omfattande). Låt oss titta på loggarna från podden 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

Puh. Två saker här fångar uppmärksamheten:

• Begäran genomgår alla söksteg tills svaret innehåller koden NOERROR (DNS-klienter förstår detta och lagrar det som ett resultat). NXDOMAIN betyder att ingen post hittades för det angivna domännamnet. Eftersom mrkaran.dev inte är ett FQDN-namn (enligt ndots=5), tittar resolvern på sökvägen och bestämmer ordningen för begärningarna;
• Posterna A och AAAAA skickas parallellt. Faktum är att enstaka begärningar i /etc/resolv.conf är som standard inställda så att parallell sökning görs över både IPv4 och IPv6-protokollen. Detta beteende kan avbrytas genom att lägga till alternativet single-request på resolv.conf.

Anmärkning: glibc kan konfigureras för att skicka dessa begärningar sekventiellt, men musl kan inte, så användare av Alpine bör ha detta i åtanke.

Experimentera med ndots

Låt oss experimentera lite mer med Från manualen för och se hur denna parameter beter sig. Idén är enkel: Från manualen för definierar om DNS-klienten ska betrakta domänen som absolut eller relativ. Till exempel, hur vet en enkel google DNS-klient om denna domän är absolut? Om man sätter Från manualen för till 1, kommer klienten att säga: "Åh, i google finns det inga punkter; jag får kanske kolla hela söklistan". Men om man begär google.com, kommer listan med suffix helt att ignoreras, eftersom det begärda namnet uppfyller tröskeln Från manualen för (det finns åtminstone en punkt).

Låt oss se till detta:

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53

** server kan inte hitta mrkaran: NXDOMAIN

CoreDNS-loggar:

[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

Eftersom det i mrkaran det finns inga punkter, sökningen gjordes över hela suffixlistan.

Anmärkning: i praktiken är det maximala värdet Från manualen för begränsat till 15; som standard är det 5 i Kubernetes.

Användning i produktion

Om en applikation gör många externa nätverksanrop kan DNS bli en flaskhals vid aktiv trafik, eftersom många onödiga förfrågningar görs vid namnupplösning (innan systemet når det önskade). Applikationer lägger vanligtvis inte till rotzonen i domännamnen, men detta kan definitivt räknas som ett hack. Med andra ord, istället för att begära api.twitter.com, kan du 'hårdprogrammera' api.twitter.com. (med punkt) i applikationen, vilket får DNS-klienter att omedelbart utföra en auktoritativ sökning i den absoluta domänen.

Dessutom, från och med version 1.14 av Kubernetes, har tilläggen dnsConfig och ClusterFirst fått status som stabila. Därmed kan värdet minskas vid distribution av en pod Från manualen för, låt oss säga, till 3 (och till och med ner till 1!). Detta innebär att varje meddelande inom noden måste innehålla hela domänen. Det här är en klassisk kompromiss när man måste välja mellan prestanda och portabilitet. Jag tycker att man bara ska oroa sig för detta om ultra-låga latenser är avgörande för din applikation, eftersom DNS-resultaten även cachas internt.

Länkar

Jag lärde mig först om denna funktion på K8s-meetup, som hölls den 25 januari. Där diskuterades bland annat detta problem.

Här är några länkar för vidare läsning:

• Förklaring, varför ndots=5 i Kubernetes;
• Ett utmärkt material om hur ändringen av ndots påverkar applikationens prestanda;
• Skillnader mellan resolverna musl och glibc.

Notera: Jag valde att inte använda dig i denna artikel. dig lägger automatisk till en punkt (rotzonens identifierare), vilket gör domänen "full" (FQDN), inte efter att ha kört den genom söklistan. Jag skrev om detta i en av mina tidigare publikationer. Trots detta är det ganska förvånande att man måste ange en separat flagga för standardbeteendet.

Lycka till med DNS! Vi ses snart!

P.S. från översättaren

Läs även i vår blogg:

• «Calico för nätverk i Kubernetes: introduktion och lite erfarenhet»;
• «CoreDNS — DNS-server för cloud native-världen och Service Discovery för Kubernetes»;
• »Illustrerad guide till nätverksuppbyggnaden i Kubernetes«: delar 1 och 2 (nätverksmodell, överlagrade nätverk), del 3 (tjänster och trafikhantering).

Källa: habr.com