Quando il DNS del container diventa un collo di bottiglia per il server domestico?

Il DNS dei container diventa un collo di bottiglia per il server domestico quando la latenza di ricerca, la moltiplicazione delle query o il fallimento del resolver consumano più tempo della richiesta del servizio locale stessa.

I container spesso risolvono i nomi dei servizi tramite un proxy DNS incorporato prima che le query raggiungano un resolver host o upstream. Questo percorso aggiuntivo è normalmente veloce. Diventa evidente quando le applicazioni aprono molte connessioni brevi, i domini di ricerca generano varianti fallite, la cache è debole o un resolver locale serve ogni container e dispositivo domestico.

Il Container Aggiunge un Percorso di Resolver per il Service-Discovery

Su una rete definita dall’utente, un resolver incorporato può mappare nomi e alias dei container, quindi inoltrare i nomi sconosciuti a un resolver upstream. Una guida al DNS incorporato di Docker traccia questa decisione tra locale e inoltrato. Il design permette ai servizi di spostarsi senza indirizzi IP hard-coded, ma rende anche la risoluzione dei nomi parte di ogni configurazione di connessione non in cache.

Host e container possono quindi mostrare risultati diversi. L’host può interrogare direttamente il suo resolver mentre il container passa attraverso il proxy di runtime, un bridge e impostazioni di resolver ereditate. Testare solo l’host può far perdere di vista lo strato lento.

I Domini di Ricerca Possono Trasformare Un Nome in Diverse Query

Un nome breve come database può essere testato con uno o più suffissi di ricerca prima che il resolver lo tenti come nome assoluto. La regola ndots influisce su quell’ordine. Impostazioni di ricerca errate o troppo ampie possono creare diverse query negative per ogni risultato positivo.

La guida alla risoluzione dei problemi DNS dei container di Netdata identifica ndots e domini di ricerca come cause di avvii lenti e lookup bloccanti. Questo è un rischio dipendente dalla configurazione, non un motivo per imporre un valore ndots unico in ogni ambiente.

Le Connessioni Brevi Moltiplicano il Costo della Ricerca

Un’app che riutilizza una connessione database o HTTP risolve il nome meno spesso. Un health checker, un worker o un client con pool mal gestito può creare una nuova connessione per ogni attività. Anche un ritardo DNS modesto si ripete quindi più volte nel percorso critico.

Un vero caso DNS container-versus-host mostra lookup di diversi secondi nel container mentre le query host restavano veloci. Un report sulla latenza DNS incorporata registra lo stesso contrasto diagnostico, rendendolo un utile primo passo prima di incolpare l’applicazione.

La Cache Aiuta Solo Entro il Suo TTL e Ambito

La cache DNS memorizza una risposta finché il suo time to live non scade, riducendo il volume di query e il ritardo di avvio. La spiegazione della cache DNS descrive come le risposte in cache riducono il lavoro di rete, ma runtime dei container, applicazioni e resolver locali possono avere comportamenti di cache diversi.

Una cache non è una cura universale. TTL molto brevi, record di servizio che cambiano frequentemente, lookup negativi e comportamento del resolver per processo possono mantenere alto il tasso di query. Una cache locale fallita o sovraccarica diventa inoltre una dipendenza condivisa per ogni servizio che vi fa riferimento.

Il DNS è il Collo di Bottiglia Solo Prima che la Connessione Inizi

Misura il tempo di lookup separatamente da TCP connect, negoziazione TLS, primo byte e risposta dell’applicazione. Se la risoluzione del nome è veloce ma la richiesta è lenta, cambiare resolver non risolverà il servizio. Se l’accesso IP diretto è veloce e l’accesso con nome si blocca, ispeziona il percorso del resolver del container e la sequenza delle query.

Un’analisi della latenza DNS per server domestici stabilisce questo confine temporale. La sua spiegazione della latenza dei bridge virtuali aiuta a separare il DNS dal percorso dei pacchetti che segue la risoluzione.

FAQ

Perché il DNS è veloce sull’host ma lento dentro un container?

Il container può usare un resolver incorporato, domini di ricerca diversi, server DNS ereditati o uno namespace di rete separato. Confronta i file del resolver e le query temporizzate da entrambe le posizioni.

I container dovrebbero usare DNS pubblici per i nomi di servizio locali?

No. I resolver pubblici non conoscono gli alias privati dei container. Usa il service discovery del runtime o un resolver locale autorevole, con inoltro affidabile per i nomi esterni.

La cache DNS può compromettere il service discovery dei container?

Risposte obsolete possono ritardare il riconoscimento di un indirizzo di servizio cambiato fino alla scadenza del TTL. La politica di cache deve bilanciare la riduzione delle query con la rapidità con cui l’ambiente cambia.