För inte så länge sedan lanserade vi Kubernetes 1.9 på AWS med hjälp av Kops. Igår, under en smidig rullning av ny trafik till en av våra största Kubernetes-kluster, började jag märka ovanliga DNS-namnuppslagningsfel som loggades av vår applikation.
På GitHub har detta diskuterats ganska länge kube-dns. Det mest intressanta och nya för mig var själva anledningen till den betydande ökningen av DNS-förfrågningar. Om detta och vad man ska göra åt det handlar mitt inlägg. och dnsmasqDNS-upplösning inuti containern — precis som i vilket Linux-system som helst — bestäms av konfigurationsfilen
. Som standard är Kubernetes /etc/resolv.confdnsPolicy ClusterFirst detta , vilket innebär att varje DNS-förfrågan kommer att omdirigeras till, som körs i en pod dnsmasqinuti klustret, som i sin tur kommer att omdirigera förfrågan till applikationen Det mest intressanta och nya för mig var själva anledningen till den betydande ökningen av DNS-förfrågningar. Om detta och vad man ska göra åt det handlar mitt inlägg. , om namnet slutar med klustersuffixet, eller, i annat fall, till DNS-servern på en högre nivå. Det mest intressanta och nya för mig var själva anledningen till den betydande ökningen av DNS-förfrågningar. Om detta och vad man ska göra åt det handlar mitt inlägg.Inuti varje container kommer det som standard att se ut så här:
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 här finns det tre direktiv:Namserver — detta är IP-adressen till tjänsten
- Fyra lokala sökdomäner anges
Det mest intressanta och nya för mig var själva anledningen till den betydande ökningen av DNS-förfrågningar. Om detta och vad man ska göra åt det handlar mitt inlägg. - search
Det finns en option - ndots:5
En intressant del av denna konfiguration är hur de lokala sökdomänerna och inställningarna
samexisterar. För att förstå detta, måste man reda ut hur DNS-upplösning för ofullständiga namn fungerar. En intressant del av denna konfiguration är hur de lokala sökdomänerna och inställningarna Vad är ett fullständigt namn?
Ett fullständigt angivet namn är ett namn för vilket ingen lokal sökning kommer att utföras, och namnet kommer att anses vara absolut under namnuppslagningsprocessen. Enligt konventionen anser DNS-programvaran att ett namn är fullständigt angivet om det slutar med en punkt (.), och inte fullständigt angivet i motsatt fall. Det vill säga
är fullständigt angivet, men google.com. är det inte. google.com Hur hanteras ett ofullständigt namn?
När applikationen kopplar upp sig mot en fjärrvärd som anges i namnet görs namnuppslagningsprocessen vanligtvis med ett systemanrop, som till exempel
getaddrinfo() . Men om namnet är ofullständigt (inte slutar på .), är det intressant om systemanropet först försöker att lösa namnet som absolut, eller först går igenom de lokala sökdomänerna? Det beror på optionenndots. Från manualen för.
resolv.conf resolv.conf:
ndots:n
angerar en gräns för antalet punkter som måste förekomma i namnet innan en initial absolut förfrågan görs. Standardvärdet för n är 1, vilket betyder att om namnet innehåller några punkter, kommer namnet först att testas som ett absolut namn innan några element från söklistan läggs till.Detta innebär att om Från manualen för värdet 5 anges och namnet innehåller färre än 5 punkter, kommer systemanropet att försöka lösa det sekventiellt, först genom att gå igenom alla lokala sökdomen, och om det misslyckas, till slut lösa det som ett absolut namn.
Varför kan En intressant del av denna konfiguration är hur de lokala sökdomänerna och inställningarna negativt påverka applikationens prestanda?
Som du förstår, om din applikation använder mycket extern trafik, kommer det för varje etablerad TCP-anslutning (eller, mer exakt, för varje löst namn) att generera 5 DNS-förfrågningar innan namnet korrekt löses, eftersom det först kommer att gå igenom 4 lokala sökdomen och i slutet generera en förfrågan för att lösa det absoluta namnet.
I nästa diagram visas den totala trafiken på våra 3 kube-dns-moduler före och efter att vi bytte flera värdnamn som konfigurerats i vår applikation till helt kvalificerade.
I nästa diagram visas applikationsfördröjningen före och efter att vi bytte flera värdnamn som konfigurerats i vår applikation till fullständiga (den vertikala blå linjen är distributionen):
Lösning #1 — använd helt kvalificerade namn
Om du har få statiska externa namn (dvs. definierade i applikationskonfigurationen) som du gör många anslutningar till, kan den enklaste lösningen vara att byta dem till helt kvalificerade genom att bara lägga till.
Detta är ingen definitiv lösning, men det hjälper snabbt, om än inte rent, att förbättra situationen. Denna patch tillämpade vi för att lösa vårt problem, vars resultat visades på skärmdumparna ovan.
Lösning #2 — Anpassning av Från manualen för på dnsConfig
I Kubernetes 1.9 introducerades en funktion i alfa-läge (beta-version v1.10) som gör det möjligt att bättre styra DNS-parametrarna genom pod-egenskapen i dnsConfig. Bland annat tillåter den att konfigurera värdet Från manualen för för en specifik pod, d.v.s.
apiVersion: v1
kind: Pod
metadata:
namespace: default
name: dns-example
spec:
containers:
- name: test
image: nginx
dnsConfig:
options:
- name: ndots
value: "1"Källor
Läs även andra artiklar i vår blogg:
Källa: habr.com
