DNS-serĉo en Kubernetes

Notu. transl.: DNS-problemo en Kubernetes, aŭ pli precize, parametraj agordoj ndots, estas surprize populara, kaj jam Ne unue год. En alia noto pri ĉi tiu temo, ĝia aŭtoro, DevOps-inĝeniero de granda kurtaĝa kompanio en Barato, parolas tre simpla kaj koncize pri tio, kio utilas al kolegoj funkciigantaj Kubernetes scii.

Unu el la ĉefaj avantaĝoj de deplojado de aplikoj sur Kubernetes estas senjunta malkovro de aplikaĵoj. Inter-grupo interago estas tre simpligita danke al la servokoncepto (servo), kiu estas virtuala IP kiu subtenas aron de pod IP-adresoj. Ekzemple, se la servo vanilla deziras kontakti la servon chocolate, ĝi povas rekte aliri la virtualan IP por chocolate. La demando ŝprucas: al kiu ĉi-kaze solvos la DNS-peton chocolate Kaj kiel?

DNS-noma rezolucio estas agordita sur Kubernetes-grupo uzante CoreDNS. Kubelet registras pod kun CoreDNS kiel nomservilo en dosieroj /etc/resolv.conf ĉiuj balgoj. Se vi rigardas la enhavon /etc/resolv.conf ajna pod, ĝi aspektos kiel ĉi tio:

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

Ĉi tiu agordo estas uzata de DNS-klientoj por plusendi petojn al la DNS-servilo. En dosiero resolv.conf enhavas la jenajn informojn:

• nomservilo: servilo al kiu DNS-petoj estos senditaj. En nia kazo, ĉi tiu estas la adreso de la CoreDNS-servo;
• serĉo: Difinas la serĉvojon por specifa domajno. Estas interese tio google.com aŭ mrkaran.dev ne estas FQDN (plene kvalifikitaj domajnaj nomoj). Laŭ la norma konvencio kiun la plej multaj DNS-solviloj sekvas, nur tiuj kiuj finiĝas per punkto ".", reprezentante la radikan zonon, estas konsideritaj plene kvalifikitaj (FDQN) domajnoj. Iuj solvantoj povas mem aldoni punkton. Tiel, mrkaran.dev. estas la plene kvalifikita domajna nomo (FQDN), kaj mrkaran.dev - Ne;
• ndotoj: La plej interesa parametro (ĉi tiu artikolo temas pri ĝi). ndots precizigas la sojlan nombron da punktoj en peta nomo antaŭ ol ĝi estas konsiderita "plene kvalifikita" domajna nomo. Ni parolos pli pri tio poste kiam ni analizos la serĉsekvencon de DNS.

Ni vidu, kio okazas kiam ni demandas mrkaran.dev en pod:

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001

Por ĉi tiu eksperimento, mi fiksis la CoreDNS-progresnivelon al all (kiu faras ĝin sufiĉe vorta). Ni rigardu la protokolojn de la balgo coredns:

