ProHoster > Blogi > antaminen > /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ä:
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.
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):
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.