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

Kohë më parë, ne lançuam Kubernetes 1.9 në AWS duke përdorur Kops. Dje, gjatë një shpërndarjeje të qetë të trafikut të ri në një nga klasteret tona më të mëdha Kubernetes, fillova të vë re gabime të çuditshme në zgjidhjen e emrit DNS, të regjistruara nga aplikacioni ynë.

Në GitHub është diskutuar për një kohë të gjatë këtu, prandaj vendosa të merrem me këtë. Në fund, kuptova se në rastin tonë, kjo shkaktohej nga një ngarkesë e madhe në kube-dns dhe dnsmasq. E veçanta dhe e re për mua ishte vetë arsyeja e rritjes së konsiderueshme të trafikut të kërkesave DNS. Ky është subjekti i postës time.

Zgjidhja DNS brenda kontejnerit — ashtu si në çdo sistem Linux — përcaktohet nga skedari konfiguruese /etc/resolv.conf. Në mënyrë default, Kubernetes dnsPolicy kjo ClusterFirst, që do të thotë se çdo kërkesë DNS do të redirigjohet në dnsmasq, e cila ekzekutohet në podin kube-dns brenda klasterit, e cila përfaqëson kërkesën në aplikacionin kube-dns, nëse emri përfundon me sufixin e klasterit, ose përndryshe në serverin DNS të nivelit më të lartë.

Skeda /etc/resolv.conf brenda secilit kontejner 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ëreni, këtu ka tre direktiva:

Serveri i emrave — është IP e shërbimit kube-dns
Janë të specifikuar 4 domenë kërkimi lokalë : përcakton rrugën e kërkimit për një domain të caktuar. Është interesante që
Ka një mundësi ndots:5

Një pjesë interesante e kësaj konfigurationsh është se si domenët kërkimi lokalë dhe parametrat ndots:5 ndajnë njëri-tjetrin. Për të kuptuar këtë, duhet të kuptojmë se si funksionon zgjidhja DNS për emrat e paplotë.

Çfarë është emri i plotë?

Emri i plotë është ai emër për të cilin nuk do të kryhet kërkimi lokal, dhe emri do të merret si absolut gjatë zgjidhjes së emrave. Në përputhje me marrëveshjen, software-i DNS e konsideron emrin të plotë nëse përfundon me pikë (.), dhe jo të plotë përndryshe. Kështu që google.com. është plotësisht i përcaktuar, ndërsa google.com nuk është.

Si përpunohen emrat e paplotë?

Kur aplikacioni lidhet me një host të distancuar, të specifikuar në emër, zgjidhja e emrave DNS zakonisht kryhet përmes një thirrjeje sistemike, për shembull, getaddrinfo(). E këndshme është se nëse emri është i paplotë (nuk përfundon me .), është interesante nëse thirrja sistematike do të përpiqet gjithmonë të zgjidhë emrin si absolut, apo do të kalojë fillimisht nëpër domenët e kërkimit lokal. Kjo varet nga opsioni ndots.

Nga manuali mbi ndodhet informacioni i mëposhtëm::

ndots:n

përcakton pragun e numrit të pikave që duhet të jenë në emër para se të kryhet një kërkesë absolute fillestare. Vlera e parazgjedhur për n është 1, që do të thotë se nëse emri ka ndonjë pikë, emri do të provojë fillimisht si emri absolut, përpara se t'i shtohen ndonjë element liste kërkimi.

Kjo do të thotë se nëse ndots caktohet vlera 5 dhe emri përmban më pak se 5 pika, thirrja në sistem do të përpiqet ta zgjidhë atë radhazi, fillimisht duke kaluar nëpër të gjithë domainet e kërkimit lokal, dhe, nëse dështon, 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ë krijuar (ose, më saktësisht, për çdo emër të lejuar) do të jepen 5 kërkesa DNS, përpara se emri të zgjidhet saktësisht, sepse fillimisht do të kalojë nëpër 4 domainet e kërkimit lokal, 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ë 3 modulët tanë kube-dns para dhe pas kalimit të disa emrave të hosteve të vendosur në aplikacionin tonë në emra të plotë.

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

Zgjidhja #1 - përdorni emra të plotë

Nëse keni pak emra statikë të jashtëm (dmth. të përcaktuar në konfigurimin e aplikacionit), për të cilët krijoni një numër të madh lidhjesh, ndoshta zgjidhja më e thjeshtë është të kaloni në emra të plotë, thjesht duke i shtuar. në fund.

Kjo nuk është një zgjidhje përfundimtare, por ndihmon që situata të përmirësohet shpejt, ndonëse jo në mënyrë të pastër. Ky patch e kemi aplikuar për zgjidhjen e problemit tonë, rezultatet e të cilit u treguan në shkrepjet më sipër.

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

Në Kubernetes 1.9, në modin alfa, u shfaq funksionaliteti (beta versioni v1.10) që lejon një kontroll më të mirë mbi parametrat DNS përmes pronës së podit në dnsConfig. Ndër të tjera, ai lejon të konfiguroni vlerën 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"