DNS-søk i Kubernetes

Obs. overs.: DNS-problemet i Kubernetes, mer spesifikt — konfigurasjonen av parameteren ndots, — er overraskende populært, faktisk allerede for første gang år. I en ny artikkel om dette temaet forklarer forfatteren — en DevOps-ingeniør fra et stort meglerfirma i India — på en ganske enkel og kortfattet måte hva kolleger som bruker Kubernetes bør vite.

En av de viktigste fordelene ved å distribuere applikasjoner i Kubernetes — problemfri oppdagelse av applikasjoner. Interne klyngeinteraksjoner forenkles betydelig takket være konseptet med en tjeneste (Service), som representerer en virtuell IP som støtter et sett med IP-adresser for pods. For eksempel, hvis tjenesten vanilla ønsker å koble til tjenesten chocolate, kan den kontakte den virtuelle IP-en direkte for chocolate. Spørsmålet oppstår: hvem vil i dette tilfellet løse DNS-forespørselen til chocolate og hvordan?

DNS-navneoppløsning konfigureres i Kubernetes-klyngen ved hjelp av CoreDNS. Kubelet angir pod med CoreDNS som navneserver i filene /etc/resolv.conf til alle pods. Hvis vi ser på innholdet i /etc/resolv.conf en hvilken som helst pod, vil den se omtrent slik ut:

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

Denne konfigurasjonen brukes av DNS-klienter for å sende forespørslene til DNS-serveren. I filen resolv.conf finnes følgende informasjon:

• nameserver: serveren som DNS-forespørslene vil bli sendt til. I vårt tilfelle er dette adressen til CoreDNS-tjenesten;
• search: angir søkestien for et spesifikt domene. Det er interessant at google.com eller mrkaran.dev ikke er FQDN (fullstendige domener). I henhold til standardavtalen som de fleste DNS-resolvere følger, anses domener som fullstendige (FQDN) bare hvis de slutter med et punkt «.», som representerer rotsonen. Noen resolvere kan legge til et punkt selv. Dermed er mrkaran.dev. — et fullstendig domenenavn (FQDN), mens mrkaran.dev — ikke;
• ndots: Den mest interessante parameteren (denne artikkelen handler faktisk om den). ndots angir terskelverdien for antall punkter i navnet som en forespørsel har, og når denne terskelen nås, anses den som et «fullstendig» domenenavn. Mer om dette vil vi diskutere senere, når vi analyserer sekvensen av DNS-oppslag.

La oss se hva som skjer når vi forespør 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 dette eksperimentet har jeg satt logging-nivået til CoreDNS til all (som gjer det ganske omstendelig). La oss se på loggene til pod’en 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. To ting her tiltrekker oppmerksomhet:

• Forespørselen går gjennom alle søketrinnene så lenge svaret ikke inneholder koden NOERROR (DNS-klienter forstår det og lagrer det som et resultat). NXDOMAIN betyr at det ikke ble funnet noen oppføring for dette domenenavnet. Fordi mrkaran.dev ikke er et FQDN-navn (i henhold til ndots=5), resolveren ser på søkestien og bestemmer rekkefølgen på forespørslene;
• Oppføringene A og AAAA sendes parallelt. Poenget er at enkeltforespørslene i /etc/resolv.conf som standard er konfigurert slik at det skjer et parallelt søk over IPv4 og IPv6-protokollene. Dette atferden kan avbrytes ved å legge til alternativet single-request i resolv.conf.

Merk: glibc som kan konfigureres for sekvensiell sending av disse forespørslene, mens musl – det kan ikke, så brukere av Alpine bør ta dette i betraktning.

La oss eksperimentere med ndots

La oss eksperimentere litt mer med ndots og se hvordan denne parameteren oppfører seg. Ideen er enkel: ndots definerer om DNS-klienten skal behandle domenet som absolutt eller relativt. For eksempel, hvordan kan en enkel google DNS-klient vite om dette domenet er absolutt? Hvis du setter ndots til 1, vil klienten si: «Åh, i google det er ingen prikker; kanskje jeg skal se gjennom hele søkelisten». Men hvis du forespør google.com, vil listen over suffikser bli helt ignorert, siden det forespurte navnet tilfredsstiller grensen ndots (det er minst én prikk).

La oss forsikre oss om dette:

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

** server kan ikke finne mrkaran: NXDOMAIN

Loggar för 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

Sidan ein kan ikkje definere tabellhint, må ein lage ei ny visning — «innpakning» av følgjande slag: mrkaran det er ingen prikker, søket ble gjort gjennom hele listen over suffikser.

Merk: i praksis er den maksimale verdien ndots begrenset til 15; standardverdien i Kubernetes er 5.

Bruk i produksjon

Hvis en applikasjon gjør mange eksterne nettverksanrop, kan DNS bli en flaskehals under aktiv trafikk, ettersom det gjør mange unødvendige forespørselser når den løser navnet før systemet kommer til målet. Applikasjoner legger vanligvis ikke til rotsonen til domenenavnene, men dette kan absolutt betraktes som en hack. Det vil si at i stedet for å be om api.twitter.com, kan du 'hardcode'e api.twitter.com. (med punktum) i applikasjonen, noe som vil få DNS-klienter til å utføre en autoritativ søk med en gang i det absolutte domenet.

I tillegg, fra og med Kubernetes versjon 1.14, har utvidelser dnsConfig og dnsPolicy fått stabil status. Dermed kan verdien når du distribuerer en pod reduseres, la oss si, til 3 (og til og med til 1!). På grunn av dette må hver melding innenfor noden inkludere det fullstendige domenet. Dette er et klassisk kompromiss når du må velge mellom ytelse og bærbarhet. Jeg mener det er verdt å bekymre seg for dette bare hvis ekstremt lave forsinkelser er avgjørende for applikasjonen din, ettersom DNS-resultater også blir hurtigbufret internt. ndotsJeg lærte om denne funksjonen for første gang på

Lenker

K8s-meetup , som fant sted 25. januar. Det ble blant annet diskutert dette problemet.Her er noen lenker for videre studier:

, hvorfor ndots=5 i Kubernetes;

• ForklaringFlott materiale
• om hvordan endring av ndots påvirker applikasjonsytelsen; Uoverensstemmelser
• mellom musl og glibc resolvere. Merk: Jeg valgte å ikke bruke

i denne artikkelen. dig automatisk legger til et punkt (roten identifikator), som gjør domenet "fullt" (FQDN), dig ved å kjøre det gjennom søklisten først. Jeg skrev om dette i ikke et tidligere innlegg . Likevel, det er ganske overraskende at for standard oppførsel, må du sette et eget flagg.God DNS’ing! Vi sees snart!

🥇DNS-søk i Kubernetes | ProHoster

P.S. from the translator

Also read in our blog:

• «Calico for networking in Kubernetes: an introduction and some experience»;
• «CoreDNS — DNS-server for cloud native verden og Service Discovery for Kubernetes»;
• Illustrated Guide to Networking in Kubernetes: parts 1 and 2 (network model, overlay networks), part 3 (services and traffic management).

Kilde: habr.com