ProHoster > Blog > administrasie > DNS-soek in Kubernetes

DNS-soek in Kubernetes

Let wel. vertaal.: DNS-probleem in Kubernetes, of meer presies, parameterinstellings ndots, is verbasend gewild, en reeds Nie eerste nie jaar. In 'n ander nota oor hierdie onderwerp praat sy skrywer, 'n DevOps-ingenieur van 'n groot makelaarsmaatskappy in Indië, op 'n baie eenvoudige en bondige manier oor wat nuttig is vir kollegas wat Kubernetes bedryf om te weet.

DNS-soek in Kubernetes

Een van die belangrikste voordele van die implementering van toepassings op Kubernetes is naatlose toepassingsontdekking. Intra-kluster interaksie word aansienlik vereenvoudig danksy die dienskonsep (Diens), wat 'n virtuele IP is wat 'n stel pod-IP-adresse ondersteun. Byvoorbeeld, as die diens vanilla die diens wil kontak chocolate, kan dit direk toegang tot die virtuele IP vir chocolate. Die vraag ontstaan: aan wie sal in hierdie geval die DNS-versoek oplos chocolate En hoe?

DNS naam resolusie is opgestel op 'n Kubernetes cluster gebruik Kern-DNS. Kubelet registreer 'n pod met CoreDNS as 'n naambediener in lêers /etc/resolv.conf alle peule. As jy na die inhoud kyk /etc/resolv.conf enige peul, sal dit so lyk:

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

Hierdie konfigurasie word deur DNS-kliënte gebruik om versoeke na die DNS-bediener aan te stuur. In lêer resolv.conf bevat die volgende inligting:

  • naambediener: bediener waarna DNS-versoeke gestuur sal word. In ons geval is dit die adres van die CoreDNS-diens;
  • Soek: Definieer die soekpad vir 'n spesifieke domein. Dit is interessant dat google.com of mrkaran.dev is nie FQDN (volledig gekwalifiseerde domeinname). Volgens die standaardkonvensie wat die meeste DNS-resolvers volg, word slegs dié wat eindig met 'n punt ".", wat die wortelsone verteenwoordig, as ten volle gekwalifiseerde (FDQN) domeine beskou. Sommige oplossers kan self 'n punt byvoeg. Dus, mrkaran.dev. is die volledig gekwalifiseerde domeinnaam (FQDN), en mrkaran.dev - Geen;
  • punte: Die interessantste parameter (hierdie artikel handel daaroor). ndots spesifiseer die drempel aantal kolletjies in 'n versoeknaam voordat dit as 'n "volledig gekwalifiseerde" domeinnaam beskou word. Ons sal later meer hieroor praat wanneer ons die DNS-opsoekvolgorde ontleed.

DNS-soek in Kubernetes

Kom ons kyk wat gebeur as ons vra mrkaran.dev in 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

Vir hierdie eksperiment het ek die CoreDNS-logvlak ingestel op all (wat dit nogal verbose maak). Kom ons kyk na die peul se logs 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

Pff. Twee dinge trek jou aandag hier:

  • Die versoek gaan deur alle stadiums van die soektog totdat die antwoord die kode bevat NOERROR (DNS-kliënte verstaan ​​dit en stoor dit as gevolg daarvan). NXDOMAIN beteken dat geen rekord vir die gegewe domeinnaam gevind is nie. Omdat die mrkaran.dev is nie 'n FQDN-naam nie (volgens ndots=5), resolver kyk na die soekpad en bepaal die volgorde van versoeke;
  • opname А и АААА parallel aankom. Die feit is dat eenmalige versoeke in /etc/resolv.conf By verstek is hulle op so 'n manier gekonfigureer dat parallelle soektogte uitgevoer word deur die IPv4- en IPv6-protokolle te gebruik. Jy kan hierdie gedrag kanselleer deur die opsie by te voeg single-request в resolv.conf.

Let wel: glibc kan gekonfigureer word om hierdie versoeke opeenvolgend te stuur, en musl - nee, so Alpine-gebruikers moet kennis neem.

Eksperimenteer met puntjies

Kom ons eksperimenteer 'n bietjie meer met ndots en kom ons kyk hoe hierdie parameter optree. Die idee is eenvoudig: ndots bepaal of die DNS-kliënt die domein as absoluut of relatief sal behandel. Byvoorbeeld, in die geval van 'n eenvoudige Google DNS-kliënt, hoe weet dit of hierdie domein absoluut is? As jy stel ndots gelyk aan 1, sal die kliënt sê: "O, in google daar is nie 'n enkele punt nie; Ek dink ek sal deur die hele soeklys gaan.” As jy egter vra google.com, sal die lys van agtervoegsels heeltemal geïgnoreer word omdat die gevraagde naam aan die drempel voldoen ndots (daar is ten minste een punt).

Kom ons maak seker hiervan:

$ 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 logs:

[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

Sedert in mrkaran daar is nie 'n enkele punt nie, die soektog is oor die hele lys van agtervoegsels uitgevoer.

Let wel: in die praktyk die maksimum waarde ndots beperk tot 15; by verstek in Kubernetes is dit 5.

Toepassing in produksie

As 'n toepassing baie eksterne netwerkoproepe maak, kan DNS 'n bottelnek word in die geval van aktiewe verkeer, aangesien naamresolusie baie onnodige navrae maak (voordat die stelsel by die regte een kom). Toepassings voeg gewoonlik nie 'n wortelsone by domeinname nie, maar dit klink soos 'n hack. Dit wil sê, in plaas daarvan om te vra api.twitter.com, kan jy dit 'hardkodeer' api.twitter.com. (met 'n punt) in die toepassing, wat DNS-kliënte sal aanspoor om gesaghebbende soektogte direk op die absolute domein uit te voer.

Daarbenewens, begin met Kubernetes weergawe 1.14, uitbreidings dnsConfig и dnsPolicy stabiele status ontvang het. Dus, wanneer u 'n peul ontplooi, kan u die waarde verminder ndots, sê, tot 3 (en selfs tot 1!). As gevolg hiervan sal elke boodskap binne 'n nodus die volle domein moet insluit. Dit is een van die klassieke afwegings wanneer jy moet kies tussen werkverrigting en oordraagbaarheid. Dit lyk vir my dat jy jou net hieroor moet bekommer as ultra-lae latensie noodsaaklik is vir jou toepassing, aangesien die DNS-resultate ook intern gekas word.

verwysings

Ek het eers oor hierdie kenmerk geleer op K8s-byeenkoms, gehou op 25 Januarie. Daar was onder meer 'n bespreking oor hierdie probleem.

Hier is 'n paar skakels vir verdere verkenning:

Let wel: Ek het gekies om nie te gebruik nie dig in hierdie artikel. dig voeg outomaties 'n punt by (wortelsone-identifiseerder), wat die domein "ten volle gekwalifiseer" (FQDN) maak, geen deur dit eers deur die soeklys te laat loop. Het hieroor geskryf in een van die vorige publikasies. Dit is egter nogal verbasend dat daar oor die algemeen 'n aparte vlag vir die standaardgedrag gespesifiseer moet word.

Gelukkige DNSing! Sien jou later!

PS van vertaler

Lees ook op ons blog:

Bron: will.com

Voeg 'n opmerking