DNS keresés a Kubernetesben

Jegyzet. ford.: DNS probléma a Kubernetesben, pontosabban a paraméterbeállításokban ndots, meglepően népszerű, és már Nem az első év. A témával kapcsolatos másik feljegyzésben annak szerzője, egy nagy indiai brókercég DevOps mérnöke nagyon egyszerűen és tömören beszél arról, hogy mit érdemes tudni a Kubernetes-t üzemeltető kollégáknak.

Az alkalmazások Kubernetesen történő üzembe helyezésének egyik fő előnye a zökkenőmentes alkalmazásfelderítés. A klaszteren belüli interakció a szolgáltatási koncepciónak köszönhetően jelentősen leegyszerűsödik (szolgáltatás), amely egy virtuális IP, amely támogatja a pod IP-címek készletét. Például, ha a szolgáltatás vanilla kapcsolatba kíván lépni a szervizzel chocolate, közvetlenül hozzáférhet a virtuális IP-címhez chocolate. Felmerül a kérdés: ebben az esetben kinek oldja meg a DNS-kérést chocolate És hogyan?

A DNS-névfeloldás egy Kubernetes-fürtön van konfigurálva a használatával CoreDNS. A Kubelet névszerverként regisztrál egy pod-ot a CoreDNS-szel a fájlokban /etc/resolv.conf minden hüvely. Ha megnézed a tartalmat /etc/resolv.conf Bármelyik pod, valahogy így fog kinézni:

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

Ezt a konfigurációt a DNS-ügyfelek használják a kérések továbbítására a DNS-kiszolgálóhoz. Fájlban resolv.conf a következő információkat tartalmazza:

• névszerver: szerver, amelyre a DNS-kérések elküldésre kerülnek. Esetünkben ez a CoreDNS szolgáltatás címe;
• keresés: Meghatározza egy adott tartomány keresési útvonalát. Érdekes ez google.com vagy mrkaran.dev nem FQDN (teljesen minősített domain nevek). A legtöbb DNS-feloldó által követett általános konvenció szerint csak azok számítanak teljesen minősített (FDQN) tartományoknak, amelyek a gyökérzónát jelző "." ponttal végződnek. Egyes feloldók maguk is hozzáadhatnak egy pontot. És így, mrkaran.dev. a teljesen minősített domain név (FQDN), és mrkaran.dev - Nem;
• ndots: A legérdekesebb paraméter (ez a cikk erről szól). ndots megadja a pontok küszöbszámát a kérésnévben, mielőtt az „teljesen minősített” domain névnek minősülne. Erről később, a DNS-keresési szekvencia elemzésekor még többet fogunk beszélni.

Lássuk, mi történik, ha megkérdezzük mrkaran.dev podban:

$ 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

Ehhez a kísérlethez a CoreDNS naplózási szintjét értékre állítottam all (ami elég bőbeszédűvé teszi). Nézzük meg a hüvely naplóit 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

Fú. Itt két dolog ragadja meg a figyelmet:

• A kérés végigmegy a keresés minden szakaszán, amíg a válasz tartalmazza a kódot NOERROR (A DNS-kliensek megértik, és ennek eredményeként tárolják). NXDOMAIN azt jelenti, hogy nem található rekord az adott domain névhez. Mert a mrkaran.dev nem FQDN név (a szerint ndots=5), a megoldó megnézi a keresési útvonalat, és meghatározza a kérések sorrendjét;
• Blog А и АААА párhuzamosan érkezik. Az a tény, hogy az egyszeri kérések be /etc/resolv.conf Alapértelmezés szerint úgy vannak beállítva, hogy párhuzamos keresések IPv4 és IPv6 protokollok használatával történjenek. Ezt a viselkedést az opció hozzáadásával törölheti single-request в resolv.conf.

Megjegyzés: glibc beállítható úgy, hogy ezeket a kéréseket egymás után küldje el, és musl - nem, ezért az Alpine felhasználóknak tudomásul kell venniük.

