ProHoster > Blogi > antaminen > DNS-haku Kubernetesissa

DNS-haku Kubernetesissa

Huomautus. käännös: DNS-ongelma Kubernetesissa tai tarkemmin sanottuna parametriasetuksissa ndots, on yllättävän suosittu, ja jo Ei ensimmäinen vuosi. Toisessa tätä aihetta koskevassa muistiinpanossa sen kirjoittaja, DevOps-insinööri suuresta intialaisesta välitysyrityksestä, puhuu hyvin yksinkertaisella ja ytimekkäällä tavalla siitä, mitä on hyödyllistä Kubernetesia käyttäville kollegoille.

DNS-haku Kubernetesissa

Yksi Kubernetes-sovellusten käyttöönoton tärkeimmistä eduista on saumaton sovellusten etsintä. Klusterin sisäinen vuorovaikutus yksinkertaistuu huomattavasti palvelukonseptin ansiosta (Palvelu), joka on virtuaalinen IP-osoite, joka tukee joukkoa pod-IP-osoitteita. Esimerkiksi jos palvelu vanilla haluaa ottaa yhteyttä palveluun chocolate, se voi käyttää suoraan virtuaalista IP-osoitetta chocolate. Herää kysymys: kuka tässä tapauksessa ratkaisee DNS-pyynnön chocolate Ja miten?

DNS-nimen resoluutio on määritetty Kubernetes-klusteriin käyttämällä CoreDNS. Kubelet rekisteröi podin CoreDNS:llä tiedostojen nimipalvelimeksi /etc/resolv.conf kaikki palot. Jos katsot sisältöä /etc/resolv.conf mikä tahansa pod, se näyttää suunnilleen tältä:

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

DNS-asiakkaat käyttävät tätä kokoonpanoa pyyntöjen välittämiseen DNS-palvelimelle. Tiedostossa resolv.conf sisältää seuraavat tiedot:

  • nimipalvelin: palvelin, johon DNS-pyynnöt lähetetään. Meidän tapauksessamme tämä on CoreDNS-palvelun osoite;
  • haku: Määrittää tietyn verkkotunnuksen hakupolun. Se on mielenkiintoista google.com tai mrkaran.dev eivät ole FQDN (täysin hyväksytyt verkkotunnukset). Useimpien DNS-selvittäjien noudattaman vakiokäytännön mukaan vain ne, jotka päättyvät pisteeseen ".", joka edustaa juurivyöhykettä, katsotaan täysin kelvollisiksi (FDQN) verkkotunnuksiksi. Jotkut ratkaisejat voivat lisätä pisteen itse. Täten, mrkaran.dev. on täysin hyväksytty verkkotunnus (FQDN) ja mrkaran.dev - Ei;
  • ndots: Mielenkiintoisin parametri (tämä artikkeli käsittelee sitä). ndots määrittää pyynnön nimessä olevien pisteiden kynnysmäärän, ennen kuin sitä pidetään "täysin kelvollisena" verkkotunnuksena. Puhumme tästä lisää myöhemmin, kun analysoimme DNS-hakusekvenssiä.

DNS-haku Kubernetesissa

Katsotaan mitä tapahtuu, kun kysymme mrkaran.dev kotelossa:

$ 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

Tätä kokeilua varten asetin CoreDNS-kirjaustason arvoon all (mikä tekee siitä melko monisanaista). Katsotaanpa podin lokeja 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

Huh huh. Kaksi asiaa kiinnittää huomiosi tässä:

  • Pyyntö käy läpi kaikki haun vaiheet, kunnes vastaus sisältää koodin NOERROR (DNS-asiakkaat ymmärtävät sen ja tallentavat sen tuloksena). NXDOMAIN tarkoittaa, että annetulle verkkotunnukselle ei löytynyt tietuetta. Koska mrkaran.dev ei ole FQDN-nimi (mukaan ndots=5), ratkaiseja tarkastelee hakupolkua ja määrittää pyyntöjen järjestyksen;
  • äänitys А и АААА saapuvat rinnakkain. Tosiasia on, että kertaluonteiset pyynnöt tulevat sisään /etc/resolv.conf Oletusarvoisesti ne on määritetty siten, että rinnakkaiset haut suoritetaan käyttämällä IPv4- ja IPv6-protokollia. Voit peruuttaa tämän toiminnan lisäämällä vaihtoehdon single-request в resolv.conf.

