🥇DNS keresés a Kubernetesben

Megjegyzés fordítás.: DNS probléma Kubernetesben, pontosabban a paraméter beállítása ndots, - meglepő módon népszerű, sőt már nem először év. Egy újabb bejegyzésben erről a témáról a szerző - egy DevOps mérnök egy nagy bróker cégtől Indiában - nagyon egyszerű és tömör módon mesél arról, hogy mit érdemes tudniuk a Kubernetes-t használó kollégáknak.

A Kubernetesben való alkalmazásbevezetés egyik fő előnye a problémamentes alkalmazásfelfedezés. A belső klaszter interakciók jelentősen egyszerűsödnek a szolgáltatás (Service), amely egy virtuális IP-t képvisel, amely támogatja a podok IP-címek halmazát. Például, ha a szolgáltatás vanilla kapcsolatba szeretne lépni a szolgáltatással chocolate, közvetlenül a virtuális IP-hez fordulhat a chocolate. Felmerül a kérdés: ki fogja ebben az esetben feloldani a DNS lekérdezést a chocolate és hogyan?

A DNS névfeloldás a Kubernetes klaszterben a CoreDNSsegítségével van beállítva. A Kubelet a pod-ot a CoreDNS-t nevezve meg névszerverként az összes pod fájlban. /etc/resolv.conf Ha megnézzük bármelyik pod tartalmát, körülbelül a következőképpen fog kinézni: /etc/resolv.conf search hello.svc.cluster.local svc.cluster.local cluster.local nameserver 10.152.183.10 options ndots:5

Ez a konfiguráció a DNS-kliensek által a DNS-szerverre irányuló lekérdezések átirányítására használatos. A

resolv.conf fájl tartalmazza a következő információt: nameserver

