Kubernetes жүйесінде DNS іздеу

Ескерту. аударма: Kubernetes жүйесіндегі DNS мәселесі немесе дәлірек айтқанда, параметр параметрлері ndots, таңқаларлық танымал және қазірдің өзінде Бірінші емес жыл. Осы тақырыпқа қатысты басқа жазбада оның авторы, Үндістандағы ірі брокерлік компанияның DevOps инженері, Kubernetes-ті басқаратын әріптестерге нені білу пайдалы екендігі туралы өте қарапайым және қысқаша әңгімелейді.

Kubernetes қолданбасында қолданбаларды орналастырудың негізгі артықшылықтарының бірі - қолданбаларды үздіксіз табу. Кластер ішілік өзара әрекеттесу сервистік тұжырымдаманың арқасында айтарлықтай жеңілдетілген (қызмет көрсету), бұл қос IP мекенжайлар жинағын қолдайтын виртуалды IP. Мысалы, егер қызмет vanilla қызметіне хабарласқысы келеді chocolate, ол виртуалды IP мекенжайына тікелей қол жеткізе алады chocolate. Сұрақ туындайды: бұл жағдайда DNS сұрауын кім шешеді chocolate және қалай?

DNS атауының ажыратымдылығы Kubernetes кластерінде конфигурацияланады CoreDNS. Kubelet файлдардағы атау сервері ретінде CoreDNS көмегімен подкастты тіркейді /etc/resolv.conf барлық бұршақ. Мазмұнына қарасаңыз /etc/resolv.conf кез келген подвод, ол келесідей болады:

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

Бұл конфигурацияны DNS клиенттері сұрауларды DNS серверіне қайта жіберу үшін пайдаланады. Файлда resolv.conf келесі ақпаратты қамтиды:

• атау сервері: DNS сұраулары жіберілетін сервер. Біздің жағдайда бұл CoreDNS қызметінің мекенжайы;
• іздеу: Белгілі бір домен үшін іздеу жолын анықтайды. Бұл қызық google.com немесе mrkaran.dev FQDN емес (толық жарамды домен атаулары). Көптеген DNS шешушілері ұстанатын стандартты конвенцияға сәйкес, түбірлік аймақты білдіретін "." нүктесімен аяқталатындар ғана толық білікті (FDQN) домендері болып саналады. Кейбір шешушілер нүктені өздері қоса алады. Осылайша, mrkaran.dev. толық жарамды домен атауы (FQDN) болып табылады және mrkaran.dev - Жоқ;
• нүктелер: Ең қызықты параметр (бұл мақала бұл туралы). ndots сұрау атауындағы нүктелердің шекті санын ол «толық жарамды» домендік атау болып саналмас бұрын көрсетеді. Бұл туралы кейінірек DNS іздеу тізбегін талдағанда айтатын боламыз.

Біз сұраған кезде не болатынын көрейік mrkaran.dev бөлімде:

$ 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

Бұл эксперимент үшін мен CoreDNS журналын тіркеу деңгейін орнаттым all (бұл оны өте егжей-тегжейлі етеді). Бұршақ журналдарын қарастырайық 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

Фу. Мұнда екі нәрсе назар аударады:

• Жауапта код болғанша сұрау іздеудің барлық кезеңдерінен өтеді NOERROR (DNS клиенттері оны түсінеді және нәтижесінде сақтайды). NXDOMAIN берілген домендік атау үшін жазба табылмағанын білдіреді. Өйткені mrkaran.dev FQDN атауы емес (сәйкес ndots=5), шешуші іздеу жолын қарап, сұраныстардың ретін анықтайды;
• Жазбалар А и АААА параллель келеді. Өйткені, бір реттік сұраныстар /etc/resolv.conf Әдепкі бойынша, олар параллельді іздеулер IPv4 және IPv6 хаттамалары арқылы орындалатындай етіп конфигурацияланады. Опцияны қосу арқылы бұл әрекеттен бас тартуға болады single-request в resolv.conf.

Ескертпе: glibc осы сұрауларды ретімен жіберу үшін конфигурациялануы мүмкін және musl - жоқ, сондықтан Альпі пайдаланушылары ескеруі керек.