Huom: glibc voidaan määrittää lähettämään nämä pyynnöt peräkkäin ja musl - ei, joten Alpine-käyttäjien tulee huomioida.

Kokeilu ndotsilla

Kokeillaan vielä vähän ndots ja katsotaan kuinka tämä parametri toimii. Idea on yksinkertainen: ndots määrittää, käsitteleekö DNS-asiakas toimialuetta absoluuttisena vai suhteellisena. Esimerkiksi, jos kyseessä on yksinkertainen Google DNS -asiakas, mistä se tietää, onko tämä verkkotunnus absoluuttinen? Jos asetat ndots yhtä suuri kuin 1, asiakas sanoo: "Voi, sisään google ei ole yhtä pistettä; Taidan käydä läpi koko hakulistan." Jos kuitenkin kysyt google.com, jälkiliitteiden luettelo ohitetaan kokonaan, koska pyydetty nimi täyttää kynnyksen ndots (on ainakin yksi kohta).

Varmistetaan tämä:

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

[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

Vuodesta lähtien mrkaran ei ole yhtä pistettä, haku tehtiin koko suffiksiluettelosta.

Huomaa: käytännössä maksimiarvo ndots rajoitettu 15; oletuksena Kubernetesissa se on 5.

Sovellus tuotannossa

Jos sovellus soittaa paljon ulkopuolisia verkkopuheluita, DNS voi muodostua pullonkaulaksi aktiivisen liikenteen tapauksessa, koska nimenselvitys tekee monia tarpeettomia kyselyitä (ennen kuin järjestelmä ehtii oikeaan). Sovellukset eivät yleensä lisää juurivyöhykettä verkkotunnusten nimiin, mutta tämä kuulostaa hakkeroilta. Eli kysymisen sijaan api.twitter.com, voit "koodata" sen api.twitter.com. (pisteellä) sovelluksessa, joka kehottaa DNS-asiakkaita suorittamaan arvovaltaisia ​​hakuja suoraan absoluuttisesta toimialueesta.

Lisäksi alkaen Kubernetes-versiosta 1.14, laajennuksia dnsConfig и dnsPolicy sai vakaan tilan. Näin ollen voit pienentää arvoa podia ottaessasi käyttöön ndots, sanotaan jopa 3 (ja jopa 1!). Tämän vuoksi jokaisen solmun sisällä olevan viestin on sisällettävä koko toimialue. Tämä on yksi klassisista kompromisseista, kun sinun on valittava suorituskyvyn ja siirrettävyyden välillä. Minusta tuntuu, että sinun pitäisi olla huolissaan tästä vain, jos erittäin alhainen latenssi on sovelluksellesi elintärkeää, koska DNS-tulokset tallennetaan myös sisäisesti välimuistiin.

viittaukset

Opin tästä ominaisuudesta ensimmäisen kerran K8s-tapaaminen, pidettiin tammikuun 25. Tästä ongelmasta käytiin keskustelua mm.

Tässä muutamia linkkejä lisäselvityksiä varten:

  • selitys, miksi ndots=5 Kubernetesissa;
  • Erinomainen materiaali kuinka ndots:n muuttaminen vaikuttaa sovelluksen suorituskykyyn;
  • Erot musl- ja glibc-selvittäjien välillä.

Huomautus: Päätin olla käyttämättä dig tässä artikkelissa. dig lisää automaattisesti pisteen (juurialueen tunnisteen), jolloin verkkotunnuksesta tulee "täysin hyväksytty" (FQDN), ei suorittamalla se ensin hakuluettelon läpi. Kirjoitti tästä vuonna yksi aiemmista julkaisuista. On kuitenkin varsin yllättävää, että tavalliselle käyttäytymiselle on yleensä määritettävä erillinen lippu.

Hyvää DNS:ää! Nähdään myöhemmin!

PS kääntäjältä

Lue myös blogistamme:

Lähde: will.com

Lisää kommentti