/etc/resolv.conf za Kubernetes pods, opcija ndots:5, kako to može negativno utjecati na performanse aplikacije

/etc/resolv.conf za Kubernetes pods, opcija ndots:5, kako to može negativno utjecati na performanse aplikacije

Nedavno smo pokrenuli Kubernetes 1.9 na AWS-u koristeći Kops. Jučer, dok sam glatko uvodio novi promet u najveći od naših Kubernetes klastera, počeo sam primjećivati ​​neobične pogreške u razrješenju DNS imena koje bilježi naša aplikacija.

Ima dosta o tome na GitHubu rekla, pa sam i ja odlučio to shvatiti. Na kraju sam shvatio da je u našem slučaju to uzrokovano povećanim opterećenjem kube-dns и dnsmasq. Najzanimljivije i novo za mene je bio sam razlog značajnog povećanja prometa DNS zahtjeva. Moj post govori o tome i što učiniti u vezi s tim.

DNS razlučivost unutar spremnika - kao u bilo kojem Linux sustavu - određena je konfiguracijskom datotekom /etc/resolv.conf. Zadani Kubernetes dnsPolicy ovo ClusterFirst, što znači da će svaki DNS zahtjev biti proslijeđen na dnsmasq, trčanje u mahuni kube-dns unutar klastera, koji će zauzvrat proslijediti zahtjev aplikaciji kube-dns, ako naziv završava sufiksom klastera ili, u suprotnom, na DNS poslužitelj više razine.

datoteka /etc/resolv.conf unutar svakog spremnika zadana će izgledati ovako:

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

Kao što vidite, postoje tri smjernice:

  1. Poslužitelj naziva je IP adresa usluge kube-dns
  2. Navedene su 4 lokalne domene pretraživanja search
  3. Postoji opcija ndots:5

Zanimljiv dio ove konfiguracije su domene i postavke lokalnog pretraživanja ndots:5 slagati se zajedno. Da biste ovo razumjeli, morate razumjeti kako funkcionira DNS razrješenje za nekvalificirana imena.

Što je puno ime i prezime?

Potpuno kvalificirano ime je ime za koje se neće izvršiti lokalno traženje i ime će se smatrati apsolutnim tijekom rješavanja naziva. Prema konvenciji, DNS softver smatra da je naziv potpuno kvalificiran ako završava s točkom (.), au suprotnom nije potpuno kvalificiran. To je google.com. potpuno definiran i google.com - Ne.

Kako se postupa s nekvalificiranim imenom?

Kada se aplikacija povezuje s udaljenim hostom navedenim u nazivu, razrješenje DNS imena obično se vrši pomoću sistemskog poziva, npr. getaddrinfo(). Ali ako je ime nekvalificirano (ne završava s .), pitam se hoće li sistemski poziv prvo pokušati riješiti ime kao apsolutno ime ili će prvo proći kroz lokalne domene pretraživanja? Ovisi o opciji ndots.

Iz priručnika resolv.conf:

ndots:n

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

To znači da ako za ndots s obzirom na vrijednost 5 i naziv sadrži manje od 5 točaka, sistemski poziv će ga pokušati riješiti sekvencijalno, prvo prolazeći kroz sve domene lokalnog pretraživanja i, ako ne uspije, na kraju će ga razriješiti kao apsolutno ime.

Zašto ndots:5 može li to negativno utjecati na rad aplikacije?

Kao što možete zamisliti, ako vaša aplikacija koristi mnogo vanjskog prometa, za svaku uspostavljenu TCP vezu (ili točnije, za svako riješeno ime), izdat će 5 DNS upita prije nego što se ime ispravno riješi, jer će prvo proći kroz 4 lokalne domene za pretraživanje, a na kraju će izdati apsolutni zahtjev za razrješenje imena.

Sljedeći grafikon prikazuje ukupni promet na naša 3 kube-dns modula prije i nakon što smo prebacili nekoliko imena računala konfiguriranih u našoj aplikaciji na potpuno kvalificirana.

/etc/resolv.conf za Kubernetes pods, opcija ndots:5, kako to može negativno utjecati na performanse aplikacije

Sljedeći dijagram prikazuje kašnjenje aplikacije prije i nakon što smo nekoliko naziva hostova konfiguriranih u našoj aplikaciji prebacili na puna imena (okomita plava linija je implementacija):

/etc/resolv.conf za Kubernetes pods, opcija ndots:5, kako to može negativno utjecati na performanse aplikacije

Rješenje #1 - Koristite potpuno kvalificirana imena

Ako imate nekoliko statičkih vanjskih naziva (tj. definiranih u konfiguraciji aplikacije) na koje stvarate velik broj veza, možda je najjednostavnije rješenje prebaciti ih na potpuno kvalificirana jednostavnim dodavanjem. na kraju.

Ovo nije konačno rješenje, ali pomaže da se situacija brzo, iako ne čisto, poboljša. Primijenili smo ovu zakrpu kako bismo riješili naš problem, a rezultati su prikazani na gornjim snimkama zaslona.

Rješenje #2 - prilagodba ndots в dnsConfig

U Kubernetesu 1.9, funkcionalnost se pojavila u alfa modu (beta verzija v1.10), koji vam omogućuje bolju kontrolu DNS parametara putem svojstva pod u dnsConfig. Između ostalog, omogućuje vam konfiguriranje vrijednosti ndots za određenu mahunu, tj.

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

izvori

Također pročitajte ostale članke na našem blogu:

Izvor: www.habr.com

Dodajte komentar