DNS bilaketa Kubernetes-en

Ohar. itzul.: DNS arazoa Kubernetes-en, edo, zehatzago, parametroen ezarpenak ndots, harrigarriro ezaguna da, eta dagoeneko Ez lehenik urteko. Gai honi buruzko beste ohar batean, bere egileak, Indiako bitartekaritza-enpresa handi bateko DevOps ingeniariak, oso modu sinple eta zehatzean hitz egiten du Kubernetes funtzionatzen duten lankideek jakitea erabilgarria denaz.

Kubernetesen aplikazioak zabaltzearen abantaila nagusietako bat aplikazioen aurkikuntza ezin hobea da. Kluster barruko elkarrekintza asko errazten da zerbitzu kontzeptuari esker (zerbitzua), hau da, pod IP helbide multzo bat onartzen duen IP birtuala. Adibidez, zerbitzua bada vanilla zerbitzuarekin harremanetan jarri nahi du chocolate, zuzenean sar daiteke IP birtualera chocolate. Galdera sortzen da: kasu honetan nori ebatziko dion DNS eskaera chocolate Eta nola?

DNS izenen ebazpena Kubernetes kluster batean konfiguratzen da CoreDNS. Kubelet-ek pod bat CoreDNS-ekin erregistratzen du fitxategietan izen-zerbitzari gisa /etc/resolv.conf leka guztiak. Edukia begiratuz gero /etc/resolv.conf edozein pod, itxura hau izango du:

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

Konfigurazio hau DNS bezeroek erabiltzen dute eskaerak DNS zerbitzariari birbidaltzeko. Fitxategian resolv.conf informazio hau dauka:

• izen-zerbitzaria: DNS eskaerak bidaliko zaizkion zerbitzaria. Gure kasuan, hau da CoreDNS zerbitzuaren helbidea;
• search: Domeinu zehatz baten bilaketa-bidea definitzen du. Interesgarria da hori google.com edo mrkaran.dev ez dira FQDN (guztiz kualifikatutako domeinu-izenak). DNS konpontzaile gehienek jarraitzen duten konbentzio estandarraren arabera, "." puntu batekin amaitzen direnak soilik, erro-eremua adierazten dutenak, guztiz kualifikatutako (FDQN) domeinutzat hartzen dira. Ebazle batzuek beraiek puntu bat gehi dezakete. Horrela, mrkaran.dev. domeinu-izena guztiz kualifikatua da (FQDN), eta mrkaran.dev - Ez;
• ndots: Parametrorik interesgarriena (artikulu hau horri buruzkoa da). ndots Eskaera-izen bateko puntuen atalasea zehazten du "guztiz kualifikatua" domeinu-izentzat hartu aurretik. Geroago hitz egingo dugu honi buruz gehiago DNS bilaketa-sekuentzia aztertzen dugunean.

Ea zer gertatzen den galdetzen dugunean mrkaran.dev podan:

$ 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

Esperimentu honetarako, CoreDNS erregistro-maila ezarri dut all (horrek nahiko hitz egiten du). Ikus ditzagun lekaren erregistroak 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

Uf. Bi gauzek atentzioa ematen dizute hemen:

• Eskaerak bilaketaren fase guztiak zeharkatzen ditu erantzunak kodea jaso arte NOERROR (DNS bezeroek ulertzen dute eta, ondorioz, gordetzen dute). NXDOMAIN esan nahi du ez dela erregistrorik aurkitu emandako domeinu-izenarentzat. Zeren mrkaran.dev ez da FQDN izena (arabera ndots=5), konpontzaileak bilaketa-bidea begiratzen du eta eskaeren ordena zehazten du;
• Sarrerak А и АААА paraleloan heldu. Kontua da behin-behineko eskaerak sartzen direla /etc/resolv.conf Berez, IPv4 eta IPv6 protokoloak erabiliz bilaketa paraleloak egiteko moduan konfiguratuta daude. Jokabide hau bertan behera utzi dezakezu aukera gehituz single-request в resolv.conf.

Oharra: glibc eskaera hauek sekuentzialki bidaltzeko konfigura daiteke, eta musl - ez, beraz, Alpine erabiltzaileek kontutan hartu beharko lukete.

