ProHoster > Blog > Bestjoer > /etc/resolv.conf foar Kubernetes pods, ndots:5 opsje, hoe't dit in negatyf ynfloed kin op de prestaasjes fan 'e applikaasje

/etc/resolv.conf foar Kubernetes pods, ndots:5 opsje, hoe't dit in negatyf ynfloed kin op de prestaasjes fan 'e applikaasje

/etc/resolv.conf foar Kubernetes pods, ndots:5 opsje, hoe't dit in negatyf ynfloed kin op de prestaasjes fan 'e applikaasje

Wy hawwe koartlyn Kubernetes 1.9 op AWS lansearre mei Kops. Juster, wylst ik nij ferkear soepel útrol nei de grutste fan ús Kubernetes-klusters, begon ik ûngewoane flaters foar resolúsje fan DNS-namme te fernimmen oanmeld troch ús applikaasje.

D'r is hjir in soad oer op GitHub spriek, dus ik besleat it ek út te finen. Op it lêst realisearre ik dat yn ús gefal dit wurdt feroarsake troch de ferhege load op kube-dns и dnsmasq. It meast nijsgjirrige en nije ding foar my wie de heul reden foar de signifikante tanimming fan DNS-fersykferkear. Myn post giet oer dit en wat te dwaan deroer.

DNS-resolúsje yn 'e kontener - lykas yn elk Linux-systeem - wurdt bepaald troch it konfiguraasjetriem /etc/resolv.conf. Standert Kubernetes dnsPolicy it ClusterFirst, wat betsjut dat elk DNS-fersyk wurdt trochstjoerd nei dnsmasq, rint yn in pod kube-dns binnen it kluster, dat op syn beurt it fersyk trochstjoert nei de oanfraach kube-dns, as de namme einiget mei in kluster efterheaksel, of, oars, nei in heger nivo DNS-tsjinner.

file /etc/resolv.conf binnen elke kontener sil de standert der sa útsjen:

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

Sa't jo sjen kinne, binne d'r trije rjochtlinen:

  1. De nammetsjinner is it IP fan 'e tsjinst kube-dns
  2. 4 lokale sykdomeinen oantsjutte search
  3. Der is in opsje ndots:5

It nijsgjirrige diel fan dizze konfiguraasje is hoe't de lokale sykdomeinen en ynstellings ndots:5 tegearre meiinoar komme. Om dit te begripen, moatte jo begripe hoe't DNS-resolúsje foar net kwalifisearre nammen wurket.

Wat is in folsleine namme?

In folslein kwalifisearre namme is in namme dêr't gjin lokale opsykjen foar útfierd wurdt en de namme wurdt beskôge as absolút by nammebeslút. By konvinsje beskôget DNS-software in namme as folslein kwalifisearre as it einiget mei in stip (.), En oars net folslein kwalifisearre. Dat is google.com. folslein definiearre en google.com - Nee.

Hoe wurdt in ûnkwalifisearre namme behannele?

As in applikaasje ferbynt mei de host op ôfstân spesifisearre yn 'e namme, wurdt DNS namme resolúsje typysk dien mei help fan in systeem oprop, f.eks. getaddrinfo(). Mar as de namme net kwalifisearre is (einiget net mei .), Ik freegje my ôf oft de systeemoprop sil besykje de namme as in absolute namme earst op te lossen, of earst troch de lokale sykdomeinen gean? It hinget ôf fan 'e opsje ndots.

Ut de hânlieding resolv.conf:

ndots:n

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

Dit betsjut dat as foar ndots jûn in wearde fan 5 en de namme befettet minder as 5 stippen, sil de systeemoprop besykje it opfolgjend op te lossen, earst troch alle lokale sykdomeinen troch te gean, en, as it net slagget, it úteinlik oplost as in absolute namme.

Wêrom dan ndots:5 koe it negatyf beynfloedzje applikaasje prestaasjes?

Lykas jo jo kinne foarstelle, as jo applikaasje in protte ekstern ferkear brûkt, sil it foar elke TCP-ferbining fêststeld (of krekter, foar elke namme oplost), 5 DNS-fragen útjaan foardat de namme goed is oplost, om't it earst troch giet 4 lokaal sykdomein, en sil oan 'e ein in absolute fersyk foar nammeresolúsje útjaan.

It folgjende diagram toant it totale ferkear op ús 3 kube-dns-modules foar en nei't wy de pear hostnammen konfigureare yn ús applikaasje hawwe oerskeakele nei folslein kwalifisearre.

/etc/resolv.conf foar Kubernetes pods, ndots:5 opsje, hoe't dit in negatyf ynfloed kin op de prestaasjes fan 'e applikaasje

It folgjende diagram toant de wachttiid fan 'e applikaasje foar en nei't wy ferskate hostnammen konfigureare yn ús applikaasje hawwe oerskeakele nei folsleine nammen (de fertikale blauwe line is de ynset):

/etc/resolv.conf foar Kubernetes pods, ndots:5 opsje, hoe't dit in negatyf ynfloed kin op de prestaasjes fan 'e applikaasje

Oplossing #1 - Brûk folslein kwalifisearre nammen

As jo ​​​​in pear statyske eksterne nammen hawwe (dus definieare yn 'e applikaasjekonfiguraasje) wêrmei jo in grut oantal ferbiningen meitsje, is miskien de ienfâldichste oplossing om se te wikseljen nei folslein kwalifisearre troch se gewoan te heakjen. oan de ein.

Dit is gjin definitive oplossing, mar it helpt om de situaasje fluch, hoewol net skjin, te ferbetterjen. Wy hawwe dizze patch tapast om ús probleem op te lossen, wêrfan de resultaten waarden werjûn yn 'e skermôfbyldings hjirboppe.

Oplossing #2 - maatwurk ndots в dnsConfig

Yn Kubernetes 1.9 ferskynde funksjonaliteit yn alpha-modus (beta-ferzje v1.10), wêrtroch jo DNS-parameters better kinne kontrolearje fia de pod-eigenskip yn dnsConfig. Under oare dingen kinne jo de wearde konfigurearje ndots foar in spesifike pod, d.w.s.

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

Boarnen

Lês ek oare artikels op ús blog:

Boarne: www.habr.com

Add a comment