ProHoster > Блог > Administrado > /etc/resolv.conf por Kubernetes pods, opcio ndots:5, kiel tio povas negative influi aplikaĵon

/etc/resolv.conf por Kubernetes pods, opcio ndots:5, kiel tio povas negative influi aplikaĵon

/etc/resolv.conf por Kubernetes pods, opcio ndots:5, kiel tio povas negative influi aplikaĵon

Ni lastatempe lanĉis Kubernetes 1.9 sur AWS uzante Kops. Hieraŭ, dum glate disvolvante novan trafikon al la plej granda el niaj Kubernetes-aretoj, mi komencis rimarki nekutimajn DNS-nomajn rezoluciajn erarojn registritajn de nia aplikaĵo.

Estas sufiĉe multe pri tio en GitHub parolis, do ankaŭ mi decidis eltrovi ĝin. Fine mi rimarkis, ke en nia kazo ĉi tio estas kaŭzita de la pliigita ŝarĝo kube-dns и dnsmasq. La plej interesa kaj nova afero por mi estis la kialo mem de la grava pliiĝo de DNS-peta trafiko. Mia afiŝo temas pri tio kaj kion fari pri ĝi.

DNS-rezolucio ene de la ujo - kiel en iu Linuksa sistemo - estas determinita de la agorda dosiero /etc/resolv.conf. Defaŭlta Kubernetes dnsPolicy ĝi ClusterFirst, kio signifas, ke ajna DNS-peto estos plusendita al dnsmasq, kurante en balgo kube-dns ene de la areto, kiu siavice plusendos la peton al la aplikaĵo kube-dns, se la nomo finiĝas per clustersufikso, aŭ, alie, al pli alta nivela DNS-servilo.

dosiero /etc/resolv.conf ene de ĉiu ujo la defaŭlto aspektos jene:

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

Kiel vi povas vidi, estas tri direktivoj:

  1. La nomservilo estas la IP de la servo kube-dns
  2. 4 lokaj serĉdomajnoj specifitaj search
  3. Estas opcio ndots:5

La interesa parto de ĉi tiu agordo estas kiel la lokaj serĉdomajnoj kaj agordoj ndots:5 interkonsenti. Por kompreni ĉi tion, vi devas kompreni kiel funkcias DNS-rezolucio por nekvalifikitaj nomoj.

Kio estas plena nomo?

Plene kvalifikita nomo estas nomo por kiu neniu loka serĉo estos farita kaj la nomo estos konsiderata absoluta dum nomsolvado. Laŭ konvencio, DNS-programaro konsideras nomon plene kvalifikita se ĝi finiĝas per punkto (.), kaj ne plene kvalifikita alie. Tio estas google.com. plene difinita kaj google.com - ne.

Kiel estas traktata nekvalifikita nomo?

Kiam aplikaĵo ligas al la fora gastiganto specifita en la nomo, DNS-nomrezolucio estas kutime farita uzante sistemvokon, ekz. getaddrinfo(). Sed se la nomo estas nekvalifikita (ne finiĝas per .), mi scivolas, ĉu la sistemvoko provos unue solvi la nomon kiel absolutan nomon, aŭ unue trapasos la lokajn serĉdomajnojn? Ĝi dependas de la opcio ndots.

El la manlibro resolv.conf:

ndots:n

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

Ĉi tio signifas, ke se por ndots donita valoron de 5 kaj la nomo enhavas malpli ol 5 punktojn, la sistemvoko provos solvi ĝin sinsekve, unue trairante ĉiujn lokajn serĉdomajnojn, kaj, se malsukcese, poste solvante ĝin kiel absoluta nomo.

Kial do ndots:5 ĉu ĝi povus negative influi aplikaĵon?

Kiel vi povas imagi, se via aplikaĵo uzas multe da ekstera trafiko, por ĉiu TCP-konekto establita (aŭ pli precize, por ĉiu nomo solvita), ĝi eldonos 5 DNS-demandojn antaŭ ol la nomo estas ĝuste solvita, ĉar ĝi unue trairos. 4 loka serĉdomajno, kaj ĉe la fino eldonos absolutan nomsolvopeton.

La sekva diagramo montras la totalan trafikon sur niaj 3 kube-dns-moduloj antaŭ kaj post kiam ni ŝanĝis la malmultajn gastigajn nomojn agorditajn en nia aplikaĵo al plene kvalifikitaj.

/etc/resolv.conf por Kubernetes pods, opcio ndots:5, kiel tio povas negative influi aplikaĵon

La sekva diagramo montras la latentecon de la aplikaĵo antaŭ kaj post kiam ni ŝanĝis plurajn gastigajn nomojn agorditajn en nia aplikaĵo al plenaj nomoj (la vertikala blua linio estas la deplojo):

/etc/resolv.conf por Kubernetes pods, opcio ndots:5, kiel tio povas negative influi aplikaĵon

Solvo #1 - Uzu plene kvalifikitajn nomojn

Se vi havas malmultajn senmovajn eksterajn nomojn (t.e. difinitajn en la aplika agordo) al kiuj vi kreas grandan nombron da konektoj, eble la plej simpla solvo estas ŝanĝi ilin al plene kvalifikitaj simple almetante ilin. fine.

Ĉi tio ne estas fina solvo, sed ĝi helpas rapide, kvankam ne pure, plibonigi la situacion. Ni aplikis ĉi tiun diakilon por solvi nian problemon, kies rezultoj estis montritaj en la supraj ekrankopioj.

Solvo #2 - personigo ndots в dnsConfig

En Kubernetes 1.9, funkcieco aperis en alfa-reĝimo (beta-versio v1.10), kiu ebligas al vi pli bone kontroli DNS-parametrojn per la podposedaĵo en dnsConfig. Interalie ĝi permesas al vi agordi la valoron ndots por specifa balgo, t.e.

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

Fontoj

Legu ankaŭ aliajn artikolojn en nia blogo:

fonto: www.habr.com

Aldoni komenton