🥇/etc/resolv.conf voor Kubernetes pods, ndots:5 optie, hoe dit de applicatieprestaties negatief kan beïnvloeden

We hebben onlangs Kubernetes 1.9 op AWS gelanceerd met behulp van Kops. Gisteren, toen ik soepel nieuw verkeer naar de grootste van onze Kubernetes-clusters uitrolde, begon ik ongebruikelijke fouten in de DNS-naamomzetting op te merken die door onze applicatie waren geregistreerd.

Er staat hier heel veel over op GitHub zei, dus besloot ik het ook uit te zoeken. Uiteindelijk realiseerde ik me dat dit in ons geval wordt veroorzaakt door de verhoogde belasting kube-dns и dnsmasq. Het meest interessante en nieuwe voor mij was juist de reden voor de aanzienlijke toename van het DNS-verzoekverkeer. Mijn bericht gaat hierover en wat u eraan kunt doen.

DNS-resolutie binnen de container wordt – zoals bij elk Linux-systeem – bepaald door het configuratiebestand /etc/resolv.conf. Standaard Kubernetes dnsPolicy het ClusterFirst, wat betekent dat elk DNS-verzoek wordt doorgestuurd naar dnsmasq, rennend in een peul kube-dns binnen het cluster, dat op zijn beurt het verzoek doorstuurt naar de applicatie kube-dns, als de naam eindigt met een clusterachtervoegsel, of anders naar een DNS-server op een hoger niveau.

file /etc/resolv.conf in elke container ziet de standaard er als volgt uit:

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

Zoals u kunt zien, zijn er drie richtlijnen:

De naamserver is het IP-adres van de service kube-dns
4 lokale zoekdomeinen gespecificeerd search
Er is een optie ndots:5

Het interessante deel van deze configuratie is hoe de lokale zoekdomeinen en instellingen zijn ndots:5 met elkaar op kunnen schieten. Om dit te begrijpen, moet u begrijpen hoe DNS-resolutie voor niet-gekwalificeerde namen werkt.

Wat is een volledige naam?

Een volledig gekwalificeerde naam is een naam waarvoor geen lokale zoekopdracht wordt uitgevoerd en de naam wordt tijdens de naamomzetting als absoluut beschouwd. Volgens afspraak beschouwt DNS-software een naam als volledig gekwalificeerd als deze eindigt met een punt (.), en anders niet volledig gekwalificeerd. Dat is google.com. volledig gedefinieerd en google.com - niet.

Hoe wordt omgegaan met een niet-gekwalificeerde naam?

Wanneer een toepassing verbinding maakt met de externe host die in de naam is opgegeven, wordt de DNS-naamomzetting doorgaans uitgevoerd met behulp van een systeemaanroep, b.v. getaddrinfo(). Maar als de naam niet-gekwalificeerd is (eindigt niet op .), vraag ik me af of de systeemaanroep eerst zal proberen de naam als een absolute naam op te lossen, of eerst door de lokale zoekdomeinen zal gaan? Het hangt af van de optie ndots.

Uit de handleiding resolv.conf:

ndots:n

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

Dit betekent dat als voor ndots gegeven een waarde van 5 en de naam bevat minder dan 5 punten, zal de systeemaanroep proberen deze opeenvolgend op te lossen, waarbij eerst alle lokale zoekdomeinen worden doorkruist en, indien dit niet lukt, uiteindelijk wordt opgelost als een absolute naam.

Waarom `ndots:5` Kan dit een negatieve invloed hebben op de prestaties van applicaties?

Zoals u zich kunt voorstellen, zal uw applicatie, als deze veel extern verkeer gebruikt, voor elke tot stand gebrachte TCP-verbinding (of beter gezegd, voor elke opgeloste naam) vijf DNS-query's uitvoeren voordat de naam correct wordt omgezet, omdat deze eerst door de 5 lokaal zoekdomein, en zal aan het einde een verzoek om absolute naamomzetting indienen.

Het volgende diagram toont het totale verkeer op onze 3 kube-dns-modules voor en nadat we de weinige hostnamen die in onze applicatie zijn geconfigureerd, hebben omgezet naar volledig gekwalificeerde hostnamen.

Het volgende diagram toont de latentie van de applicatie voor en nadat we verschillende hostnamen die in onze applicatie zijn geconfigureerd, hebben omgezet naar volledige namen (de verticale blauwe lijn is de implementatie):

Oplossing #1 - Gebruik volledig gekwalificeerde namen

Als u weinig statische externe namen heeft (d.w.z. gedefinieerd in de applicatieconfiguratie) waaraan u een groot aantal verbindingen maakt, is de eenvoudigste oplossing misschien om ze om te zetten naar volledig gekwalificeerde namen door ze eenvoudigweg toe te voegen. aan het einde.

Dit is geen definitieve oplossing, maar het helpt om de situatie snel, zij het niet netjes, te verbeteren. We hebben deze patch toegepast om ons probleem op te lossen, waarvan de resultaten in de bovenstaande schermafbeeldingen worden weergegeven.

Oplossing #2 - maatwerk `ndots` в `dnsConfig`

In Kubernetes 1.9 verscheen de functionaliteit in alfamodus (bètaversie v1.10), waarmee u DNS-parameters beter kunt beheren via de pod-eigenschap in dnsConfig. Hiermee kunt u onder andere de waarde configureren ndots voor een specifieke pod, d.w.z.

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsConfig:
    options:
      - name: ndots
        value: "1"

bronnen

Lees ook andere artikelen op onze blog:

Bron: www.habr.com

/etc/resolv.conf voor Kubernetes pods, ndots:5 optie, hoe dit de applicatieprestaties negatief kan beïnvloeden