Nemrég indítottuk el a Kubernetes 1.9-et az AWS-en a Kops segítségével. Tegnap, amikor a legnagyobb Kubernetes klaszterünkre új forgalmat telepítettünk, szokatlan DNS névmegjelenítési hibákat kezdtem észlelni, amelyeket az alkalmazásunk naplózott.
A GitHub-on már régóta beszélnek róla , ezért én is elkezdtem utána járni. Végül rájöttem, hogy az esetünkben ezt a DNS kérdésekre nehezedő terhelés okozza. kube-dns és dnsmasqA legérdekesebb és legújabb számomra az volt, hogy miért nőtt meg jelentősen a DNS-kérések forgalma. Erről és arról, hogy mit tehetünk ezzel kapcsolatban, írtam a bejegyzésemet.
A DNS feloldás egy konténeren belül – mint bármely Linux rendszerben – a konfigurációs fájl határozza meg /etc/resolv.conf. Alapértelmezés szerint a Kubernetes dnsPolicy ez ClusterFirst, ami azt jelenti, hogy bármely DNS-kérés átirányításra kerül dnsmasq, amely a klaszterben futó podban található, amely viszont átirányítja a kérést az alkalmazásra kube-dns , ha a név a klaszter utótagjával végződik, különben pedig a magasabb szintű DNS szerverre. kube-dnsA konténerekben alapértelmezés szerint így fest:
Fájl /etc/resolv.conf nameserver 100.64.0.10 search namespace.svc.cluster.local svc.cluster.local cluster.local eu-west-1.compute.internal options ndots:5
Ahogy látható, itt három direktíva van:A névszerver az IP cím szolgáltatás
- 4 helyi kereső domain van megadva
kube-dns - Van egy opció
: a megadott domain keresési útvonalát határozza meg. Érdekes, hogy - ndots:5
A konfiguráció érdekes része az, ahogyan a helyi kereső domainek és a beállítások
együttműködnek. Ennek megértéséhez fontos tisztázni, hogyan működik a DNS feloldás a hiányos neveknél. A konfiguráció érdekes része az, ahogyan a helyi kereső domainek és a beállítások Mi az a teljes név?
A teljesen azonosított név az, amelyikhez nem történik helyi keresés, és a név abszolútnak számít a név feloldása során. A DNS szoftver megállapodása szerint a név teljesen azonosítottnak számít, ha pontra (.) végződik, és nem teljesen azonosítottnak egyébként. Tehát
google.com. teljesen azonosított, míg – nem az. mrkaran.dev Hogyan kezeljük a hiányos neveket?
Amikor egy alkalmazás csatlakozik egy távoli hosthoz, amelyet a név tartalmaz, a DNS név feloldást általában rendszerhívással végzik, például
getaddrinfo() . De ha a név hiányos (nem végződik a .), érdekes, hogy a rendszerhívás először abszolút névként próbálja-e feloldani a nevet, vagy először végigmegy a helyi kereső domaineken? Ez az opciótól függA kézikönyv szerint ndots.
A kézikönyvből fájl tartalmazza a következő információt::
ndots:n
beállítja a küszöbértéket a névben megjelenő pontok számára, mielőtt a kezdeti abszolút lekérdezés megtörténik. Az alapértelmezett érték n-re 1, ami azt jelenti, hogy ha a név tartalmaz bármilyen pontot, először a nevet abszolút névként próbálják ki, mielőtt bármely keresési lista elemet hozzáadnának.Ez azt jelenti, hogy ha a ndots értéke 5, és a név kevesebb mint 5 pontot tartalmaz, a rendszerhívás megpróbálja sorban feloldani, először átmegy minden helyi keresési domaineken, és ha ez nem sikerül, végül abszolút névként fogja feloldani.
Miért is A konfiguráció érdekes része az, ahogyan a helyi kereső domainek és a beállítások lehet negatívan hatni az alkalmazás teljesítményére?
Ahogy megérted, ha az alkalmazásod sok külső forgalmat használ, minden egyes TCP-kapcsolat (vagy pontosabban, minden egyes feloldott név) esetén 5 DNS-lekérdezést fog kiadni, mielőtt a nevet helyesen oldaná fel, mert először áthalad 4 helyi keresési domaineken, és végül kiad egy abszolút név feloldó lekérdezést.
A következő diagramon a teljes forgalom látható a 3 kube-dns modulunkban azután, hogy néhány hosztnév teljesen definiáltra lett váltva az alkalmazásunkban.
A következő diagramon az alkalmazás késleltetése látható azután, hogy néhány hosztnév teljesen definiáltra lett váltva az alkalmazásunkban (a függőleges kék vonal a telepítést jelzi):
Megoldás #1 — használj teljesen definiált neveket
Ha kevés statikus külső neved van (azaz, amelyek az alkalmazás konfigurációjában vannak meghatározva), amelyekhez nagyszámú kapcsolatot létesítesz, akkor talán a legegyszerűbb megoldás az, hogy azokat teljesen definiáltakra váltod, egyszerűen azzal, hogy hozzáadod a végéhez.
Ez nem végleges megoldás, de segít gyorsan, ha nem is tisztán, javítani a helyzeten. Ezt a javítást alkalmaztuk problémánk megoldására, amelynek eredményeit a fenti képernyőképeken látható.
Megoldás #2 — testreszabás ndots be. dnsConfig
A Kubernetes 1.9-ben alfa módban megjelent egy funkció (béta verzió v1.10), amely lehetővé teszi a DNS paraméterek jobb kezelését a pod tulajdonságain keresztül. dnsConfig. Többek között lehetővé teszi egy adott podhoz tartozó ndots érték beállítását, azaz.
apiVersion: v1
kind: Pod
metadata:
namespace: default
name: dns-example
spec:
containers:
- name: test
image: nginx
dnsConfig:
options:
- name: ndots
value: "1"Források
Olvasd el többi cikkünket a blogunkban:
Forrás: habr.com
