Cerca de DNS a Kubernetes

Nota. transl.: problema de DNS a Kubernetes, o més precisament, la configuració dels paràmetres ndots, és sorprenentment popular, i ja No primer any. En una altra nota sobre aquest tema, el seu autor, un enginyer de DevOps d'una gran empresa de corretatge a l'Índia, parla d'una manera molt senzilla i concisa sobre què és útil que coneguin els companys que operen Kubernetes.

Un dels principals avantatges de desplegar aplicacions a Kubernetes és la descoberta perfecta d'aplicacions. La interacció intra-clúster es simplifica enormement gràcies al concepte de servei (servei), que és una IP virtual que admet un conjunt d'adreces IP de pod. Per exemple, si el servei vanilla desitja contactar amb el servei chocolate, pot accedir directament a la IP virtual chocolate. Es planteja la pregunta: a qui en aquest cas resoldrà la sol·licitud de DNS chocolate I com?

La resolució de noms DNS es configura en un clúster de Kubernetes mitjançant CoreDNS. Kubelet registra un pod amb CoreDNS com a servidor de noms als fitxers /etc/resolv.conf totes les beines. Si mireu el contingut /etc/resolv.conf qualsevol pod, tindrà un aspecte com això:

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

Aquesta configuració la fan servir els clients DNS per reenviar sol·licituds al servidor DNS. A l'arxiu resolv.conf conté la informació següent:

• servidor de noms: servidor al qual s'enviaran les peticions DNS. En el nostre cas, aquesta és l'adreça del servei CoreDNS;
• cerca: defineix el camí de cerca per a un domini específic. És interessant això google.com o mrkaran.dev no són FQDN (noms de domini totalment qualificats). D'acord amb la convenció estàndard que segueixen la majoria de resolutors DNS, només els que acaben amb un punt ".", que representa la zona arrel, es consideren dominis totalment qualificats (FDQN). Alguns solucionadors poden afegir un punt ells mateixos. Així, mrkaran.dev. és el nom de domini totalment qualificat (FQDN) i mrkaran.dev - No;
• ndots: El paràmetre més interessant (aquest article tracta sobre això). ndots especifica el nombre llindar de punts en un nom de sol·licitud abans que es consideri un nom de domini "completament qualificat". En parlarem més endavant quan analitzem la seqüència de cerca de DNS.

A veure què passa quan preguntem mrkaran.dev a la beina:

$ 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

Per a aquest experiment, he establert el nivell de registre CoreDNS a all (cosa que fa que sigui bastant verbosa). Mirem els registres de la beina 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

Uf. Aquí us criden l'atenció dues coses:

• La sol·licitud passa per totes les etapes de la cerca fins que la resposta conté el codi NOERROR (Els clients DNS ho entenen i l'emmagatzemen com a resultat). NXDOMAIN significa que no s'ha trobat cap registre per al nom de domini donat. Perquè el mrkaran.dev no és un nom FQDN (segons ndots=5), el resolutor mira el camí de cerca i determina l'ordre de les peticions;
• Entrades А и АААА arribar en paral·lel. El fet és que hi ha sol·licituds puntuals /etc/resolv.conf Per defecte, estan configurats de manera que es realitzen cerques paral·leles mitjançant els protocols IPv4 i IPv6. Podeu cancel·lar aquest comportament afegint l'opció single-request в resolv.conf.

Nota: glibc es pot configurar per enviar aquestes peticions de manera seqüencial i musl - no, així que els usuaris d'Alpine haurien de prendre nota.

Experimentant amb ndots

Experimentem una mica més amb ndots i vegem com es comporta aquest paràmetre. La idea és senzilla: ndots determina si el client DNS tractarà el domini com a absolut o relatiu. Per exemple, en el cas d'un simple client DNS de Google, com sap si aquest domini és absolut? Si estableixes ndots igual a 1, el client dirà: "Oh, en google no hi ha ni un sol punt; Suposo que revisaré tota la llista de cerca". Tanmateix, si demaneu google.com, la llista de sufixos s'ignorarà completament perquè el nom sol·licitat compleix el llindar ndots (hi ha almenys un punt).

Assegurem-nos d'això:

$ 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

Registres de 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

Des de l'any mrkaran no hi ha ni un sol punt, la cerca es va fer a través de tota la llista de sufixos.

Nota: a la pràctica el valor màxim ndots limitat a 15; per defecte a Kubernetes és 5.

Aplicació en producció

Si una aplicació fa moltes trucades a la xarxa externa, el DNS pot convertir-se en un coll d'ampolla en el cas del trànsit actiu, ja que la resolució de noms fa moltes consultes innecessàries (abans que el sistema arribi a la correcta). Normalment, les aplicacions no afegeixen una zona arrel als noms de domini, però això sembla un truc. És a dir, en comptes de preguntar api.twitter.com, podeu "codificar-lo". api.twitter.com. (amb un punt) a l'aplicació, que demanarà als clients DNS que realitzin cerques autoritzades directament al domini absolut.

A més, a partir de la versió 1.14 de Kubernetes, les extensions dnsConfig и dnsPolicy va rebre un estat estable. Així, en desplegar un pod, podeu reduir el valor ndots, per exemple, fins a 3 (i fins i tot fins a 1!). Per això, cada missatge dins d'un node haurà d'incloure el domini complet. Aquesta és una de les compensacions clàssiques quan heu de triar entre rendiment i portabilitat. Em sembla que només us hauríeu de preocupar per això si la latència ultra baixa és vital per a la vostra aplicació, ja que els resultats de DNS també s'emmagatzemen a la memòria cau internament.

Referències

Vaig conèixer aquesta funció per primera vegada Trobada de K8, celebrada el 25 de gener. Hi va haver un debat sobre aquest problema, entre altres coses.

Aquí teniu alguns enllaços per a una exploració més detallada:

• Explicació, per què ndots=5 a Kubernetes;
• Grans coses com el canvi de ndots afecta el rendiment de l'aplicació;
• Discrepàncies entre els solucionadors musl i glibc.

Nota: vaig optar per no utilitzar dig en aquest article. dig afegeix automàticament un punt (identificador de zona arrel), fent que el domini sigui "completament qualificat" (FQDN), no primer executant-lo a través de la llista de cerca. Va escriure sobre això a una de les publicacions anteriors. No obstant això, és força sorprenent que, en general, s'hagi d'especificar una bandera separada per al comportament estàndard.

Feliç DNSing! Et veig després!

PS del traductor

Llegeix també al nostre blog:

• «Calico per al networking a Kubernetes: una introducció i una mica d'experiència»;
• «CoreDNS: servidor DNS per al món natiu del núvol i Service Discovery per a Kubernetes»;
• "Una guia il·lustrada per a les xarxes a Kubernetes": parts 1 i 2 (model de xarxa, xarxes superposades), part 3 (serveis i processament de trànsit).

Font: www.habr.com