/etc/resolv.conf Kubernetes-podille, ndots:5-vaihtoehto, miten tämä voi vaikuttaa kielteisesti sovelluksen suorituskykyyn

/etc/resolv.conf Kubernetes-podille, ndots:5-vaihtoehto, miten tämä voi vaikuttaa kielteisesti sovelluksen suorituskykyyn

Julkaisimme äskettäin Kubernetes 1.9:n AWS:llä Kopsin avulla. Eilen, kun siirsin sujuvasti uutta liikennettä suurimpaan Kubernetes-klusteriimme, aloin huomata sovelluksemme kirjaamia epätavallisia DNS-nimien ratkaisuvirheitä.

Tästä on paljon GitHubissa sanoi, joten päätin myös selvittää sen. Lopulta tajusin, että meidän tapauksessamme tämä johtuu lisääntyneestä kuormituksesta kube-dns и dnsmasq. Mielenkiintoisin ja uusi asia minulle oli juuri se syy DNS-pyyntöliikenteen merkittävään kasvuun. Viestini käsittelee tätä ja mitä tehdä asialle.

Säilön sisällä oleva DNS-resoluutio - kuten missä tahansa Linux-järjestelmässä - määräytyy asetustiedoston mukaan /etc/resolv.conf. Oletus Kubernetes dnsPolicy это ClusterFirst, mikä tarkoittaa, että kaikki DNS-pyynnöt välitetään osoitteeseen dnsmasq, juoksemassa palossa kube-dns klusterin sisällä, joka puolestaan ​​välittää pyynnön sovellukselle kube-dns, jos nimi päättyy klusteriliitteeseen, tai muussa tapauksessa korkeamman tason DNS-palvelimeen.

tiedosto /etc/resolv.conf kunkin säilön sisällä oletusarvo näyttää tältä:

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

Kuten näet, direktiiviä on kolme:

  1. Nimipalvelin on palvelun IP-osoite kube-dns
  2. 4 paikallista hakualuetta määritetty search
  3. On olemassa vaihtoehto ndots:5

Mielenkiintoinen osa tätä kokoonpanoa on, miten paikalliset hakualueet ja -asetukset ndots:5 tulla toimeen yhdessä. Ymmärtääksesi tämän, sinun on ymmärrettävä, kuinka DNS-selvitys määrittelemättömille nimille toimii.

Mikä on koko nimi?

Täysin hyväksytty nimi on nimi, jolle ei suoriteta paikallista hakua ja nimeä pidetään ehdottomana nimenselvityksen aikana. Sopimuksen mukaan DNS-ohjelmisto pitää nimeä täysin pätevänä, jos se päättyy pisteeseen (.), eikä sitä muutoin ole täysin hyväksytty. Tuo on google.com. täysin määritelty ja google.com - ei.

Miten määrittelemätöntä nimeä käsitellään?

Kun sovellus muodostaa yhteyden nimessä määritettyyn etäisäntään, DNS-nimen selvitys tehdään tyypillisesti järjestelmäkutsulla, esim. getaddrinfo(). Mutta jos nimi on määrittelemätön (ei pääty merkkiin .), mietin, yrittääkö järjestelmäkutsu ratkaista nimen ensin absoluuttiseksi nimeksi vai käykö ensin paikalliset hakualueet läpi? Se riippuu vaihtoehdosta ndots.

Käsikirjasta resolv.conf:

ndots:n

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

Tämä tarkoittaa, että jos ndots jos arvo on 5 ja nimi sisältää alle 5 pistettä, järjestelmäkutsu yrittää ratkaista sen peräkkäin, ensin läpi kaikki paikalliset hakualueet ja, jos se ei onnistu, ratkaisee sen lopulta absoluuttiseksi nimeksi.

Miksi niin ndots:5 voiko se vaikuttaa kielteisesti sovelluksen suorituskykyyn?

Kuten voit kuvitella, jos sovelluksesi käyttää paljon ulkoista liikennettä, jokaista muodostettua TCP-yhteyttä (tai tarkemmin sanottuna jokaista ratkaistua nimeä kohden) kohden se lähettää 5 DNS-kyselyä ennen kuin nimi on ratkaistu oikein, koska se käy ensin läpi 4 paikallista hakuverkkotunnusta, ja lopussa antaa ehdottoman nimenratkaisupyynnön.

Seuraava kaavio näyttää kolmen kube-dns-moduulimme kokonaisliikenteen ennen ja sen jälkeen, kun vaihdoimme muutamat sovelluksessamme määritetyt isäntänimet täysin kelvollisiksi.

/etc/resolv.conf Kubernetes-podille, ndots:5-vaihtoehto, miten tämä voi vaikuttaa kielteisesti sovelluksen suorituskykyyn

Seuraava kaavio näyttää sovelluksen viiveen ennen ja sen jälkeen, kun vaihdoimme useita sovelluksessamme määritettyjä isäntänimiä täydellisiksi nimiksi (pystysuora sininen viiva on käyttöönotto):

/etc/resolv.conf Kubernetes-podille, ndots:5-vaihtoehto, miten tämä voi vaikuttaa kielteisesti sovelluksen suorituskykyyn

Ratkaisu #1 - Käytä täysin päteviä nimiä

Jos sinulla on muutamia staattisia ulkoisia nimiä (eli määritettyjä sovelluksen kokoonpanossa), joihin luot suuren määrän yhteyksiä, ehkä yksinkertaisin ratkaisu on vaihtaa ne täysin kelvollisiksi liittämällä ne. lopussa.

Tämä ei ole lopullinen ratkaisu, mutta se auttaa parantamaan tilannetta nopeasti, joskaan ei puhtaasti. Ratkaisimme ongelmamme tämän korjaustiedoston, jonka tulokset näkyvät yllä olevissa kuvakaappauksissa.

Ratkaisu #2 - räätälöinti ndots в dnsConfig

Kubernetes 1.9:ssä toiminnallisuus ilmestyi alfa-tilaan (betaversio v1.10), jonka avulla voit hallita DNS-parametreja paremmin pod-ominaisuuden kautta dnsConfig. Sen avulla voit muun muassa määrittää arvon ndots tietylle podille, ts.

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

lähteet

Lue myös muut artikkelit blogistamme:

Lähde: will.com

Lisää kommentti