ProHoster > BLOG > administrare > /etc/resolv.conf pentru podurile Kubernetes, opțiunea ndots:5, modul în care aceasta poate afecta negativ performanța aplicației

/etc/resolv.conf pentru podurile Kubernetes, opțiunea ndots:5, modul în care aceasta poate afecta negativ performanța aplicației

/etc/resolv.conf pentru podurile Kubernetes, opțiunea ndots:5, modul în care aceasta poate afecta negativ performanța aplicației

Am lansat recent Kubernetes 1.9 pe AWS folosind Kops. Ieri, în timp ce lansam fără probleme trafic nou către cel mai mare dintre clusterele noastre Kubernetes, am început să observ erori neobișnuite de rezoluție a numelor DNS înregistrate de aplicația noastră.

Există destul de multe despre asta pe GitHub a declarat, așa că am decis să-mi dau seama și eu. În cele din urmă, mi-am dat seama că în cazul nostru acest lucru este cauzat de sarcina crescută kube-dns и dnsmasq. Cel mai interesant și nou lucru pentru mine a fost chiar motivul creșterii semnificative a traficului de solicitări DNS. Postarea mea este despre asta și despre ce să fac.

Rezoluția DNS din interiorul containerului - ca în orice sistem Linux - este determinată de fișierul de configurare /etc/resolv.conf. Kubernetes implicit dnsPolicy acest ClusterFirst, ceea ce înseamnă că orice solicitare DNS va fi redirecționată către dnsmasq, alergând într-o păstă kube-dns în interiorul clusterului, care la rândul său va transmite cererea către aplicație kube-dns, dacă numele se termină cu un sufix de cluster sau, în caz contrar, la un server DNS de nivel superior.

fișier /etc/resolv.conf în interiorul fiecărui container, implicit va arăta astfel:

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

După cum puteți vedea, există trei directive:

  1. Serverul de nume este IP-ul serviciului kube-dns
  2. 4 domenii de căutare locale specificate search
  3. Există o opțiune ndots:5

Partea interesantă a acestei configurații este modul în care domeniile și setările de căutare locală ndots:5 se intelege impreuna. Pentru a înțelege acest lucru, trebuie să înțelegeți cum funcționează rezoluția DNS pentru nume necalificate.

Ce este un nume complet?

Un nume complet calificat este un nume pentru care nu se va efectua nicio căutare locală, iar numele va fi considerat absolut în timpul rezolvării numelui. Prin convenție, software-ul DNS consideră că un nume este complet calificat dacă se termină cu un punct (.) și nu este complet calificat în caz contrar. Acesta este google.com. pe deplin definite şi google.com - Nu.

Cum este tratat un nume necalificat?

Când o aplicație se conectează la gazda de la distanță specificată în nume, rezoluția numelui DNS se face de obicei folosind un apel de sistem, de ex. getaddrinfo(). Dar dacă numele este necalificat (nu se termină cu .), mă întreb dacă apelul de sistem va încerca să rezolve mai întâi numele ca nume absolut sau să treacă mai întâi prin domeniile de căutare locale? Depinde de optiune ndots.

Din manual resolv.conf:

ndots:n

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

Aceasta înseamnă că dacă pentru ndots dat fiind o valoare de 5 și numele conține mai puțin de 5 puncte, apelul de sistem va încerca să o rezolve secvenţial, parcurgând mai întâi toate domeniile de căutare locale și, dacă nu reușește, rezolvându-l în cele din urmă ca nume absolut.

De ce da ndots:5 ar putea avea un impact negativ asupra performanței aplicației?

După cum vă puteți imagina, dacă aplicația dvs. utilizează mult trafic extern, pentru fiecare conexiune TCP stabilită (sau mai precis, pentru fiecare nume rezolvat), va emite 5 interogări DNS înainte ca numele să fie rezolvat corect, deoarece va trece mai întâi prin 4 domeniul de căutare local, iar la sfârșit va emite o cerere de rezoluție absolută a numelui.

Următorul diagramă arată traficul total pe cele 3 module kube-dns ale noastre înainte și după ce am schimbat câteva nume de gazdă configurate în aplicația noastră la cele complet calificate.

/etc/resolv.conf pentru podurile Kubernetes, opțiunea ndots:5, modul în care aceasta poate afecta negativ performanța aplicației

Următoarea diagramă arată latența aplicației înainte și după ce am schimbat mai multe nume de gazdă configurate în aplicația noastră la nume complete (linia albastră verticală este implementarea):

/etc/resolv.conf pentru podurile Kubernetes, opțiunea ndots:5, modul în care aceasta poate afecta negativ performanța aplicației

Soluția #1 - Folosiți nume complet calificate

Dacă aveți puține nume externe statice (adică definite în configurația aplicației) la care creați un număr mare de conexiuni, poate cea mai simplă soluție este să le comutați la cele complet calificate prin simpla adăugare a acestora. la sfârșitul.

Aceasta nu este o soluție finală, dar ajută la îmbunătățirea rapidă, deși nu în mod curat, a situației. Am aplicat acest patch pentru a ne rezolva problema, ale cărei rezultate au fost afișate în capturile de ecran de mai sus.

Soluția #2 - personalizare ndots в dnsConfig

În Kubernetes 1.9, funcționalitatea a apărut în modul alfa (versiunea beta v1.10), care vă permite să controlați mai bine parametrii DNS prin proprietatea pod din dnsConfig. Printre altele, vă permite să configurați valoarea ndots pentru un anumit pod, de ex.

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

surse

Citiți și alte articole de pe blogul nostru:

Sursa: www.habr.com

Adauga un comentariu