/etc/resolv.conf Kubernetes podokhoz, ndots:5 opció, hogyan befolyásolhatja ez negatívan az alkalmazás teljesítményét

/etc/resolv.conf Kubernetes podokhoz, ndots:5 opció, hogyan befolyásolhatja ez negatívan az alkalmazás teljesítményét

Nemrég elindítottuk a Kubernetes 1.9-et AWS-en a Kops használatával. Tegnap, miközben zökkenőmentesen továbbítottam az új forgalmat a legnagyobb Kubernetes-fürtökhöz, szokatlan DNS-névfeloldási hibákat vettem észre, amelyeket az alkalmazásunk naplózott.

A GitHubon sok minden megtalálható erről nevezett, ezért úgy döntöttem, hogy én is kitalálom. Végül rájöttem, hogy esetünkben ezt a megnövekedett terhelés okozza kube-dns и dnsmasq. Számomra a legérdekesebb és legújabb dolog a DNS-kérés forgalom jelentős növekedésének oka volt. A bejegyzésem erről szól, és arról, hogy mit tegyek ellene.

A tárolón belüli DNS felbontást – mint minden Linux rendszerben – a konfigurációs fájl határozza meg /etc/resolv.conf. Alapértelmezett Kubernetes dnsPolicy ezt ClusterFirst, ami azt jelenti, hogy a rendszer minden DNS-kérést továbbít a címre dnsmasq, tokban fut kube-dns a fürtön belül, amely viszont továbbítja a kérést az alkalmazásnak kube-dns, ha a név fürt utótaggal végződik, vagy egyébként magasabb szintű DNS-kiszolgálóra.

fájl /etc/resolv.conf minden tárolón belül az alapértelmezett így fog kinézni:

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

Amint látja, három irányelv létezik:

  1. A névszerver a szolgáltatás IP-címe kube-dns
  2. 4 helyi keresési tartomány megadva search
  3. Van egy lehetőség ndots:5

Ennek a konfigurációnak az érdekes része, hogy a helyi keresési tartományok és beállítások hogyan ndots:5 összejönni. Ennek megértéséhez meg kell értenie, hogyan működik a nem minősített nevek DNS-feloldása.

Mi az a teljes név?

A teljesen minősített név olyan név, amelyre nem kerül sor helyi keresésre, és a név abszolútnak minősül a névfeloldás során. Megállapodás szerint a DNS-szoftver akkor tekinti a nevet teljesen minősítettnek, ha pontra (.) végződik, máskülönben nem minősítettnek. Azaz google.com. teljesen meghatározott és google.com - nem.

Hogyan kezelik a minősíthetetlen nevet?

Amikor egy alkalmazás csatlakozik a névben megadott távoli gazdagéphez, a DNS-névfeloldás általában rendszerhívással történik, pl. getaddrinfo(). De ha a név nem minősíthető (nem végződik .-vel), vajon a rendszerhívás megpróbálja-e először abszolút névként feloldani a nevet, vagy először a helyi keresési tartományokon megy keresztül? Az opciótól függ ndots.

A kézikönyvből resolv.conf:

ndots:n

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

Ez azt jelenti, hogy ha azért ndots Ha 5-ös értékkel rendelkezik, és a név kevesebb mint 5 pontot tartalmaz, a rendszerhívás megpróbálja szekvenciálisan feloldani, először bejárja az összes helyi keresési tartományt, és ha nem sikerül, végül abszolút névként fogja feloldani.

Miért? ndots:5 negatívan befolyásolhatja az alkalmazás teljesítményét?

Elképzelhető, hogy ha az alkalmazás sok külső forgalmat használ, akkor minden létrejött TCP-kapcsolatnál (pontosabban minden feloldott névnél) 5 DNS-lekérdezést fog kiadni, mielőtt a név helyesen megoldódik, mert először átmegy 4 helyi keresési tartományt, és a végén abszolút névfeloldási kérést ad ki.

A következő diagram a 3 kube-dns modulunk teljes forgalmát mutatja, mielőtt és miután az alkalmazásunkban beállított néhány gazdagépnevet teljesen minősítettre cseréltük.

/etc/resolv.conf Kubernetes podokhoz, ndots:5 opció, hogyan befolyásolhatja ez negatívan az alkalmazás teljesítményét

Az alábbi diagram az alkalmazás késleltetését mutatja, mielőtt és miután több, az alkalmazásunkban beállított gazdagépnevet teljes névre váltottunk (a függőleges kék vonal a telepítést jelenti):

/etc/resolv.conf Kubernetes podokhoz, ndots:5 opció, hogyan befolyásolhatja ez negatívan az alkalmazás teljesítményét

1. megoldás – Használjon teljesen minősített neveket

Ha kevés statikus külső név van (azaz az alkalmazás konfigurációjában van meghatározva), amelyhez nagyszámú kapcsolatot hoz létre, akkor talán a legegyszerűbb megoldás, ha egyszerűen hozzáfűzi őket teljesen minősített névre. a végén.

Ez nem végleges megoldás, de segít gyorsan, ha nem is tisztán, de javítani a helyzeten. Ezt a javítást alkalmaztuk a problémánk megoldására, amelynek eredményei a fenti képernyőképeken láthatók.

2. megoldás – testreszabás ndots в dnsConfig

A Kubernetes 1.9-ben a funkciók alfa módban jelentek meg (béta verzió v1.10), amely lehetővé teszi a DNS-paraméterek jobb vezérlését a pod tulajdonságon keresztül dnsConfig. Többek között lehetővé teszi az érték konfigurálását ndots egy adott podra, pl.

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

forrás

Olvassa el blogunk további cikkeit is:

Forrás: will.com

Hozzászólás