DNS-sökning i Kubernetes

Notera. transl.: DNS-problem i Kubernetes, eller mer exakt, parameterinställningar ndots, är förvånansvärt populärt och redan Inte den första år. I en annan anteckning om detta ämne berättar dess författare, en DevOps-ingenjör från ett stort mäklarföretag i Indien, på ett mycket enkelt och kortfattat sätt om vad som är användbart för kollegor som driver Kubernetes att veta.

En av de främsta fördelarna med att distribuera applikationer på Kubernetes är sömlös applikationsupptäckt. Interaktion inom kluster förenklas avsevärt tack vare tjänstekonceptet (Service), som är en virtuell IP som stöder en uppsättning pod-IP-adresser. Till exempel om tjänsten vanilla vill kontakta tjänsten chocolate, kan den komma direkt åt den virtuella IP-adressen för chocolate. Frågan uppstår: vem i detta fall kommer att lösa DNS-förfrågan till chocolate Och hur?

DNS-namnupplösning konfigureras på ett Kubernetes-kluster med hjälp av CoreDNS. Kubelet registrerar en pod med CoreDNS som namnserver i filer /etc/resolv.conf alla baljor. Om man tittar på innehållet /etc/resolv.conf vilken pod som helst kommer den 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 vidarebefordra förfrågningar till DNS-servern. I fil resolv.conf innehåller följande information:

• namnserver: server till vilken DNS-förfrågningar kommer att skickas. I vårt fall är detta adressen till CoreDNS-tjänsten;
• Sök: Definierar sökvägen för en specifik domän. Det är intressant det där google.com eller mrkaran.dev är inte FQDN (fullt kvalificerade domännamn). Enligt standardkonventionen som de flesta DNS-upplösare följer, anses endast de som slutar med en punkt ".", som representerar rotzonen, vara fullt kvalificerade (FDQN) domäner. Vissa lösare kan lägga till en punkt själva. Således, mrkaran.dev. är det fullt kvalificerade domännamnet (FQDN), och mrkaran.dev - Nej;
• prickar: Den mest intressanta parametern (den här artikeln handlar om det). ndots anger tröskeln för antalet punkter i ett förfrågningsnamn innan det anses vara ett "fullständigt kvalificerat" domännamn. Vi kommer att prata mer om detta senare när vi analyserar DNS-uppslagssekvensen.

Låt oss se vad som händer när vi frågar mrkaran.dev i 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

För det här experimentet ställde jag in CoreDNS-loggningsnivån till all (vilket gör det ganska mångsidigt). Låt oss titta på poddens loggar 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 fångar din uppmärksamhet här:

• Förfrågan går igenom alla steg i sökningen tills svaret innehåller koden NOERROR (DNS-klienter förstår det och lagrar det som ett resultat). NXDOMAIN betyder att ingen post hittades för det angivna domännamnet. Eftersom den mrkaran.dev är inte ett FQDN-namn (enligt ndots=5), resolver tittar på sökvägen och bestämmer ordningen på förfrågningar;
• Inspelningar А и АААА anlända parallellt. Faktum är att engångsförfrågningar in /etc/resolv.conf Som standard är de konfigurerade på ett sådant sätt att parallella sökningar utförs med IPv4- och IPv6-protokollen. Du kan avbryta detta beteende genom att lägga till alternativet single-request в resolv.conf.

Notera: glibc kan konfigureras för att skicka dessa förfrågningar sekventiellt, och musl - nej, så alpina användare bör notera det.

Experimenterar med ndotter

Låt oss experimentera lite mer med ndots och låt oss se hur den här parametern beter sig. Tanken är enkel: ndots avgör om DNS-klienten kommer att behandla domänen som absolut eller relativ. Till exempel, i fallet med en enkel Google DNS-klient, hur vet den om denna domän är absolut? Om du ställer in ndots lika med 1 kommer klienten att säga: "Åh, in google det finns inte en enda punkt; Jag antar att jag ska gå igenom hela söklistan." Men om du frågar google.com, kommer listan med suffix att ignoreras helt eftersom det begärda namnet når tröskeln ndots (det finns åtminstone en poäng).

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 can't find 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

Sedan i mrkaran det finns inte en enda punkt, sökningen utfördes över hela listan med suffix.

Obs: i praktiken maxvärdet ndots begränsat till 15; som standard i Kubernetes är det 5.

Applikation i produktion

Om en applikation gör många externa nätverksanrop kan DNS bli en flaskhals vid aktiv trafik, eftersom namnupplösning gör många onödiga frågor (innan systemet kommer till rätt). Applikationer lägger vanligtvis inte till en rotzon till domännamn, men detta låter som ett hack. Det vill säga istället för att fråga api.twitter.com, kan du "hårdkoda" den api.twitter.com. (med en prick) i applikationen, vilket kommer att uppmana DNS-klienter att utföra auktoritativa sökningar direkt på den absoluta domänen.

Dessutom, från och med Kubernetes version 1.14, tillägg dnsConfig и dnsPolicy fått stabil status. När du distribuerar en pod kan du alltså minska värdet ndotssäg upp till 3 (och till och med upp till 1!). På grund av detta måste varje meddelande inom en nod inkludera hela domänen. Detta är en av de klassiska avvägningarna när du ska välja mellan prestanda och portabilitet. Det verkar för mig att du bara ska oroa dig för detta om ultralåg latens är avgörande för din applikation, eftersom DNS-resultaten också cachelagras internt.

referenser

Jag lärde mig först om den här funktionen på K8s-träff, som hölls den 25 januari. Det diskuterades bland annat om detta problem.

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

• förklaring, varför ndots=5 i Kubernetes;
• Utmärkt material hur ändring av ndots påverkar applikationens prestanda;
• Diskrepanser mellan musl och glibc resolver.

Obs: Jag valde att inte använda dig i den här artikeln. dig lägger automatiskt till en punkt (rotzonsidentifierare), vilket gör domänen "fullständigt kvalificerad" (FQDN), ingen genom att först köra den genom söklistan. Skrev om detta i en av de tidigare publikationerna. Det är dock ganska förvånande att en separat flagga i allmänhet måste anges för standardbeteendet.

Glad DNSing! Vi ses senare!

PS från översättaren

Läs även på vår blogg:

• «Calico för nätverk i Kubernetes: introduktion och lite erfarenhet";
• «CoreDNS - DNS-server för molnvärlden och Service Discovery för Kubernetes";
• "En illustrerad guide till nätverk i Kubernetes": del 1 och 2 (nätverksmodell, överläggsnätverk), del 3 (tjänster och trafikhantering).

Källa: will.com