ProHoster > Blog > administration > /etc/resolv.conf for Kubernetes pods, ndots:5 mulighed, hvordan dette kan påvirke applikationens ydeevne negativt

/etc/resolv.conf for Kubernetes pods, ndots:5 mulighed, hvordan dette kan påvirke applikationens ydeevne negativt

/etc/resolv.conf for Kubernetes pods, ndots:5 mulighed, hvordan dette kan påvirke applikationens ydeevne negativt

Vi lancerede for nylig Kubernetes 1.9 på AWS ved hjælp af Kops. I går, mens jeg jævnt udrullede ny trafik til de største af vores Kubernetes-klynger, begyndte jeg at bemærke usædvanlige DNS-navneopløsningsfejl, der blev logget af vores applikation.

Der er ret meget om dette på GitHub sagde, så jeg besluttede også at finde ud af det. Til sidst indså jeg, at i vores tilfælde er dette forårsaget af den øgede belastning på kube-dns и dnsmasq. Det mest interessante og nye for mig var selve årsagen til den betydelige stigning i DNS-anmodningstrafik. Mit indlæg handler om dette, og hvad man skal gøre ved det.

DNS-opløsning inde i containeren - som i ethvert Linux-system - bestemmes af konfigurationsfilen /etc/resolv.conf. Standard Kubernetes dnsPolicy dette ClusterFirst, hvilket betyder, at enhver DNS-anmodning vil blive videresendt til dnsmasq, løber i en pod kube-dns inde i klyngen, som igen vil videresende anmodningen til ansøgningen kube-dns, hvis navnet slutter med et klyngesuffiks, eller på anden måde til en højere niveau DNS-server.

fil /etc/resolv.conf inde i hver beholder ser standarden sådan ud:

nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local 
eu-west-1.compute.internal
options ndots:5

Som du kan se, er der tre direktiver:

  1. Navneserveren er tjenestens IP-adresse kube-dns
  2. 4 lokale søgedomæner angivet search
  3. Der er en mulighed ndots:5

Den interessante del af denne konfiguration er, hvordan de lokale søgedomæner og indstillinger ndots:5 tage sig sammen. For at forstå dette skal du forstå, hvordan DNS-opløsning for ukvalificerede navne fungerer.

Hvad er et fulde navn?

Et fuldt kvalificeret navn er et navn, for hvilket der ikke vil blive udført lokalt opslag, og navnet vil blive betragtet som absolut under navneopløsning. Efter konvention anser DNS-software et navn for at være fuldt kvalificeret, hvis det ender med en prik (.), og ellers ikke fuldt kvalificeret. Det er google.com. fuldt defineret og google.com - Nej.

Hvordan håndteres et ukvalificeret navn?

Når en applikation opretter forbindelse til den fjernvært, der er angivet i navnet, udføres DNS-navneopløsning typisk ved hjælp af et systemkald, f.eks. getaddrinfo(). Men hvis navnet er ukvalificeret (ender ikke med .), mon ikke systemkaldet vil forsøge at løse navnet som et absolut navn først, eller gå gennem de lokale søgedomæner først? Det afhænger af muligheden ndots.

Fra manualen resolv.conf:

ndots:n

устанавливает порог для количества точек, которые должны появиться в имени, прежде чем будет сделан начальный абсолютный запрос. Значение по умолчанию для n равно 1, что означает, что если в имени есть какие-либо точки, имя будет сначала опробовано как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.

Det betyder, at hvis for ndots givet en værdi på 5, og navnet indeholder mindre end 5 punkter, vil systemkaldet forsøge at løse det sekventielt, først gennemse alle lokale søgedomæner, og hvis det ikke lykkes, vil det til sidst løse det som et absolut navn.

Hvorfor det? ndots:5 kan det påvirke applikationens ydeevne negativt?

Som du kan forestille dig, hvis din applikation bruger meget ekstern trafik, vil den for hver oprettet TCP-forbindelse (eller mere præcist, for hvert navn, der er løst), udstede 5 DNS-forespørgsler, før navnet er korrekt løst, fordi det først vil gå igennem 4 lokalt søgedomæne, og vil i slutningen udstede en absolut anmodning om navneopløsning.

Følgende diagram viser den samlede trafik på vores 3 kube-dns-moduler før og efter vi skiftede de få værtsnavne, der er konfigureret i vores applikation, til fuldt kvalificerede.

/etc/resolv.conf for Kubernetes pods, ndots:5 mulighed, hvordan dette kan påvirke applikationens ydeevne negativt

Følgende diagram viser applikationsforsinkelsen før og efter vi skiftede flere værtsnavne konfigureret i vores applikation til fulde navne (den lodrette blå linje er implementeringen):

/etc/resolv.conf for Kubernetes pods, ndots:5 mulighed, hvordan dette kan påvirke applikationens ydeevne negativt

Løsning #1 - Brug fuldt kvalificerede navne

Hvis du har få statiske eksterne navne (dvs. defineret i applikationskonfigurationen), som du opretter et stort antal forbindelser til, er den måske enkleste løsning at skifte dem til fuldt kvalificerede ved blot at tilføje dem. i slutningen.

Dette er ikke en endelig løsning, men det hjælper til hurtigt, om end ikke rent, at forbedre situationen. Vi anvendte denne patch for at løse vores problem, hvis resultater blev vist på skærmbillederne ovenfor.

Løsning #2 - tilpasning ndots в dnsConfig

I Kubernetes 1.9 dukkede funktionalitet op i alfa-tilstand (betaversion v1.10), som giver dig mulighed for bedre at kontrollere DNS-parametre gennem pod-egenskaben i dnsConfig. Det giver dig blandt andet mulighed for at konfigurere 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: www.habr.com

Tilføj en kommentar