[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744s

Huf. Du aferoj kaptas vian atenton ĉi tie:

• La peto trairas ĉiujn stadiojn de la serĉo ĝis la respondo enhavas la kodon NOERROR (DNS-klientoj komprenas ĝin kaj konservas ĝin kiel rezulto). NXDOMAIN signifas ke neniu registro estis trovita por la donita domajna nomo. Ĉar la mrkaran.dev ne estas FQDN-nomo (laŭ ndots=5), solvanto rigardas la serĉvojon kaj determinas la ordon de petoj;
• Afiŝoj А и АААА alvenu paralele. La fakto estas, ke unufojaj petoj en /etc/resolv.conf Defaŭlte, ili estas agorditaj tiel, ke paralelaj serĉoj estas faritaj per la protokoloj IPv4 kaj IPv6. Vi povas nuligi ĉi tiun konduton aldonante la opcion single-request в resolv.conf.

Notu: glibc povas esti agordita por sendi ĉi tiujn petojn sinsekve, kaj musl - ne, do Alpaj uzantoj notu.

Eksperimentante kun ndots

Ni eksperimentu iom pli kun ndots kaj ni vidu kiel kondutas ĉi tiu parametro. La ideo estas simpla: ndots determinas ĉu la DNS-kliento traktos la domajnon kiel absolutan aŭ relativan. Ekzemple, en la kazo de simpla google DNS-kliento, kiel ĝi scias ĉu ĉi tiu domajno estas absoluta? Se vi fiksas ndots egala al 1, la kliento diros: "Ho, en google ne estas unu punkto; Mi supozas, ke mi ekzamenos la tutan serĉliston." Tamen, se vi demandas google.com, la listo de sufiksoj estos tute ignorita ĉar la petita nomo renkontas la sojlon ndots (estas almenaŭ unu punkto).

Ni certigu ĉi tion:

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53

** server can't find mrkaran: NXDOMAIN

Protokoloj de CoreDNS:

[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s

Ekde en mrkaran ne estas unu punkto, la serĉo estis farita tra la tuta listo de sufiksoj.

Noto: en la praktiko la maksimuma valoro ndots limigita al 15; defaŭlte en Kubernetes ĝi estas 5.

Apliko en produktado

Se aplikaĵo faras multajn eksterajn retajn vokojn, DNS povas fariĝi proplemkolo en la kazo de aktiva trafiko, ĉar nomsolvado faras multajn nenecesajn demandojn (antaŭ ol la sistemo venas al la ĝusta). Aplikoj kutime ne aldonas radikan zonon al domajnaj nomoj, sed ĉi tio sonas kiel hako. Tio estas, anstataŭ demandi api.twitter.com, vi povas hardkodigi api.twitter.com. (kun punkto) en la aplikaĵo, kiu instigos DNS-klientojn fari aŭtoritatajn serĉojn rekte sur la absoluta domajno.

Aldone, komencante kun Kubernetes versio 1.14, etendoj dnsConfig и dnsPolicy ricevis stabilan statuson. Tiel, dum deplojado de pod, vi povas redukti la valoron ndots, ekzemple, ĝis 3 (kaj eĉ ĝis 1!). Pro tio, ĉiu mesaĝo ene de nodo devos inkluzivi la plenan domajnon. Ĉi tio estas unu el la klasikaj kompromisoj kiam vi devas elekti inter rendimento kaj porteblo. Ŝajnas al mi, ke vi devas zorgi pri tio nur se ultra-malalta latenco estas esenca por via aplikaĵo, ĉar la DNS-rezultoj ankaŭ estas kaŝitaj interne.

referencoj

Mi unue lernis pri ĉi tiu funkcio sur K8s-renkontiĝo, okazigita la 25-an de januaro. Tie oni diskutis interalie pri ĉi tiu problemo.

Jen kelkaj ligiloj por plia esplorado:

• Klarigo, kial ndots=5 en Kubernetes;
• Grandaj aferoj kiel ŝanĝi ndots influas aplikan rendimenton;
• Diferencoj inter musl kaj glibc solvantoj.

Notu: Mi elektis ne uzi dig en ĉi tiu artikolo. dig aŭtomate aldonas punkton (radikzonidentigilo), igante la domajnon "plene kvalifikita" (FQDN), ne unue kurante ĝin tra la serĉlisto. Pri tio skribis en unu el la antaŭaj eldonaĵoj. Tamen, estas sufiĉe surprize, ke, ĝenerale, aparta flago devas esti specifita por la norma konduto.

Feliĉa DNSing! Ĝis revido!

PS de tradukisto

Legu ankaŭ en nia blogo:

• «Calico por interkonektado en Kubernetes: enkonduko kaj iom da sperto»;
• «CoreDNS - DNS-servilo por la nuba indiĝena mondo kaj Service Discovery por Kubernetes»;
• "Ilustrita Gvidilo pri Retoj en Kubernetes": partoj 1 kaj 2 (retmodelo, tegmentaj retoj), parto 3 (servoj kaj trafika prilaborado).

fonto: www.habr.com