🥇Ricerca DNS in Kubernetes

Nota di traduzione.: Problema DNS in Kubernetes, e più precisamente — configurazione del parametro Dalla guida su, — sorprendentemente popolare, e già non è la prima anno. In un altro articolo su questo argomento, l'autore — un ingegnere DevOps di una grande società di brokeraggio in India — spiegano in modo piuttosto semplice e conciso cosa sia utile sapere ai colleghi che operano con Kubernetes.

Uno dei principali vantaggi della distribuzione delle applicazioni in Kubernetes è il rilevamento delle applicazioni senza problemi. L'interazione intra-cluster è notevolmente semplificata grazie al concetto di servizio (Servizio), che rappresenta un IP virtuale che supporta un insieme di indirizzi IP dei pod. Ad esempio, se il servizio vanilla vuole comunicare con il servizio chocolate, può accedere direttamente all'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 scrive il pod con CoreDNS come server dei nomi nei file /etc/resolv.conf di tutti i pod. Se guardiamo il contenuto di /etc/resolv.conf qualsiasi pod, sarà simile al seguente:

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 reindirizzare le richieste al server DNS. Nel file resolv.conf è presente la seguente informazione:

nameserver: server a cui saranno indirizzate le richieste DNS. Nel nostro caso si tratta dell'indirizzo del servizio CoreDNS;
C'è un'opzione: definisce il percorso di ricerca per un dominio specifico. Curiosamente, Riconnessione TCP o mrkaran.dev non sono FQDN (nomi di dominio completi). Secondo la convenzione standard seguita dalla maggior parte dei resolver DNS, i domini completi (FQDN) sono solo quelli che terminano con un punto «.», che rappresenta la zona radice. Alcuni resolver possono aggiungere il punto automaticamente. Pertanto, mrkaran.dev. è un nome di dominio completo (FQDN), mentre mrkaran.dev non lo è;
Dalla guida su: il parametro più interessante (di cui questa articolo parla). Dalla guida su determina il numero soglia di punti nel nome della richiesta, raggiunto il quale viene considerato come nome di dominio 'completo'. Ne parleremo in dettaglio 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 registrazione di CoreDNS su all (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

Fiu. Ci sono due cose qui che attirano l'attenzione:

La richiesta passa attraverso tutte le fasi di ricerca fino a quando la risposta non contiene il codice NOERROR (i client DNS lo comprendono e lo memorizzano come risultato). NXDOMAIN significa che non è stata trovata una registrazione per questo nome di dominio. Poiché mrkaran.dev non è un nome FQDN (secondo ndots=5), il resolver esamina il percorso di ricerca e determina l'ordine delle richieste;
Le registrazioni A e AAAA vengono elaborate in parallelo. Il punto è che le richieste uniche in /etc/resolv.conf sono configurate per cercare parallelamente nei protocolli IPv4 e IPv6 per impostazione predefinita. È possibile annullare questo comportamento aggiungendo l'opzione single-request in resolv.conf.

Nota: glibc che può essere impostata per inviare queste richieste in modo sequenziale, mentre musl non lo è, quindi gli utenti di Alpine devono tenerne conto.

Sperimentiamo con ndots

Facciamo ancora un po' di esperimenti con Dalla guida su e vediamo come si comporta questo parametro. L'idea è semplice: Dalla guida su determina se il client DNS considera il dominio assoluto o relativo. Ad esempio, come nel caso del semplice google, come fa il client DNS a sapere se questo dominio è assoluto? Se si imposta Dalla guida su uguale a 1, il client dirà: "Oh, in google non ci sono punti; suppongo che controllerò l'intera lista di ricerca." Tuttavia, se si richiede Riconnessione TCP, l'elenco dei suffissi sarà completamente ignorato, poiché il nome richiesto supera la soglia Dalla guida su (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 ci sono punti, la ricerca è stata effettuata su tutta la lista dei suffissi.

Nota: nella pratica, il valore massimo Dalla guida su è limitato a 15; per impostazione predefinita in Kubernetes è 5.

Applicazione in production

Se l'applicazione effettua molte chiamate di rete esterne, il DNS può diventare un collo di bottiglia in caso di traffico attivo, poiché durante la risoluzione del nome vengono effettuate molte richieste superflue (prima che il sistema arrivi a quello giusto). Le applicazioni di solito non aggiungono la zona root ai nomi di dominio, ma questo è decisamente un hack. Cioè, invece di richiedere api.twitter.com, puoi 'hardcodare' api.twitter.com. (con il punto) nell'applicazione, il che incoraggerà i client DNS a eseguire una ricerca autorevole direttamente nel dominio assoluto.

Inoltre, a partire dalla versione 1.14 di Kubernetes, le estensioni dnsConfig e è hanno ottenuto lo stato di stabili. Pertanto, durante il deployment di un pod, è possibile ridurre il valore Dalla guida su, ad esempio, a 3 (e persino a 1!). A causa di ciò, ogni messaggio all'interno del nodo dovrà includere il dominio completo. Questo è uno dei classici compromessi quando si deve scegliere tra prestazioni e portabilità. Penso che valga la pena preoccuparsi di questo solo se ritardi super ridotti sono vitali per la tua applicazione, poiché i risultati DNS vengono anche memorizzati nella cache internamente.

Link

Ho sentito parlare di questa caratteristica per la prima volta al K8s-meetup, tenutasi il 25 gennaio. Si è parlato, tra l'altro, anche di questo problema.

Ecco alcuni link per ulteriori approfondimenti:

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

Nota: Ho preferito non utilizzare dig in questo articolo. dig aggiunge automaticamente un punto (identificatore della zona root), rendendo il dominio 'completo' (FQDN), non passandolo prima attraverso l'elenco di ricerca. Ho scritto di questo in uno dei precedenti post. Tuttavia, è piuttosto sorprendente che, in generale, per il comportamento standard sia necessario impostare un flag separato.

Buon DNS-ing! A presto!

Ricerca DNS in Kubernetes

Sperimentiamo con ndots

Applicazione in production

Link

P.S. dal traduttore