Bemærk. overs.: DNS-problem i Kubernetes, eller mere præcist, parameterindstillinger ndots, er overraskende populær og allerede . I en anden note om dette emne taler dens forfatter, en DevOps-ingeniør fra et stort mæglerfirma i Indien, på en meget enkel og kortfattet måde om, hvad der er nyttigt for kolleger, der driver Kubernetes, at vide.
En af de vigtigste fordele ved at implementere applikationer på Kubernetes er problemfri applikationsopdagelse. Intra-cluster interaktion er meget forenklet takket være servicekonceptet (), som er en virtuel IP, der understøtter et sæt pod-IP-adresser. For eksempel hvis tjenesten vanilla ønsker at kontakte tjenesten chocolate, kan den få direkte adgang til den virtuelle IP for chocolate. Spørgsmålet opstår: hvem i dette tilfælde vil løse DNS-anmodningen til chocolate Og hvor?
DNS-navneopløsning er konfigureret på en Kubernetes-klynge ved hjælp af . Kubelet registrerer en pod med CoreDNS som navneserver i filer /etc/resolv.conf alle bælg. Hvis man ser på indholdet /etc/resolv.conf enhver pod, vil den se 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 videresende anmodninger til DNS-serveren. I fil resolv.conf indeholder følgende oplysninger:
- navneserver: server, som DNS-anmodninger vil blive sendt til. I vores tilfælde er dette adressen på CoreDNS-tjenesten;
- søge: Definerer søgestien for et bestemt domæne. Det er interessant det
google.comellermrkaran.dever ikke FQDN (). Ifølge standardkonventionen, som de fleste DNS-resolvere følger, er det kun dem, der ender med et punktum ".", der repræsenterer rodzonen, som betragtes som fuldt kvalificerede (FDQN) domæner. Nogle resolvere kan selv tilføje et punkt. Dermed,mrkaran.dev.er det fuldt kvalificerede domænenavn (FQDN), ogmrkaran.dev- Nej; - ndotter: Den mest interessante parameter (denne artikel handler om det).
ndotsangiver tærskelantallet af prikker i et anmodningsnavn, før det betragtes som et "fuldt kvalificeret" domænenavn. Vi vil tale mere om dette senere, når vi analyserer DNS-opslagssekvensen.
Lad os se, hvad der sker, når vi spørger 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
Til dette eksperiment satte jeg CoreDNS-logningsniveauet til all (hvilket gør det ret ordrigt). Lad os se på podens logfiler 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.145091744sPyha. To ting fanger din opmærksomhed her:
- Forespørgslen gennemgår alle stadier af søgningen, indtil svaret indeholder koden
NOERROR(DNS-klienter forstår det og gemmer det som et resultat).NXDOMAINbetyder, at der ikke blev fundet nogen registrering for det givne domænenavn. Fordimrkaran.dever ikke et FQDN-navn (ifølgendots=5), resolver ser på søgestien og bestemmer rækkefølgen af anmodninger; - Indlæg
АиААААankommer parallelt. Faktum er, at engangsanmodninger ind/etc/resolv.confSom standard er de konfigureret på en sådan måde, at parallelle søgninger udføres ved hjælp af IPv4- og IPv6-protokollerne. Du kan annullere denne adfærd ved at tilføje mulighedensingle-requestвresolv.conf.
Note: glibc kan konfigureres til at sende disse anmodninger sekventielt, og musl - nej, så alpine brugere bør tage det til efterretning.
Eksperimenterer med ndotter
Lad os eksperimentere lidt mere med ndots og lad os se, hvordan denne parameter opfører sig. Ideen er enkel: ndots bestemmer, om DNS-klienten vil behandle domænet som absolut eller relativt. For eksempel, i tilfælde af en simpel google DNS-klient, hvordan ved den, om dette domæne er absolut? Hvis du indstiller ndots lig med 1, vil klienten sige: "Åh, ind google der er ikke et eneste punkt; Jeg tror, jeg vil gennemgå hele søgelisten." Men hvis du spørger google.com, vil listen over suffikser blive fuldstændig ignoreret, fordi det anmodede navn opfylder tærsklen ndots (der er mindst et punkt).
Lad os sikre os 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: NXDOMAINCoreDNS-logfiler:
[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 der er ikke et eneste punkt, søgningen blev udført på tværs af hele listen af suffikser.
Bemærk: i praksis den maksimale værdi ndots begrænset til 15; som standard i Kubernetes er det 5.
Anvendelse i produktion
Hvis en applikation foretager mange eksterne netværksopkald, kan DNS blive en flaskehals i tilfælde af aktiv trafik, da navneopløsning laver mange unødvendige forespørgsler (inden systemet kommer til den rigtige). Programmer tilføjer normalt ikke en rodzone til domænenavne, men det lyder som et hack. Altså i stedet for at spørge api.twitter.com, kan du 'hardkode' den api.twitter.com. (med en prik) i applikationen, som vil bede DNS-klienter om at udføre autoritative opslag direkte på det absolutte domæne.
Derudover, startende med Kubernetes version 1.14, udvidelser dnsConfig и dnsPolicy fik stabil status. Når du installerer en pod, kan du således reducere værdien ndotsf.eks. op til 3 (og endda op til 1!). På grund af dette skal hver meddelelse i en node inkludere hele domænet. Dette er en af de klassiske afvejninger, når du skal vælge mellem ydeevne og bærbarhed. Det forekommer mig, at du kun skal bekymre dig om dette, hvis ultra-lav latenstid er afgørende for din applikation, da DNS-resultaterne også cachelagres internt.
RЎSЃS <P "RєRё
Jeg lærte først om denne funktion på , afholdt den 25. januar. Der var en diskussion om dette problem bl.a.
Her er nogle links til yderligere udforskning:
- , hvorfor ndots=5 i Kubernetes;
- hvordan ændring af ndots påvirker applikationens ydeevne;
- mellem musl og glibc resolvere.
Bemærk: Jeg valgte ikke at bruge dig i denne artikel. dig tilføjer automatisk en prik (rodzone-id), hvilket gør domænet "fuldt kvalificeret" (FQDN), nej ved først at køre den gennem søgelisten. Skrev om dette i . Det er dog ret overraskende, at der generelt skal angives et separat flag for standardadfærden.
God DNSing! Vi ses senere!
PS fra oversætteren
Læs også på vores blog:
- «";
- «";
- "En illustreret guide til netværk i Kubernetes": , .
Kilde: www.habr.com