DNS търсене в Kubernetes

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

Едно от основните предимства на внедряването на приложения в Kubernetes е безпроблемното откриване на приложения. Взаимодействието между клъстерите е значително опростено благодарение на концепцията за обслужване (обслужване), което е виртуален IP, който поддържа набор от IP адреси на pod. Например, ако услугата 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), резолверът разглежда пътя за търсене и определя реда на заявките;
• Recordings А и АААА пристигат успоредно. Факт е, че еднократните заявки в /etc/resolv.conf По подразбиране те са конфигурирани по такъв начин, че да се извършват паралелни търсения с помощта на протоколите IPv4 и IPv6. Можете да отмените това поведение, като добавите опцията single-request в resolv.conf.

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

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

Нека експериментираме още малко с ndots и нека да видим как се държи този параметър. Идеята е проста: ndots определя дали DNS клиентът ще третира домейна като абсолютен или относителен. Например, в случай на обикновен DNS клиент на Google, как той знае дали този домейн е абсолютен? Ако зададете 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 получи стабилно състояние. По този начин, когато разгръщате pod, можете да намалите стойността ndots, да речем, до 3 (и дори до 1!). Поради това всяко съобщение в рамките на възел ще трябва да включва пълния домейн. Това е един от класическите компромиси, когато трябва да избирате между производителност и преносимост. Струва ми се, че трябва да се тревожите за това само ако ултра ниската латентност е жизненоважна за вашето приложение, тъй като резултатите от DNS също се кешират вътрешно.

Позоваването

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

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

• обяснение, защо ndots=5 в Kubernetes;
• Страхотни неща как промяната на ndots влияе върху производителността на приложението;
• Несъответствия между musl и glibc резолвери.

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

Приятно DNS! До скоро!

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

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

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

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