For ikke så længe siden lancerede vi Kubernetes 1.9 på AWS ved hjælp af Kops. I går, under en blød udrulning af ny trafik til den største af vores Kubernetes-klynger, begyndte jeg at bemærke usædvanlige DNS-navn opløsning fejl, der blev logget af vores applikation.
Der har været en del snak om dette på GitHub i et stykke tid . Det mest interessante og nye for mig var selve årsagen til den markante stigning i trafik af DNS-forespørgsler. Dette, samt hvad man skal gøre ved det, er emnet for mit indlæg. kube-dns og dnsmasqOpløsning af DNS inden i containere – ligesom i ethvert Linux-system – bestemmes af konfigurationsfilen
. Som standard er Kubernetes /etc/resolv.confClusterFirst dnsPolicy dette , hvilket betyder, at enhver DNS-forespørgsel vil blive omdirigeret til, som kører i en pod dnsmasqinden for klyngen, som igen vil omdirigere forespørgslen til applikationen kube-dns , hvis navnet slutter med klynge-suffikset, eller ellers til en højere niveau DNS-server. kube-dnsInden i hver container vil det som standard se sådan ud:
Fil /etc/resolv.conf nameserver 100.64.0.10 search namespace.svc.cluster.local svc.cluster.local cluster.local eu-west-1.compute.internal options ndots:5
Som man kan se, her er der tre direktiver:Navneserver – dette er IP’en for servicen
- Der er angivet 4 lokale søgedomæner
kube-dns - Der er en mulighed
search - ndots:5
En interessant del af denne konfiguration er, hvordan lokale søgedomæner og indstillinger
lever sammen. For at forstå dette, skal man først forstå, hvordan DNS-oplevelsen fungerer for ufuldstændige navne. En interessant del af denne konfiguration er, hvordan lokale søgedomæner og indstillinger Hvad er et fuldt navn?
Et helt kvalificeret navn er et navn, for hvilket der ikke vil blive udført lokal søgning, og navnet vil blive betragtet som absolut under opløsning af navne. Efter aftale anser DNS-software et navn som fuldt kvalificeret, hvis det slutter med et punktum (.), og ikke fuldt kvalificeret ellers. Det vil sige
er fuldt kvalificeret, men google.com. er ikke. google.com Hvordan håndteres et ufuldstændigt navn?
Når applikationen forbinder til en ekstern vært, der er angivet i navnet, udføres navneopløsning normalt via et systemkald, såsom
getaddrinfo() . Men hvis navnet er ufuldstændigt (ikke slutter på .), er det interessant, om systemkaldet først vil forsøge at opløse navnet som absolut, eller om det først vil gå gennem de lokale søgedomæner? Det afhænger af indstillingenFra manualen om ndots.
Из мануала по resolv.conf:
ndots:n
sætter grænsen for antallet af punkter, der skal være i navnet, før der foretages en initial absolut anmodning. Standardværdien for n er 1, hvilket betyder, at hvis der er nogen punkter i navnet, vil navnet først blive prøvet som et absolut navn, før der tilføjes nogen elementer fra søgelisten.Det betyder, at hvis der ndots er angivet en værdi på 5, og navnet indeholder mindre end 5 punkter, vil systemopkaldet forsøge at opløse det sekventielt, først ved at gå gennem alle lokale søgedomæner, og i tilfælde af fejlslag vil det til sidst opløse det som et absolut navn.
Hvorfor kan En interessant del af denne konfiguration er, hvordan lokale søgedomæner og indstillinger det negativt påvirke applikationens ydeevne?
Som du forstår, hvis din applikation bruger meget ekstern trafik, vil den for hver etableret TCP-forbindelse (eller mere præcist for hvert opløst navn) generere 5 DNS-anmodninger, før navnet bliver korrekt opløst, fordi den først vil gå gennem 4 lokale søgedomæner og til sidst generere en anmodning om opløsning af det absolutte navn.
I det følgende diagram vises den samlede trafik på vores 3 kube-dns moduler før og efter, at vi skiftede flere vært-navne, der var konfigureret i vores applikation, til fuldt kvalificerede.
I det følgende diagram vises forsinkelsen i applikationen før og efter, at vi skiftede flere vært-navne, der var konfigureret i vores applikation, til fuldt kvalificerede (den lodrette blå linje er implementeringen):
Løsning #1 — brug af fuldt kvalificerede navne
Hvis du har få statiske eksterne navne (dvs. defineret i applikationskonfigurationen), som du opretter et stort antal forbindelser til, kan den nemmeste løsning være at skifte dem til fuldt kvalificerede ved blot at tilføje. i slutningen.
Dette er ikke en endelig løsning, men det hjælper hurtigt, omend ikke perfekt, med at forbedre situationen. Denne patch anvendte vi til at løse vores problem, hvis resultater blev vist på skærmbillederne ovenfor.
Løsning #2 — tilpasning ndots i dnsConfig
I Kubernetes 1.9 blev der i alpha-tilstand indført funktionalitet (beta-version v1.10), der giver bedre kontrol over DNS-parametre gennem pod-egenskaber i dnsConfig. Blandt andet giver det mulighed for at justere værdien ndots for en bestemt pod, dvs.
apiVersion: v1
kind: Pod
metadata:
namespace: default
name: dns-example
spec:
containers:
- name: test
image: nginx
dnsConfig:
options:
- name: ndots
value: "1"Kilder
Læs også andre artikler på vores blog:
Kilde: habr.com