Kísérletezés az ndots-szal

Kísérletezzünk még egy kicsit ndots és nézzük meg, hogyan viselkedik ez a paraméter. Az ötlet egyszerű: ndots meghatározza, hogy a DNS-ügyfél abszolút vagy relatívként kezeli-e a tartományt. Például egy egyszerű google DNS kliens esetén honnan tudja, hogy ez a tartomány abszolút? Ha beállítod ndots egyenlő 1-gyel, az ügyfél azt mondja: "Ó, be google nincs egyetlen pont sem; Azt hiszem, végig fogom nézni a teljes keresési listát." Ha azonban megkérdezed google.com, az utótagok listája teljesen figyelmen kívül marad, mert a kért név eléri a küszöbértéket ndots (legalább egy pont van).

Győződjünk meg erről:

$ 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 naplók:

[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

Óta mrkaran egyetlen pont sincs, a keresést a teljes utótaglistán végeztük.

Megjegyzés: a gyakorlatban a maximális érték ndots 15-re korlátozva; alapértelmezés szerint a Kubernetesben 5.

Alkalmazás a termelésben

Ha egy alkalmazás sok külső hálózati hívást bonyolít le, akkor aktív forgalom esetén a DNS szűk keresztmetszetgé válhat, mivel a névfeloldás sok felesleges lekérdezést hajt végre (mielőtt a rendszer ráér a megfelelőre). Az alkalmazások általában nem adnak hozzá gyökérzónát a domainnevekhez, de ez feltörésnek hangzik. Vagyis kérdezés helyett api.twitter.com, akkor "hardcode" azt api.twitter.com. (ponttal) az alkalmazásban, amely arra kéri a DNS-klienseket, hogy mérvadó kereséseket hajtsanak végre közvetlenül az abszolút tartományban.

Ezenkívül a Kubernetes 1.14-es verziójától kezdve a bővítmények dnsConfig и dnsPolicy stabil állapotot kapott. Így a pod üzembe helyezésekor csökkentheti az értéket ndots, mondjuk 3-ig (és akár 1-ig is!). Emiatt a csomóponton belül minden üzenetnek tartalmaznia kell a teljes tartományt. Ez az egyik klasszikus kompromisszum, amikor választani kell a teljesítmény és a hordozhatóság között. Számomra úgy tűnik, hogy csak akkor kell aggódnia emiatt, ha az ultra-alacsony késleltetés létfontosságú az alkalmazás számára, mivel a DNS-eredmények is belső gyorsítótárban vannak.

referenciák

Először tanultam erről a funkcióról K8s-meetupjanuár 25-én került megrendezésre. Többek között erről a problémáról is szó esett.

Íme néhány link a további felfedezéshez:

• Magyarázat, miért ndots=5 a Kubernetesben;
• Kiváló anyag hogyan befolyásolja az ndots megváltoztatása az alkalmazások teljesítményét;
• eltérések musl és glibc megoldók között.

Megjegyzés: Úgy döntöttem, hogy nem használom dig ebben a cikkben. dig automatikusan hozzáad egy pontot (gyökérzóna azonosítót), így a domain "teljesen minősített" (FQDN), nincs úgy, hogy először végigfuttatja a keresési listán. Ebben írt erről az egyik korábbi kiadvány. Meglepő azonban, hogy általában külön zászlót kell megadni a normál viselkedéshez.

Boldog DNS-ezést! Később találkozunk!

PS a fordítótól

Olvassa el blogunkon is:

• «Calico hálózatépítéshez Kubernetesben: bemutatkozás és egy kis tapasztalat";
• «CoreDNS – DNS-kiszolgáló a felhő natív világához és Service Discovery a Kubernetes számára";
• "Illusztrált útmutató a Kubernetes hálózatépítéshez": 1. és 2. rész (hálózati modell, átfedő hálózatok), 3. rész (szolgáltatások és forgalomfeldolgozás).

Forrás: will.com