Ricerca DNS in Kubernetes

Nota. trad.: Problema DNS in Kubernetes o, più precisamente, impostazione dei parametri ndots, è sorprendentemente popolare, e già non il primo anno. In un'altra nota su questo argomento, il suo autore, un ingegnere DevOps di una grande società di brokeraggio in India, parla in modo molto semplice e conciso di ciò che è utile sapere per i colleghi che utilizzano Kubernetes.

Uno dei principali vantaggi della distribuzione delle applicazioni su Kubernetes è l'individuazione senza interruzioni delle applicazioni. L'interazione intra-cluster è notevolmente semplificata grazie al concetto di servizio (Servizi), che è un IP virtuale che supporta una serie di indirizzi IP pod. Ad esempio, se il servizio vanilla desidera contattare il servizio chocolate, può accedere direttamente all'IP virtuale per chocolate. Sorge la domanda: a chi in questo caso risolverà la richiesta DNS chocolate e come?

La risoluzione dei nomi DNS è configurata su un cluster Kubernetes utilizzando CoreDNS. Kubelet registra un pod con CoreDNS come server dei nomi nei file /etc/resolv.conf tutti i baccelli. Se guardi il contenuto /etc/resolv.conf qualsiasi pod, sarà simile a questo:

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

Questa configurazione viene utilizzata dai client DNS per inoltrare le richieste al server DNS. In archivio resolv.conf contiene le seguenti informazioni:

• server dei nomi: server a cui verranno inviate le richieste DNS. Nel nostro caso si tratta dell'indirizzo del servizio CoreDNS;
• Ricerca: Definisce il percorso di ricerca per un dominio specifico. E' interessante google.com o mrkaran.dev non sono FQDN (nomi di dominio pienamente qualificati). Secondo la convenzione standard seguita dalla maggior parte dei risolutori DNS, solo quelli che terminano con un punto ".", che rappresenta la zona radice, sono considerati domini pienamente qualificati (FDQN). Alcuni risolutori possono aggiungere un punto da soli. Così, mrkaran.dev. è il nome di dominio completo (FQDN) e mrkaran.dev - no;
• ndot: Il parametro più interessante (questo articolo ne parla). ndots specifica il numero soglia di punti in un nome richiesto prima che venga considerato un nome di dominio "completamente qualificato". Ne parleremo più approfonditamente più avanti quando analizzeremo la sequenza di ricerca DNS.

Vediamo cosa succede quando chiediamo mrkaran.dev nel baccello:

$ 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 questo esperimento, ho impostato il livello di registrazione CoreDNS su all (il che lo rende piuttosto prolisso). Diamo un'occhiata ai log del 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

Uff. Due cose attirano la tua attenzione qui:

• La richiesta attraversa tutte le fasi della ricerca finché la risposta non contiene il codice NOERROR (I client DNS lo comprendono e di conseguenza lo memorizzano). NXDOMAIN significa che non è stato trovato alcun record per il nome di dominio specificato. Perché il mrkaran.dev non è un nome FQDN (secondo ndots=5), il risolutore esamina il percorso di ricerca e determina l'ordine delle richieste;
• registrazioni А и АААА arrivano in parallelo. Il fatto è che le richieste una tantum entrano /etc/resolv.conf Per impostazione predefinita, sono configurati in modo tale che le ricerche parallele vengano eseguite utilizzando i protocolli IPv4 e IPv6. Puoi annullare questo comportamento aggiungendo l'opzione single-request в resolv.conf.

Nota: glibc può essere configurato per inviare queste richieste in sequenza e musl - no, quindi gli utenti Alpine dovrebbero prenderne atto.

Sperimentare con i ndots

Sperimentiamo ancora un po' ndots e vediamo come si comporta questo parametro. L'idea è semplice: ndots determina se il client DNS tratterà il dominio come assoluto o relativo. Ad esempio, nel caso di un semplice client DNS di Google, come fa a sapere se questo dominio è assoluto? Se imposti ndots uguale a 1, il cliente dirà: "Oh, in google non c'è un solo punto; Immagino che esaminerò l'intero elenco di ricerca. " Tuttavia, se lo chiedi google.com, l'elenco dei suffissi verrà completamente ignorato perché il nome richiesto soddisfa la soglia ndots (c'è almeno un punto).

Assicuriamoci di questo:

$ 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

Registri 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

Dal in mrkaran non c'è un solo punto, la ricerca è stata effettuata su tutto l'elenco dei suffissi.

Nota: in pratica il valore massimo ndots limitato a 15; per impostazione predefinita in Kubernetes è 5.

Applicazione in produzione

Se un'applicazione effettua molte chiamate alla rete esterna, il DNS può diventare un collo di bottiglia in caso di traffico attivo, poiché la risoluzione dei nomi richiede molte query non necessarie (prima che il sistema arrivi a quella giusta). Le applicazioni di solito non aggiungono una zona root ai nomi di dominio, ma questo sembra un hack. Cioè, invece di chiedere api.twitter.com, puoi "codificarlo". api.twitter.com. (con un punto) nell'applicazione, che richiederà ai client DNS di eseguire ricerche autorevoli direttamente sul dominio assoluto.

Inoltre, a partire dalla versione 1.14 di Kubernetes, le estensioni dnsConfig и dnsPolicy ricevuto uno status stabile. Pertanto, quando distribuisci un pod, puoi ridurre il valore ndots, diciamo, fino a 3 (e anche fino a 1!). Per questo motivo, ogni messaggio all'interno di un nodo dovrà includere l'intero dominio. Questo è uno dei classici compromessi quando devi scegliere tra prestazioni e portabilità. Mi sembra che dovresti preoccuparti di questo solo se una latenza ultra bassa è vitale per la tua applicazione, poiché anche i risultati DNS vengono memorizzati nella cache interna.

riferimenti

Ho appreso per la prima volta di questa funzionalità su Incontro dei K8, tenutasi il 25 gennaio. C'è stata una discussione su questo problema, tra le altre cose.

Ecco alcuni link per ulteriori approfondimenti:

• spiegazione, perché ndots=5 in Kubernetes;
• Roba fantastica in che modo la modifica dei ndot influisce sulle prestazioni dell'applicazione;
• discrepanze tra i risolutori musl e glibc.

Nota: ho scelto di non utilizzare dig in questo articolo. dig aggiunge automaticamente un punto (identificatore della zona root), rendendo il dominio "completamente qualificato" (FQDN), no eseguendo prima l'elenco di ricerca. Ne ho parlato in una delle pubblicazioni precedenti. Tuttavia è abbastanza sorprendente che, in generale, per il comportamento standard debba essere specificato un flag separato.

Buon DNS! Arrivederci!

PS da traduttore

Leggi anche sul nostro blog:

• «Calico per il networking in Kubernetes: introduzione e un po' di esperienza";
• «CoreDNS: server DNS per il mondo cloud nativo e Service Discovery per Kubernetes";
• "Una guida illustrata alla rete in Kubernetes": parti 1 e 2 (modello di rete, reti overlay), parte 3 (servizi ed elaborazione del traffico).

Fonte: habr.com