Пребарување DNS во Kubernetes

Забелешка. превод.: Проблем со DNS во Kubernetes, или поточно, параметри поставки ndots, е изненадувачки популарен, и веќе Не прво година. Во друга белешка на оваа тема, нејзиниот автор, инженер DevOps од голема брокерска компанија во Индија, зборува на многу едноставен и концизен начин за тоа што е корисно да знаат колегите кои работат со Kubernetes.

Една од главните придобивки од распоредувањето на апликациите на Kubernetes е беспрекорното откривање апликации. Интеракцијата меѓу кластерот е значително поедноставена благодарение на концептот на услугата (Сервис), што е виртуелна IP адреса која поддржува збир од IP-адреси. На пример, ако услугата vanilla сака да ја контактира услугата chocolate, може директно да пристапи до виртуелната IP адреса chocolate. Се поставува прашањето: кој во овој случај ќе го реши барањето DNS chocolate И како?

Резолуцијата на името на DNS е конфигурирана на кластерот Kubernetes користејќи CoreDNS. Kubelet регистрира pod со 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 во 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

За овој експеримент, го поставив нивото на евиденција на 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 - не, затоа корисниците на Alpine треба да внимаваат.

Експериментирање со точки

Ајде да експериментираме малку повеќе со 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 може да стане тесно грло во случај на активен сообраќај, бидејќи резолуцијата на името прави многу непотребни прашања (пред системот да дојде до вистинското). Апликациите обично не додаваат root зона на имињата на домени, но ова звучи како хакирање. Односно, наместо да прашува api.twitter.com, можете да го „хардкодирате“. api.twitter.com. (со точка) во апликацијата, што ќе ги поттикне клиентите на DNS да вршат авторитативни пребарувања директно на апсолутниот домен.

Дополнително, почнувајќи од Кубернетес верзија 1.14, екстензии dnsConfig и dnsPolicy доби стабилен статус. Така, кога распоредувате под, можете да ја намалите вредноста ndots, да речеме, до 3 (па дури и до 1!). Поради ова, секоја порака во еден јазол ќе мора да го вклучи целиот домен. Ова е една од класичните компромиси кога треба да изберете помеѓу перформанси и преносливост. Ми се чини дека треба да се грижите за ова само ако ултра ниската латентност е од витално значење за вашата апликација, бидејќи резултатите од DNS исто така се кеширани внатрешно.

референци

Првпат научив за оваа функција на K8s-состанок, одржана на 25 јануари. За овој проблем, меѓу другото, се разговараше.

Еве неколку линкови за понатамошно истражување:

• Објаснување, зошто ndots=5 во Kubernetes;
• Одлични работи како менувањето точки влијае на перформансите на апликацијата;
• Несогласувања помеѓу musl и glibc резолутори.

Забелешка: Избрав да не користам dig во овој напис. dig автоматски додава точка (идентификатор на коренската зона), правејќи го доменот „целосно квалификуван“ (FQDN), Нема со тоа што прво ќе го извршите низ списокот за пребарување. Напиша за ова во една од претходните публикации. Сепак, сосема е изненадувачки што, генерално, треба да се специфицира посебно знаменце за стандардното однесување.

Среќен DNSing! Се гледаме подоцна!

PS од преведувач

Прочитајте и на нашиот блог:

• «Калико за вмрежување во Кубернетес: вовед и малку искуство";
• «CoreDNS - DNS сервер за мајчиниот свет на облакот и Service Discovery за Kubernetes";
• „Илустриран водич за вмрежување во Кубернетес“: делови 1 и 2 (мрежен модел, преклопени мрежи), дел 3 (услуги и сообраќајна обработка).

Извор: www.habr.com