🥇 DNS-search in Kubernetes

Bem. overs.: DNS-problemet i Kubernetes, nærmere bestemt indstillingen af parameteren ndots, — er overraskende populær, og det allerede for første gang år. I endnu en artikel om emnet forklarer forfatteren — en DevOps-ingeniør fra et stort mæglerfirma i Indien — på en meget enkel og kortfattet måde, hvad kolleger, der arbejder med Kubernetes, bør vide.

En af de største fordele ved at implementere applikationer i Kubernetes — problemfri opdagelse af applikationer. Interne cluster-interaktioner forenkles markant takket være konceptet med tjenester (Service), som repræsenterer en virtuel IP, der understøtter en række pod-IPs. For eksempel, hvis tjenesten vanilla ønsker at kommunikere med tjenesten chokolade, kan den henvende sig direkte til den virtuelle IP for chokolade. Spørgsmålet opstår: hvem vil i dette tilfælde løse DNS-anmodningen til chokolade og hvordan?

Navnopløsning DNS indstilles i Kubernetes-klusteret ved hjælp af CoreDNS. Kubelet registrerer pod'en med CoreDNS som navneserver i filerne /etc/resolv.conf af alle pod'er. Hvis du ser indholdet af /etc/resolv.conf en hver pod, vil det se omtrent sådan ud:

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

Denne konfiguration bruges af DNS-klienter til at omdirigere anmodninger til DNS-serveren. I filen resolv.conf er følgende information til stede:

navneserver: serveren, som DNS-anmodningerne vil blive sendt til. I vores tilfælde er det adressen på CoreDNS-tjenesten;
search: angiver søgestien for en bestemt domæne. Det er interessant, at google.com eller mrkaran.dev ikke er FQDN (fuldstændige domænenavne). Ifølge den standard, som de fleste resolvere DNS følger, betragtes domæner som fuldstændige (FDQN) kun, hvis de slutter med et punktum «.», der repræsenterer rodzonen. Nogle resolvere kan tilføje punktumet selv. Således er mrkaran.dev. — et fuldstændigt domænenavn (FQDN), mens mrkaran.dev — ikke;
ndots: Den mest interessante parameter (denne artikel handler netop om den). ndots sætter den tærskelværdi for antallet af punkter i anmodningsnavnet, når det overskrides, betragtes det som et «fuldstændigt» domænenavn. Vi vil tale mere om det senere, når vi analyserer sekvensen af DNS-søgning.

Lad os se, hvad der sker, når vi anmoder om mrkaran.dev i pod'en:

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Ikke-autoritativt svar:
Navn: mrkaran.dev
Adresse: 157.230.35.153
Navn: mrkaran.dev
Adresse: 2400:6180:0:d1::519:6001

For this experiment, I set the CoreDNS logging level to alle (which makes it quite verbose). Let's take a look at the logs of the 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

Phew. Two things here stand out:

The query goes through all stages of resolution until it receives a response containing the code NOERROR (which DNS clients understand and treat as a successful result). NXDOMAIN indicates that there is no record for the specified domain name. Since mrkaran.dev is not an FQDN (according to ndots=5), the resolver looks at the search path and determines the order of queries;
Records A og AAAA are processed in parallel. The thing is, one-off queries in /etc/resolv.conf are by default configured to perform a parallel search across both IPv4 and IPv6 protocols. This behavior can be overridden by adding the option single-request i resolv.conf.

Bemærk: glibc to configure these requests to be sent sequentially, while musl — no, so Alpine users should keep this in mind.

Experimenting with ndots

Let's experiment a bit more with ndots and see how this parameter behaves. The idea is simple: ndots determines whether the DNS client treats the domain as absolute or relative. For example, how does a simple Google DNS client know if this domain is absolute? If you set ndots to 1, the client will say: "Oh, in google there's not a single dot; I guess I'll go through the entire search list." However, if you query google.com, the list of suffixes will be entirely ignored since the requested name meets the threshold ndots (there's at least one dot).

Let's verify that:

$ 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 logs:

[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

Since there are no dots in mrkaran , the search was conducted across the entire suffix list.

Note: in practice, the maximum value ndots begrænset til 15; som standard er det 5 i Kubernetes.

Anvendelse i produktion

Hvis en applikation foretager mange eksterne netværksopkald, kan DNS blive en flaskehals under aktiv trafik, da der udføres mange unødvendige forespørgsler ved navneopslag (før systemet når frem til det, det har brug for). Applikationer tilføjer typisk ikke rodområdet til domænenavne, men det kan godt anses som et hack. Det vil sige, i stedet for at anmode om api.twitter.com, kan du 'hardcode' api.twitter.com. (med punktum) i applikationen, hvilket får DNS-klienter til straks at udføre en autoritativ søgning på det absolutte domæne.

Derudover har udvidelserne, fra og med version 1.14 af Kubernetes, fået status som stabile. Således kan du ved implementering af en pod sænke værdien dnsConfig og dnsPolicy , lad os sige, til 3 (eller endda til 1!). Dette betyder, at hver besked inden for noden skal inkludere det fulde domæne. Dette er en klassisk afvejning, når man skal vælge mellem ydeevne og bærbarhed. Jeg mener, det er værd at bekymre sig om kun hvis overordentlig lave forsinkelser er livsvigtige for din applikation, da DNS-resultater også bliver cachelagret internt. ndotsJeg lærte først om dette fænomen på

Links

K8s-m mødet , der fandt sted den 25. januar. Der blev blandt andet talt om dette problem.Her er nogle links til videre udforskning:

Forklaring

, hvorfor ndots=5 i Kubernetes;Fremragende materiale
om hvordan ændring af ndots påvirker applikationens ydeevne; Uoverensstemmelser
mellem musl og glibc resolvere. Bemærk: Jeg valgte ikke at bruge

i denne artikel. dig tilføjer automatisk et punkt (identifikator for rodområdet), hvilket gør domænet 'komplet' (FQDN), dig ved at køre det forud gennem søgelisten. Jeg har skrevet om dette i ikke et af mine tidligere indlæg . Alligevel er det ret overraskende, at man generelt må indstille en separat flag for standardadfærden.God DNS'ings! Vi ses snart!

CoreDNS - DNS-server for cloud native verden og Service Discovery for Kubernetes