🥇Cerca DNS in Kubernetes

Nota del traduttore.: Problema DNS in Kubernetes, ossia la configurazione del parametro ndots, — sorprendentemente popolare, e già non è la prima anno. In un ulteriore articolo su questo tema, l'autore — un ingegnere DevOps di una grande azienda di intermediazione in India — spiega in modo molto semplice e conciso cosa è utile sapere per i colleghi che operano con Kubernetes.

Uno dei principali vantaggi della distribuzione delle applicazioni in Kubernetes è la scoperta senza problemi delle applicazioni. L'interazione intra-cluster è notevolmente semplificata grazie al concetto di servizio (Service), che rappresenta un IP virtuale che supporta un insieme di indirizzi IP dei pod. Ad esempio, se il servizio vanilla desidera connettersi con il servizio chocolate, può contattare direttamente l'IP virtuale per chocolate. Si pone la domanda: chi risolverà la richiesta DNS a chocolate e come?

La risoluzione dei nomi DNS è configurata nel cluster Kubernetes tramite CoreDNS. Kubelet registra il pod con CoreDNS come server dei nomi nei file /etc/resolv.conf di tutti i pod. Se si guarda al contenuto di /etc/resolv.conf qualsiasi pod, apparirà più o meno come segue:

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

Questa configurazione è utilizzata dai client DNS per indirizzare le richieste al server DNS. Nel file resolv.conf è presente la seguente informazione:

nameserver: server a cui verranno inviate le richieste DNS. Nel nostro caso è l'indirizzo del servizio CoreDNS;
cerca: definisce il percorso di ricerca per un dominio specifico. Curiosamente, google.com o mrkaran.dev non è un FQDN (nomi di dominio completamente qualificati). Secondo la convenzione standard seguita dalla maggior parte dei resolver DNS, i domini completi (FDQN) sono solo quelli che terminano con un punto «.», che rappresenta la zona radice. Alcuni resolver possono aggiungere il punto automaticamente. Quindi, mrkaran.dev. è un nome di dominio completo (FQDN), mentre mrkaran.dev non lo è;
ndots: l'opzione più interessante (di cui parla questo articolo). ndots definisce il numero soglia di punti nel nome della richiesta, oltre il quale viene considerato come un "nome di dominio completo". Discuteremo di più su questo più tardi, quando analizzeremo la sequenza di ricerca DNS.

Vediamo cosa succede quando richiediamo mrkaran.dev in un pod:

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Risposta non autorevole:
Nome: mrkaran.dev
Indirizzo: 157.230.35.153
Nome: mrkaran.dev
Indirizzo: 2400:6180:0:d1::519:6001

Per questo esperimento, ho impostato il livello di logging di CoreDNS su all (il che lo rende piuttosto verboso). 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. Ci sono due cose che attirano l'attenzione qui:

La richiesta passa attraverso tutte le fasi della ricerca fino a quando la risposta non contiene il codice NOERROR (i client DNS lo interpretano e lo conservano come risultato). NXDOMAIN indica che per questo nome di dominio non è stata trovata alcuna registrazione. Poiché mrkaran.dev non è un nome FQDN (secondo ndots=5), il resolver guarda il percorso di ricerca e determina l'ordine delle richieste;
Le registrazioni E e AAAA arrivano in parallelo. Infatti, le richieste singole in /etc/resolv.conf sono impostate di default per effettuare ricerche parallele sia su IPv4 che su IPv6. È possibile annullare questo comportamento aggiungendo l'opzione single-request in resolv.conf.

Nota: glibc che può essere configurata per inviare queste richieste in sequenza, mentre musl non lo è, quindi gli utenti di Alpine dovrebbero tenerne conto.

Sperimentiamo con ndots

Facciamo un po' di esperimenti con ndots e vediamo come si comporta questo parametro. L'idea è semplice: ndots determina se il client DNS considera il dominio assoluto o relativo. Ad esempio, come nel caso semplice di google, come fa il client DNS a sapere se questo dominio è assoluto? Se impostato ndots su 1, il client dirà: «Oh, in google non c'è alcun punto; forse controllerò l'intero elenco di ricerca». Tuttavia, se si richiede google.com, l'elenco dei suffissi verrà interamente ignorato, poiché 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

** il server non riesce a trovare mrkaran: NXDOMAIN

Log di 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

Poiché in mrkaran non ha alcun punto, la ricerca è stata effettuata su tutto l'elenco dei suffissi.

Nota: nella pratica, il valore massimo ndots è limitato a 15; di default in Kubernetes è impostato su 5.

Applicazione in produzione

Se un'applicazione effettua numerose chiamate di rete esterne, il DNS potrebbe diventare un collo di bottiglia in presenza di un traffico intenso, poiché durante la risoluzione del nome vengono eseguite molte richieste superflue (prima che il sistema arrivi al risultato desiderato). Le applicazioni normalmente non aggiungono la zona radice ai nomi di dominio, ma ciò è considerato un workaround. Quindi, invece di interrogare api.twitter.com, puoi 'hardcodare' api.twitter.com. (con il punto) nell'applicazione, il che costringerà i client DNS a eseguire una ricerca autoritativa direttamente nel dominio assoluto.

Inoltre, a partire dalla versione 1.14 di Kubernetes, le estensioni dnsConfig e dnsPolicy hanno raggiunto lo stato di stabilità. Pertanto, durante il deployment di un pod, si può ridurre il valore ndots, diciamo, a 3 (o anche a 1!). A causa di ciò, ogni messaggio all'interno del nodo dovrà includere il dominio completo. Questo è uno dei compromessi classici quando si deve scegliere tra prestazioni e portabilità. Penso che valga la pena preoccuparsi solo nel caso in cui latenze estremamente basse siano cruciali per la tua applicazione, poiché i risultati DNS vengono anche memorizzati nella cache.

Link

Ho appreso per la prima volta di questa caratteristica durante il K8s-meetup, tenutosi il 25 gennaio. Si è parlato, tra l'altro, di questo problema.

Ecco alcuni link per ulteriori approfondimenti:

Spiegazione, perché ndots=5 in Kubernetes;
Un ottimo materiale su come la modifica di ndots influisce sulle prestazioni dell'applicazione;
Discrepanze tra i resolver musl e glibc.

Nota: Ho preferito non utilizzare dig in questo articolo. dig aggiunge automaticamente un punto (identificatore della zona radice), rendendo il dominio 'completo' (FQDN), non passandolo prima attraverso la lista di ricerca. Ne ho scritto in uno dei miei precedenti articoli. Tuttavia, è piuttosto sorprendente che, in generale, per il comportamento standard sia necessario impostare un flag specifico.

Buon DNS-ing! A presto!