DNS-oppslag i Kubernetes

Merk. overs.: DNS-problem i Kubernetes, eller mer presist, parameterinnstillinger ndots, er overraskende populær, og allerede Ikke først år. I et annet notat om dette emnet snakker forfatteren, en DevOps-ingeniør fra et stort meglerselskap i India, på en veldig enkel og kortfattet måte om hva som er nyttig for kolleger som driver Kubernetes å vite.

En av hovedfordelene med å distribuere applikasjoner på Kubernetes er sømløs applikasjonsoppdagelse. Intra-klyngeinteraksjon er betydelig forenklet takket være tjenestekonseptet (Service), som er en virtuell IP som støtter et sett med pod-IP-adresser. For eksempel hvis tjenesten vanilla ønsker å kontakte tjenesten chocolate, kan den få direkte tilgang til den virtuelle IP-en for chocolate. Spørsmålet oppstår: hvem vil i dette tilfellet løse DNS-forespørselen til chocolate Og hvordan?

DNS-navneoppløsning er konfigurert på en Kubernetes-klynge ved hjelp av KjerneDNS. Kubelet registrerer en pod med CoreDNS som navneserver i filer /etc/resolv.conf alle pods. Hvis du ser på innholdet /etc/resolv.conf 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 til å videresende forespørsler til DNS-serveren. I fil resolv.conf inneholder følgende informasjon:

• navneserver: server som DNS-forespørsler vil bli sendt til. I vårt tilfelle er dette adressen til CoreDNS-tjenesten;
• Søk: Definerer søkebanen for et spesifikt domene. Det er interessant det google.com eller mrkaran.dev er ikke FQDN (fullt kvalifiserte domenenavn). I henhold til standardkonvensjonen som de fleste DNS-resolvere følger, er det bare de som slutter med en prikk ".", som representerer rotsonen, som anses som fullt kvalifiserte (FDQN) domener. Noen løsere kan legge til et poeng selv. Dermed, mrkaran.dev. er det fullt kvalifiserte domenenavnet (FQDN), og mrkaran.dev - Nei;
• ndotter: Den mest interessante parameteren (denne artikkelen handler om det). ndots angir terskelantallet for prikker i et forespørselsnavn før det anses som et "fullt kvalifisert" domenenavn. Vi snakker mer om dette senere når vi analyserer DNS-oppslagssekvensen.

La oss se hva som skjer når vi spør 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

For dette eksperimentet satte jeg CoreDNS-loggingsnivået til all (noe som gjør det ganske detaljert). La oss se på podens logger 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 fanger oppmerksomheten din her:

• Forespørselen går gjennom alle stadier av søket til svaret inneholder koden NOERROR (DNS-klienter forstår det og lagrer det som et resultat). NXDOMAIN betyr at ingen oppføring ble funnet for det oppgitte domenenavnet. Fordi det mrkaran.dev er ikke et FQDN-navn (ifølge ndots=5), resolver ser på søkebanen og bestemmer rekkefølgen på forespørslene;
• Innspillinger А и АААА kommer parallelt. Faktum er at engangsforespørsler inn /etc/resolv.conf Som standard er de konfigurert på en slik måte at parallelle søk utføres ved hjelp av IPv4- og IPv6-protokollene. Du kan avbryte denne oppførselen ved å legge til alternativet single-request в resolv.conf.

Merk: glibc kan konfigureres til å sende disse forespørslene sekvensielt, og musl – nei, så alpinbrukere bør ta det til etterretning.

Eksperimenterer med ndotter

La oss eksperimentere litt mer med ndots og la oss se hvordan denne parameteren oppfører seg. Ideen er enkel: ndots bestemmer om DNS-klienten vil behandle domenet som absolutt eller relativt. For eksempel, i tilfelle av en enkel google DNS-klient, hvordan vet den om dette domenet er absolutt? Hvis du setter ndots lik 1, vil klienten si: "Å, inn google det er ikke et eneste poeng; Jeg antar at jeg skal gå gjennom hele søkelisten.» Men hvis du spør google.com, vil listen over suffikser bli fullstendig ignorert fordi det forespurte navnet oppfyller terskelen ndots (det er minst ett poeng).

La oss sørge for dette:

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

[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

Siden i mrkaran det er ikke et eneste punkt, søket ble utført på tvers av hele listen over suffikser.

Merk: i praksis maksimal verdi ndots begrenset til 15; som standard i Kubernetes er det 5.

Søknad i produksjon

Hvis en applikasjon foretar mange eksterne nettverksanrop, kan DNS bli en flaskehals ved aktiv trafikk, siden navneløsning gjør mange unødvendige spørringer (før systemet kommer til den rette). Programmer legger vanligvis ikke til en rotsone til domenenavn, men dette høres ut som et hack. Altså i stedet for å spørre api.twitter.com, kan du "hardkode" den api.twitter.com. (med en prikk) i applikasjonen, som vil be DNS-klienter om å utføre autoritative oppslag direkte på det absolutte domenet.

I tillegg, fra og med Kubernetes versjon 1.14, utvidelser dnsConfig и dnsPolicy fikk stabil status. Derfor, når du distribuerer en pod, kan du redusere verdien ndots, for eksempel opptil 3 (og til og med opptil 1!). På grunn av dette må hver melding i en node inkludere hele domenet. Dette er en av de klassiske avveiningene når du skal velge mellom ytelse og portabilitet. Det virker for meg som om du bare bør bekymre deg for dette hvis ultralav ventetid er avgjørende for applikasjonen din, siden DNS-resultatene også bufres internt.

referanser

Jeg lærte først om denne funksjonen på K8s-treff, holdt 25. januar. Det ble en diskusjon om dette problemet bl.a.

Her er noen linker for videre utforskning:

• forklaring, hvorfor ndots=5 i Kubernetes;
• Flotte greier hvordan endring av ndots påvirker applikasjonsytelsen;
• Avvik mellom musl og glibc resolvere.

Merk: Jeg valgte å ikke bruke dig i denne artikkelen. dig legger automatisk til en prikk (rotsoneidentifikator), noe som gjør domenet "fullt kvalifisert" (FQDN), no ved først å kjøre den gjennom søkelisten. Skrev om dette i en av de tidligere publikasjonene. Imidlertid er det ganske overraskende at det generelt må spesifiseres et eget flagg for standardoppførselen.

Lykke til med DNSing! Ser deg senere!

PS fra oversetter

Les også på bloggen vår:

• «Calico for nettverksbygging i Kubernetes: introduksjon og litt erfaring";
• «CoreDNS - DNS-server for cloud native verden og Service Discovery for Kubernetes";
• "En illustrert guide til nettverk i Kubernetes": del 1 og 2 (nettverksmodell, overleggsnettverk), del 3 (tjenester og trafikkbehandling).

Kilde: www.habr.com