: a szerver, amelyre a DNS-lekérdezések irányulnak. A mi esetünkben ez a CoreDNS szolgáltatás címe;search
: a megadott domain keresési útvonalát határozza meg. Érdekes, hogygoogle.com mrkaran.dev vagy nem FQDN ( teljes domainnevek). A legtöbb DNS feloldó által követett standard megállapodás szerint csak azok a nevek tekinthetők teljessé (FQDN), amelyek ponttal '.' végződnek, ami a gyökérzónát jelöli. Néhány feloldó képes automatikusan hozzáadni a pontot. Ígymrkaran.dev. – teljes domainnév (FQDN), míg nem; nem FQDN ( : A legérdekesebb paraméter (erről a cikk szól).
ndotsmeghatározza a kérés nevében a pontok küszöbértékét, amikor elérik, akkor azt «teljes» domainnévnek tekintik. Ezzel részletesebben foglalkozunk később, amikor elemezzük a DNS-keresési folyamatot. ndots Nézzük meg, mi történik, amikor a

pod-ban kérjük: nem FQDN ( $ nslookup mrkaran.dev Server: 10.152.183.10 Address: 10.152.183.10#53Nem autoritásos válasz: Név: mrkaran.dev Cím: 157.230.35.153 Név: mrkaran.dev Cím: 2400:6180:0:d1::519:6001

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

Nem hivatalos válasz:
Név: mrkaran.dev
Cím: 157.230.35.153
Név: mrkaran.dev
Cím: 2400:6180:0:d1::519:6001

Ehhez a kísérlethez a CoreDNS naplózási szintet állítottam be mind (ami meglehetősen bőséges); nézzük meg a pod 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

Húha. Két dolog itt felhívja a figyelmet:

A kérdés végigmegy a keresési folyamat minden lépésén, amíg a válasz nem tartalmaz kódot NOERROR (a DNS-kliensek ezt megértik és eredményként tárolják). NXDOMAIN azt jelenti, hogy a megadott domain névhez nem található rekord. Mivel nem FQDN ( nem egy FQDN név (a következő szerint: ndots=5), a resolver a keresési útra néz és meghatározza a kérdések sorrendjét;
A rekordok A és AAAAA párhuzamosan érkeznek. Az a helyzet, hogy az egyszeri kérdéseket a /etc/resolv.conf alapértelmezés szerint úgy állították be, hogy párhuzamos keresést végezzen az IPv4 és IPv6 protokollok között. Ezt a viselkedést megszüntethetjük, ha hozzáadjuk a single-request be. fájl tartalmazza a következő információt:.

Megjegyzés: glibc-t beállíthatjuk, hogy ezeket a kéréseket sorban küldje el, de musl nem, tehát az Alpine felhasználóknak ezt figyelembe kell venniük.

Kísérletezünk az ndots-tal

Kísérletezzünk még egy kicsit a ndots -val, és nézzük meg, hogyan viselkedik ez a beállítás. Az ötlet egyszerű: ndots meghatározza, hogy a DNS-kliens abszolútnak vagy relatívnak tekinti-e a domaint. Például, ahogy a sima Google DNS-kliens megismeri, hogy ez a domain abszolút-e? Ha a ndots értéke 1, a kliens azt mondja: „Ó, a google nem tartalmaz egyetlen pontot sem; talán végigfutok az összes keresési listán”. A kérdezés viszont, mrkaran.dev, a suffix lista teljesen figyelmen kívül lesz hagyva, mivel a megadott név eleget tesz a küszöbnek ndots (van legalább egy pont).

Biztosítsuk be ezt:

$ 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

Mivel a mrkaran nem tartalmaz egyetlen pontot sem, a keresés az összes suffix lista alapján zajlott.

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

Production használata

Ha az alkalmazás sok külső hálózati hívást végez, a DNS szűk keresztmetszetté válhat aktív forgalom esetén, mivel a név feloldása során számos felesleges lekérdezést végeznek (mielőtt a rendszer eljutna a szükségeshez). Az alkalmazások általában nem adnak hozzá gyökérzónát a domainnevekhez, de ez teljesen hacknek számít. Vagyis ahelyett, hogy lekérdezné az api.twitter.com, „hardcode”-olhatja az api.twitter.com. (ponttal) az alkalmazásban, ami arra ösztönzi a DNS-ügyfeleket, hogy közvetlenül az abszolút név területén végezzenek hatósági keresést.

Ezenkívül a Kubernetes 1.14-es verziójától kezdődően a kiterjesztések dnsConfig és dnsPolicy stabil státuszt kaptak. Tehát pod telepítésekor csökkenthető az érték ndots, mondjuk 3-ra (és akár 1-re is!). Emiatt minden üzenetnek a csomóponton belül tartalmaznia kell a teljes domaint. Ez egy klasszikus kompromisszum, amikor teljesítmény és hordozhatóság között kell választani. Szerintem csak abban az esetben érdemes ezen aggódni, ha a rendkívül alacsony késleltetések létfontosságúak az alkalmazás számára, mivel a DNS eredmények is gyorsítótárazva vannak.

Hivatkozások

Erről a tulajdonságról először a K8s-meetup-on, amely január 25-én zajlott. Ott többek között erről a problémáról is szó esett.

Íme néhány további hivatkozás a tanulmányozáshoz:

Magyarázat, miért ndots=5 a Kubernetesben;
Nagyszerű anyag arról, hogyan befolyásolja az ndots módosítása az alkalmazás teljesítményét;
Eltérések a musl és glibc resolver-ek között.

Megjegyzés: úgy döntöttem, hogy nem használom a dig ebben a cikkben. dig automatikusan hozzáad egy pontot (a gyökérzóna azonosítója), teljesé téve a domaint (FQDN), nem előkészítve azt egy keresési lista révén. Erről írtam az egyik korábbi bejegyzésemben. Mindenesetre meglepő, hogy a normál viselkedéshez külön zászlót kell beállítani.

Jó DNS-zést! Hamarosan találkozunk!