🥇/etc/resolv.conf për Kubernetes pods, opsioni ndots:5, si mund të ndikojë negativisht në performancën e aplikacionit

Së fundmi, lançuam Kubernetes 1.9 në AWS duke përdorur Kops. Dje, gjatë lançimit të qetë të trafikut të ri në njërin nga klasterët tanë më të mëdhenj të Kubernetes, fillova të vërej një sërë gabimesh të pazakonta në zgjidhjen e emrave DNS, të regjistruara nga aplikacioni ynë.

Në GitHub ka pasur shumë diskutime rreth kësaj, prandaj vendosa të hetoj. Në fund, kuptova se në rastin tonë, kjo është shkaktuar nga një ngarkesë e shtuar në kube-dns dhe dnsmasq. Ajo që më interesoi dhe ishte e re për mua ishte vetë shkaku i rritjes së konsiderueshme të trafikut të kërkesave DNS. Rreth kësaj dhe çfarë mund të bëjmë me të, është ky postim.

Zgjidhja e DNS brenda kontejnerit — ashtu si në çdo sistem Linux — përcaktohet nga skedari i konfigurimit /etc/resolv.conf. Siç është e zakonshme, Kubernetes dnsPolicy kjo ClusterFirst, që do të thotë se çdo kërkesë DNS do të drejtohet te dnsmasq, e cila ekzekutohet në pod kube-dns brenda klasterit, i cili, nga ana e tij, do ta drejtojë kërkesën te aplikacioni kube-dns, nëse emri përfshin sufixin e klasterit, ose, ndryshe, te serveri DNS i niveleve më të larta.

Skedari /etc/resolv.conf brenda çdo kontejneri në mënyrë të zakonshme do të duket kështu:

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

Si mund të vërehet, këtu ka tre direktiva:

Serveri i emrave është IP i shërbimit kube-dns
Janë specifikuar 4 domenet lokale të kërkimit kërko
Ekziston një opsion ndots:5

Një pjesë interesante e kësaj konfigurimi është se si domenet lokale të kërkimit dhe cilësimet ndots:5 bashkëjetojnë. Për ta kuptuar këtë, është e nevojshme të kuptojmë si funksionon zgjidhja DNS për emrat e papërfunduar.

Çfarë është emri i plotë?

Një emër i plotë i përcaktuar është emri për të cilin nuk do të kryhet një kërkim lokal, dhe emri do të konsiderohet si absolut gjatë zgjidhjes së emrave. Sipas marrëveshjes, softueri DNS e konsideron emrin si të plotë të përcaktuar, nëse përfundon me një pikë (.) dhe jo plotësisht të përcaktuar ndryshe. Pra, google.com. është plotësisht e përcaktuar, ndërsa google.com — jo.

Si përpunohuan emrat e papërfunduar?

Kur një aplikacion lidhet me një host të largët, i specifikuar në emër, zgjidhja e emrave DNS zakonisht realizohet përmes thirrjes së sistemit, për shembull, getaddrinfo(). Po nëse emri nuk është i plotë (nuk përfundon në .), a do të përpiqet thirrja sistemike fillimisht ta zgjidhë emrin si tërësor, apo do të kalojë fillimisht përmes domain-eve lokale të kërkimit? Kjo varet nga opsioni ndots.

Nga manuali për resolv.conf:

ndots:n

vendos kufirin për numrin e pikave që duhet të shfaqen në emër, para se të bëhet një kërkesë fillestare absolute. Vlera e paracaktuar për n është 1, që do të thotë se nëse emri ka ndonjë pikë, emri do të provoni fillimisht si emri absolut, para se t'i shtohen ndonjë element i listës së kërkimit.

Kjo do të thotë se nëse për ndots vendoset vlera 5, dhe emri përmban më pak se 5 pika, thirrja sistemike do të përpiqet ta zgjidhë atë rresht pas rreshti, fillimisht duke kaluar përmes të gjithë domain-eve lokale të kërkimit, dhe, në rast dështimi, në fund do ta zgjidhë atë si emër absolut.

Pse `ndots:5` mund të ndikojë negativisht në performancën e aplikacionit?

Si e kuptoni, nëse aplikacioni juaj përdor shumë trafik të jashtëm, për çdo lidhje TCP të vendosur (ose, më saktë, për çdo emër të lejuar) ai do të japë 5 kërkesa DNS, para se emri të zgjidhet siç duhet, sepse fillimisht do të kalojë përmes 4 domain-eve lokale të kërkimit dhe në fund do të japë një kërkesë për zgjidhjen e emrit absolut.

Në diagramin e mëposhtëm tregohet trafiku total në tre modulet tona kube-dns para dhe pas ndryshimit të disa emrave të hosteve të konfiguruar në aplikacionin tonë në emra të përcaktuar plotësisht.

Në diagramin e mëposhtëm tregohet vonesa e aplikacionit para dhe pas ndryshimit të disa emrave të hosteve të konfiguruar në aplikacionin tonë në emra të plotë (vija e kaltër vertikale është implementimi):

Zgjidhja #1 - përdorimi i emrave të plotë të përcaktuar

Nëse keni pak emra statikë të jashtëm (dmth. të përcaktuar në konfigurimin e aplikacionit), të cilave u krijoni një sasi të madhe lidhjesh, ndoshta zgjidhja më e thjeshtë është t'i kaloni ato në emra të plotë, duke shtuar thjesht 'në fund.'

Kjo nuk është një zgjidhje përfundimtare, por ndihmon për të përmirësuar shpejt, ndonëse jo në mënyrë të përsosur, situatën. Ky patch e aplikuam për të zgjidhur problemin tonë, rezultatet e së cilës u treguan në screenshot-et më sipër.

Zgjidhja #2 — personalizimi `ndots` në `dnsConfig`

Në Kubernetes 1.9, u shfaq në modin alfa një funksionalitet (versioni beta v1.10) që lejon një kontroll më të mirë të parametrave DNS përmes pronës së pods në dnsConfig. Mes të tjerash, ai lejon konfigurimin e vlerës ndots për një pod të caktuar, dmth.

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