🥇DNS-sökning i Kubernetes

Obs. övers.: DNS-problemet i Kubernetes, mer specifikt - inställning av parameter Från manualen för, - är förvånansvärt populärt, och det har redan inte första år. I en ny artikel om detta ämne berättar författaren - en DevOps-ingenjör från ett stort mäklarföretag i Indien - på ett mycket enkelt och koncist sätt vad kollegor som använder Kubernetes behöver känna till.

En av de främsta fördelarna med att distribuera applikationer i Kubernetes är det problemfria upptäckandet av applikationer. Den interna kommunikation inom klustret förenklas avsevärt tack vare tjänstkonceptet (Tjänst), vilket representerar en virtuell IP som stöder en uppsättning IP-adresser av poddar. Till exempel, om tjänsten vanilla vill kommunicera med tjänsten chocolate, kan den direkt hänvisa till den virtuella IP-adressen för chocolate. Frågan uppstår: vem kommer i detta fall att lösa DNS-förfrågan till chocolate och hur?

Namnupplösningen DNS konfigureras i Kubernetes-klustret med hjälp av CoreDNS. Kubelet registrerar podden med CoreDNS som namnserver i filerna /etc/resolv.conf av alla poddar. Om du tittar på innehållet i /etc/resolv.conf vilken pod som helst, kommer det att se ut ungefär så här:

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

Denna konfiguration används av DNS-klienter för att omdirigera förfrågningar till DNS-servern. I filen resolv.conf finns följande information:

nameserver: servern som DNS-förfrågningar kommer att riktas till. I vårt fall är detta adressen till CoreDNS-tjänsten;
Det finns en option: definierar sökvägen för ett visst domännamn. Det är intressant att google.com eller mrkaran.dev inte är FQDN (fullständiga domännamn). Enligt den standard som de flesta DNS-resolvrar följer anses fullständiga (FDQN) domäner endast vara de som slutar med en punkt «.», vilket representerar rotzonen. Vissa resolvrar kan lägga till punkten själva. Således är mrkaran.dev. ett fullständigt domännamn (FQDN), medan mrkaran.dev inte är det;
Från manualen för: Den mest intressanta parametern (denna artikel handlar just om den). Från manualen för anger det tröskelnummer av punkter i namnfrågan, vid vilken den betraktas som ett «fullständigt» domännamn. Mer om detta kommer vi att diskutera senare när vi analyserar sekvensen av DNS-sökningar.

Låt oss titta på vad som händer när vi begär mrkaran.dev i podden:

$ 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

För detta experiment har jag ställt in loggnivån för CoreDNS på all (что делает его весьма многословным). Посмотрим на логи 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 означает, что для данного доменного имени запись не найдена. Поскольку mrkaran.dev не является FQDN-именем (в соответствии с ndots=5), resolver смотрит на поисковый путь и определяет порядок запросов;
Записи A och AAAAA поступают параллельно. Дело в том, что разовые запросы в /etc/resolv.conf по умолчанию настроены таким образом, что производится параллельный поиск по протоколам IPv4 и IPv6. Отменить подобное поведение можно, добавив опцию single-request på resolv.conf.

Anmärkning: glibc можно настроить на последовательную отправку этих запросов, а musl — нет, так что пользователям Alpine следует принять это к сведению.

Экспериментируем с ndots

Давайте еще немного поэкспериментируем с Från manualen för и посмотрим, как себя ведет этот параметр. Идея проста: Från manualen för определяет, будет ли DNS-клиент считать домен абсолютным или относительным. Например, как в случае простого google DNS-клиент узнает, является ли этот домен абсолютным? Если задать Från manualen för равным 1, клиент скажет: «О, в google нет ни одной точки; пожалуй, пробегусь по всему списку поиска». Однако если запросить google.com, список суффиксов будет целиком проигнорирован, поскольку запрошенное имя удовлетворяет порогу Från manualen för (имеется хотя бы одна точка).

Давайте убедимся в этом:

$ 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-loggar:

[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

Eftersom det i mrkaran нет ни одной точки, поиск проводился по всему списку суффиксов.

Примечание: на практике максимальное значение Från manualen för ограничено 15; по умолчанию в Kubernetes оно равно 5.

Применение в production

Om en applikation gör många externa nätverksanrop kan DNS bli en flaskhals vid aktiv trafik, eftersom många onödiga förfrågningar görs vid namnupplösning (innan systemet når det önskade). Applikationer lägger vanligtvis inte till rotzonen i domännamnen, men detta kan definitivt räknas som ett hack. Med andra ord, istället för att begära api.twitter.com, kan du 'hårdprogrammera' api.twitter.com. (med punkt) i applikationen, vilket får DNS-klienter att omedelbart utföra en auktoritativ sökning i den absoluta domänen.

Dessutom, från och med version 1.14 av Kubernetes, har tilläggen dnsConfig och ClusterFirst fått status som stabila. Därmed kan värdet minskas vid distribution av en pod Från manualen för, låt oss säga, till 3 (och till och med ner till 1!). Detta innebär att varje meddelande inom noden måste innehålla hela domänen. Det här är en klassisk kompromiss när man måste välja mellan prestanda och portabilitet. Jag tycker att man bara ska oroa sig för detta om ultra-låga latenser är avgörande för din applikation, eftersom DNS-resultaten även cachas internt.

Länkar

Jag lärde mig först om denna funktion på K8s-meetup, som hölls den 25 januari. Där diskuterades bland annat detta problem.

Här är några länkar för vidare läsning:

Förklaring, varför ndots=5 i Kubernetes;
Ett utmärkt material om hur ändringen av ndots påverkar applikationens prestanda;
Skillnader mellan resolverna musl och glibc.

Notera: Jag valde att inte använda dig i denna artikel. dig lägger automatisk till en punkt (rotzonens identifierare), vilket gör domänen "full" (FQDN), inte efter att ha kört den genom söklistan. Jag skrev om detta i en av mina tidigare publikationer. Trots detta är det ganska förvånande att man måste ange en separat flagga för standardbeteendet.

Lycka till med DNS! Vi ses snart!

P.S. från översättaren

Läs även i vår blogg:

«Calico för nätverk i Kubernetes: introduktion och lite erfarenhet»;
«CoreDNS — DNS-server för cloud native-världen och Service Discovery för Kubernetes»;
»Illustrerad guide till nätverksuppbyggnaden i Kubernetes«: delar 1 och 2 (nätverksmodell, överlagrade nätverk), del 3 (tjänster och trafikhantering).

Källa: habr.com