ProHoster > Blog > Adminisztráció > /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:
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.
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):
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.