ndotsekin esperimentatzen

Ea pixka bat gehiago esperimentatu ndots eta ikus dezagun parametro honek nola jokatzen duen. Ideia sinplea da: ndots DNS bezeroak domeinua absolutu edo erlatibo gisa tratatuko duen zehazten du. Adibidez, google DNS bezero soil baten kasuan, nola jakiten du domeinu hau absolutua den? Ezarri baduzu ndots 1 berdina, bezeroak esango du: "Oh, sartu google ez dago puntu bakar bat ere; Bilaketa-zerrenda osoa aztertuko dudala uste dut". Hala ere, galdetuz gero google.com, atzizkien zerrenda guztiz baztertuko da, eskatutako izenak atalasea betetzen duelako ndots (gutxienez puntu bat dago).

Ziurta dezagun hau:

$ 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

CoreDNS erregistroak:

[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

urtean geroztik mrkaran ez dago puntu bakar bat ere, bilaketa atzizkien zerrenda osoan egin zen.

Oharra: praktikan gehienezko balioa ndots 15era mugatua; Kubernetesen lehenespenez 5 da.

Aplikazioa ekoizpenean

Aplikazio batek kanpoko sareko dei asko egiten baditu, DNS trafiko aktiboaren kasuan botila-lepo bihur daiteke, izenen ebazpenak alferrikako kontsulta asko egiten baititu (sistema zuzenera iritsi aurretik). Aplikazioek normalean ez dute domeinu-izenei erro-eremurik gehitzen, baina hack bat dirudi. Hau da, galdetu beharrean api.twitter.com, hardcode dezakezu api.twitter.com. (puntu batekin) aplikazioan, DNS bezeroei domeinu absolutuan zuzenean bilaketa autoritarioak egiteko eskatuko diena.

Gainera, Kubernetes 1.14 bertsiotik hasita, luzapenak dnsConfig и dnsPolicy egoera egonkorra jaso zuen. Horrela, pod bat zabaltzean, balioa murriztu dezakezu ndots, esan, 3 arte (eta baita 1 ere!). Horregatik, nodo bateko mezu bakoitzak domeinu osoa sartu beharko du. Hau da errendimendua eta eramangarritasunaren artean aukeratu behar duzun merkataritza-off klasikoetako bat. Iruditzen zait horretaz bakarrik kezkatu behar zarela zure aplikaziorako latentzia oso baxua ezinbestekoa bada, DNS emaitzak ere barnean gordetzen baitira.

Erreferentziak

Ezaugarri honi buruz ikasi nuen lehenengoz K8-en topaketa, urtarrilaren 25ean. Bertan, besteak beste, arazo hau eztabaidatu zuten.

Hona hemen esteka batzuk esplorazio gehiagorako:

• azalpen, zergatik ndots=5 Kubernetes-en;
• Gauza bikainak ndots aldatzeak aplikazioen errendimenduan nola eragiten duen;
• Desadostasunak musl eta glibc ebazleen artean.

Oharra: ez erabiltzea aukeratu dut dig artikulu honetan. dig automatikoki puntu bat gehitzen du (erro-eremuaren identifikatzailea), domeinua "guztiz kualifikatua" (FQDN) bihurtuz. ez lehenik bilaketa-zerrendan exekutatuta. urtean idatzi zuen honi buruz aurreko argitalpenetako bat. Hala ere, nahiko harrigarria da, oro har, portaera estandar baterako bandera bereizi bat zehaztu behar izatea.

Zoriontsu DNSa! Gero arte!

PS itzultzailetik

Irakurri ere gure blogean:

• «Kubernetes-en sarerako Calico: aurkezpena eta esperientzia txiki bat»;
• «CoreDNS - Hodeiko jatorrizko mundurako DNS zerbitzaria eta Kubernetesentzako Service Discovery»;
• "Kubernetes-en sareak egiteko gida ilustratua": 1. eta 2. zatiak (sare-eredua, gainjarritako sareak), 3. zatia (zerbitzuak eta trafikoaren tratamendua).

Iturria: www.habr.com