Ndots арқылы тәжірибе жасау

Кішкене тәжірибе жасап көрейік ndots және бұл параметр қалай әрекет ететінін көрейік. Идея қарапайым: ndots DNS клиенті доменді абсолютті немесе салыстырмалы ретінде қарастыратынын анықтайды. Мысалы, қарапайым Google DNS клиенті жағдайында бұл доменнің абсолютті екенін ол қайдан біледі? Егер сіз орнатсаңыз ndots 1-ге тең болса, клиент: «О, в google бір нүкте жоқ; Мен бүкіл іздеу тізімін қарап шығамын деп ойлаймын ». Дегенмен, сұрасаңыз google.com, жұрнақтар тізімі толығымен еленбейді, себебі сұралған атау шекті мәнге сәйкес келеді ndots (кем дегенде бір нүкте бар).

Осыған көз жеткізейік:

$ 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 журналдары:

[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

Бастап mrkaran бір нүкте жоқ, іздеу жұрнақтардың бүкіл тізімі бойынша жүргізілді.

Ескерту: іс жүзінде максималды мән ndots 15-ке дейін шектелген; әдепкі бойынша Kubernetes-те бұл 5.

Өндірісте қолдану

Егер қолданба көптеген сыртқы желілік қоңырауларды жасаса, DNS белсенді трафик жағдайында тығырықтан шығуы мүмкін, өйткені атауды шешу көптеген қажетсіз сұрауларды жасайды (жүйе оң жаққа жеткенге дейін). Қолданбалар әдетте домен атауларына түбірлік аймақты қоспайды, бірақ бұл бұзу сияқты естіледі. Яғни, сұраудың орнына api.twitter.com, сіз қатты кодтай аласыз api.twitter.com. (нүктемен) қолданбада, ол DNS клиенттерін абсолютті доменде тікелей беделді іздеулерді орындауға шақырады.

Сонымен қатар, Kubernetes 1.14 нұсқасынан бастап кеңейтімдер dnsConfig и dnsPolicy тұрақты күйге ие болды. Осылайша, подкастты орналастыру кезінде мәнді азайтуға болады ndots, айталық, 3-ке дейін (тіпті 1-ге дейін!). Осыған байланысты түйіндегі әрбір хабарлама толық доменді қамтуы керек. Бұл өнімділік пен портативтілік арасында таңдау керек кездегі классикалық келіссөздердің бірі. Менің ойымша, бұл туралы тым төмен кідіріс қолданбаңыз үшін маңызды болса ғана алаңдау керек сияқты, өйткені DNS нәтижелері де ішкі кэште сақталады.

сілтемелер

Мен бұл функция туралы бірінші рет білдім K8s-кездесу, 25 қаңтарда өтті. Басқа мәселелермен қатар, осы мәселеге қатысты пікірталас болды.

Мұнда қосымша зерттеуге арналған кейбір сілтемелер берілген:

• Түсіндіру, неге ndots=5 Kubernetes;
• Тамаша заттар ndots өзгерту қолданбаның өнімділігіне қалай әсер етеді;
• Сәйкессіздіктер musl және glibc шешушілері арасында.

Ескерту: Мен қолданбауды таңдадым dig осы мақалада. dig автоматты түрде нүктені (түбірлік аймақ идентификаторы) қосады, доменді «толық білікті» (FQDN) етеді; емес алдымен оны іздеу тізімі арқылы іске қосу арқылы. Бұл туралы жазған алдыңғы басылымдардың бірі. Дегенмен, жалпы стандартты мінез-құлық үшін бөлек жалаушаны көрсету керек екендігі таңқаларлық.

Бақытты DNS! Көріскенше!

Аудармашыдан PS

Біздің блогта да оқыңыз:

• «Кубернетестегі желіге арналған Calico: кіріспе және кішкене тәжірибе«;
• «CoreDNS - бұлттық әлемге арналған DNS сервері және Kubernetes үшін Service Discovery«;
• «Кубернетестегі желіге арналған иллюстрациялық нұсқаулық»: 1 және 2 бөліктер (желі үлгісі, қабаттасатын желілер), 3-бөлім (қызметтер және трафикті өңдеу).

Ақпарат көзі: www.habr.com