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

Kohët e fundit kemi lançuar Kubernetes 1.9 në AWS duke përdorur Kops. Dje, ndërsa shpërndaja pa probleme trafikun e ri në grupimet tona më të mëdha Kubernetes, fillova të vëreja gabime të pazakonta në rezolucionin e emrit DNS të regjistruara nga aplikacioni ynë.

Ka shumë për këtë në GitHub tha, kështu që vendosa ta kuptoj edhe unë. Në fund, kuptova se në rastin tonë kjo është shkaktuar nga rritja e ngarkesës në kube-dns и dnsmasq. Gjëja më interesante dhe e re për mua ishte vetë arsyeja e rritjes së konsiderueshme të trafikut të kërkesave DNS. Postimi im ka të bëjë me këtë dhe çfarë të bëjmë në lidhje me të.

Rezolucioni i DNS brenda kontejnerit - si në çdo sistem Linux - përcaktohet nga skedari i konfigurimit /etc/resolv.conf. Kubernetes i parazgjedhur dnsPolicy это ClusterFirst, që do të thotë se çdo kërkesë DNS do të përcillet te dnsmasq, duke vrapuar në një pod kube-dns brenda grupit, i cili nga ana tjetër do t'ia përcjellë kërkesën aplikacionit kube-dns, nëse emri përfundon me një prapashtesë grupi, ose, përndryshe, në një server DNS të nivelit më të lartë.

skedar /etc/resolv.conf brenda çdo kontejneri parazgjedhja 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 ta shihni, ekzistojnë tre direktiva:

Serveri i emrave është IP e shërbimit kube-dns
4 fusha të kërkimit lokal të specifikuar search
Ekziston një opsion ndots:5

Pjesa interesante e këtij konfigurimi është se si kërkohen domenet dhe cilësimet lokale ndots:5 bashkohuni së bashku. Për ta kuptuar këtë, duhet të kuptoni se si funksionon rezolucioni DNS për emrat e pakualifikuar.

Cili është emri i plotë?

Një emër plotësisht i kualifikuar është një emër për të cilin nuk do të kryhet asnjë kërkim lokal dhe emri do të konsiderohet absolut gjatë zgjidhjes së emrit. Sipas konventës, softueri DNS e konsideron një emër të kualifikuar plotësisht nëse përfundon me një pikë (.) dhe jo plotësisht të kualifikuar ndryshe. Kjo eshte google.com. plotësisht të përcaktuara dhe google.com - jo

Si trajtohet një emër i pakualifikuar?

Kur një aplikacion lidhet me hostin në distancë të specifikuar në emër, zgjidhja e emrit DNS zakonisht bëhet duke përdorur një thirrje sistemi, p.sh. getaddrinfo(). Por nëse emri është i pakualifikuar (nuk mbaron me .), pyes veten nëse thirrja e sistemit do të përpiqet të zgjidhë emrin si një emër absolut fillimisht, apo do të kalojë së pari nëpër domenet e kërkimit lokal? Kjo varet nga opsioni ndots.

Nga manuali resolv.conf:

ndots:n

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

Kjo do të thotë se nëse për ndots Duke pasur parasysh një vlerë prej 5 dhe emri përmban më pak se 5 pika, thirrja e sistemit do të përpiqet ta zgjidhë atë në mënyrë sekuenciale, duke përshkuar fillimisht të gjitha domenet e kërkimit lokal dhe, nëse nuk ka sukses, përfundimisht duke e zgjidhur atë si një emër absolut.

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

Siç mund ta imagjinoni, nëse aplikacioni juaj përdor shumë trafik të jashtëm, për çdo lidhje TCP të krijuar (ose më saktë, për çdo emër të zgjidhur), ai do të lëshojë 5 pyetje DNS përpara se emri të zgjidhet saktë, sepse së pari do të kalojë 4 domeni i kërkimit lokal, dhe në fund do të lëshojë një kërkesë absolute për zgjidhjen e emrit.

Grafiku i mëposhtëm tregon trafikun total në 3 modulet tona kube-dns përpara dhe pasi kemi ndërruar disa emra pritës të konfiguruar në aplikacionin tonë në ato plotësisht të kualifikuara.

Diagrami i mëposhtëm tregon vonesën e aplikacionit përpara dhe pasi kemi ndërruar disa emra pritës të konfiguruar në aplikacionin tonë në emrat e plotë (vija vertikale blu është vendosja):

Zgjidhja #1 - Përdorni emra plotësisht të kualifikuar

Nëse keni pak emra të jashtëm statikë (d.m.th. të përcaktuar në konfigurimin e aplikacionit) tek të cilët krijoni një numër të madh lidhjesh, ndoshta zgjidhja më e thjeshtë është t'i kaloni në ato plotësisht të kualifikuara, thjesht duke i bashkuar. në fund.

Kjo nuk është një zgjidhje përfundimtare, por ndihmon në përmirësimin e shpejtë, megjithëse jo të pastër, të situatës. Ne aplikuam këtë patch për të zgjidhur problemin tonë, rezultatet e të cilit u shfaqën në pamjet e mësipërme.

Zgjidhja #2 - personalizimi `ndots` в `dnsConfig`

Në Kubernetes 1.9, funksionaliteti u shfaq në modalitetin alfa (versioni beta v1.10), i cili ju lejon të kontrolloni më mirë parametrat DNS përmes vetive pod në dnsConfig. Ndër të tjera, ju lejon të konfiguroni vlerën ndots për një pod specifik, d.m.th.

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

burime

Lexoni gjithashtu artikuj të tjerë në blogun tonë:

Burimi: www.habr.com

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