🥇DNS търсене в Kubernetes

Прим. прев.: DNS проблемата в Kubernetes, по-скоро — настройката на параметъра ndots, — е удивително популярна, и то не за първи . В поредната бележка по тази тема, авторът — DevOps инженер от голяма брокерска компания в Индия — в много прост и лаконичен стил разказва какво е полезно да знаят колегите, ползващи Kubernetes. годинаЕдно от основните предимства на разгръщането на приложения в Kubernetes е безпроблемното откритие на приложения. Вътрешнокластерното взаимодействие се опрощава значително благодарение на концепцията за услуга (

), която представлява виртуален IP, поддържащ набор от IP адреси на pod-ове. Например, ако услугатаServiceжелая да се свърже с услугата vanilla chocolate , тя може да се обърне директно към виртуалния IP за. Възниква въпросът: кой в този случай ще разреши DNS запитването към , тя може да се обърне директно към виртуалния IP заи как? , тя може да се обърне директно към виртуалния IP за Разрешаването на DNS имена се настройва в кластер Kubernetes с помощта на

. Kubelet записва pod с CoreDNS като DNS сървър в файловете CoreDNSна всички pod-ове. Ако погледнем съдържанието на /etc/resolv.conf който и да е pod, то ще изглежда приблизително по следния начин: /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 nameserver

: сървърът, към който ще бъдат насочвани DNS запитванията. В нашия случай това е адресът на CoreDNS услугата;: определя пътя за търсене на определен домейн. Интересно е, че
searchmrkaran.dev google.com или не са FQDN ( пълни домейн имена). Според стандартната практика, следвана от повечето DNS решаващи единици, пълните (FQDN) домейни са само тези, които завършват с точка „.“, представляваща кореновата зона. Някои решаващи единици могат да добавят точка сами. Така че,mrkaran.dev. — е пълно домейн име (FQDN), а — не; не са FQDN ( : Най-интересният параметър (тази статия точно за него).
ndotsопределя прагова стойност на точките в името на запитването, при достигането на която то се счита за „пълно“ домейн име. Накратко за това ще говорим по-късно, когато анализираме последователността на DNS търсенето. ndots Нека да разгледаме какво се случва, когато запитваме

в pod: не са FQDN ( $ nslookup mrkaran.dev Server: 10.152.183.10 Address: 10.152.183.10#53Non-authoritative answer: Name: mrkaran.dev Address: 157.230.35.153 Name: mrkaran.dev Address: 2400:6180:0:d1::519:6001

За този експеримент настроих нивото на логиране на CoreDNS на

За този експеримент настроих нивото на логване на CoreDNS на всички (което го прави доста многословен). Нека да погледнем логовете на pod-а 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 означава, че за това домейно име записа не е намерен. Понеже не са FQDN ( не е FQDN име (съгласно ndots=5), резолвера разглежда пътя за търсене и определя реда на запитванията;
Записите И и АААА пристигат паралелно. Работата е, че индивидуалните запитвания в /etc/resolv.conf по подразбиране са настроени да извършват паралелно търсене както по протоколите IPv4, така и по IPv6. Можете да отмените това поведение, като добавите опцията single-request в resolv.conf.

Забележка: glibc може да се настрои за последователна изпращане на тези запитвания, а musl — не, така че потребителите на Alpine трябва да го имат предвид.

Експериментираме с ndots

Нека да експериментираме малко повече с ndots и да видим как се държи този параметър. Идеята е проста: ndots определя дали DNS клиентът ще счита домена за абсолютен или относителен. Например, как DNS клиентът разбира, че този домен е абсолютен? Ако зададете ndots равен на 1, клиентът ще каже: „О, в google няма нито една точка; вероятно ще проверя целия списък за търсене“. Но ако поискате google.com, списъкът с суфикси ще бъде напълно игнориран, тъй като зададеното име отговаря на прага ndots (има поне една точка).

Нека да се уверим в това:

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Сървър: 10.152.183.10
Адрес: 10.152.183.10#53

** сървърът не може да намери 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.

Приложение в production

Ако приложението прави множество външни мрежови повиквания, DNS може да стане проблематично място при активен трафик, тъй като при разрешаването на името се извършват множество излишни запитвания (преди системата да стигне до необходимо). Приложенията обикновено не добавят кореновата зона към домейн имената, но това може да се нарече хак. Тоест вместо да запитвате api.twitter.com, можете да 'hardcode'-нете api.twitter.com. (с точка) в приложението, което ще накара DNS клиентите да извършат авторитетно търсене веднага в абсолютния домейн.

Освен това, от версия 1.14 на Kubernetes, разширенията dnsConfig и dnsPolicy получиха статут на стабилни. Следователно, при разгръщане на pod, можете да намалите стойността ndots, да кажем, до 3 (и дори до 1!). Поради това всяко съобщение вътре в възела ще трябва да включва пълния домейн. Това е един от класическите компромиси, когато се налага да избирате между производителност и преносимост. Смятам, че трябва да се притеснявате за това, само ако свръхниските закъснения са от жизненоважно значение за вашето приложение, тъй като резултатите от DNS също се кешират вътре.

Връзки

За първи път научих за тази функция на K8s-meetup, който се проведе на 25 януари. Там се обсъждаше и този проблем.

Ето няколко линка за допълнително проучване:

Обяснение, защо ndots=5 в Kubernetes;
Отличен материал за това как промяната на ndots влияе върху производителността на приложението;
Разминавания между resolver-ите musl и glibc.

Забележка: Предпочетох да не използвам dig в тази статия. dig автоматично добавя точка (идентификатор на кореновата зона), правейки домейна «пълен» (FQDN), не като го пропуска предварително през списъка за търсене. Писах за това в една от предишните публикации.. Въпреки това, доста учудващо е, че за стандартно поведение трябва да зададете отделен флаг.

Успешно DNS-ене! До скоро!

P.S. от преводача

Прочетете също в нашия блог:

«Calico за мрежи в Kubernetes: запознаване и малко от опита»;
«CoreDNS — DNS сървър за света на cloud native и Service Discovery за Kubernetes»;
«Илюстрирано ръководство за мрежи в Kubernetes»: части 1 и 2 (мрежови модели, оверлейни мрежи), част 3 (услуги и управление на трафика).

Източник: habr.com