🥇/etc/resolv.conf per i pod Kubernetes, opzione ndots:5, come può influire negativamente sulle prestazioni dell'applicazione

Non molto tempo fa abbiamo lanciato Kubernetes 1.9 su AWS utilizzando Kops. Ieri, durante un deployment graduale di un nuovo traffico sul nostro più grande cluster Kubernetes, ho iniziato a notare errori insoliti nella risoluzione dei nomi DNS registrati dalla nostra applicazione.

Se ne è parlato a lungo su GitHub quindi ho deciso di approfondire. Alla fine, ho capito che nel nostro caso era causato da un aumento del carico su. La causa più interessante e nuova per me è stata l'enorme aumento del traffico delle richieste DNS. Di questo e di cosa fare a riguardo è il mio post. kube-dns e dnsmasq. Самым интересным и новым для меня оказалась сама причина значительного увеличения трафика DNS-запросов. Об этом и о том, что с этим делать, мой пост.

La risoluzione DNS all'interno del contenitore - così come in qualsiasi sistema Linux - è determinata dal file di configurazione /etc/resolv.conf. Per impostazione predefinita, Kubernetes dnsPolicy questo ClusterFirst, il che significa che qualsiasi richiesta DNS verrà reindirizzata a dnsmasq, in esecuzione in un pod kube-dns all'interno del cluster, che, a sua volta, reindirizzerà la richiesta all'applicazione kube-dns, se il nome termina con il suffisso del cluster, oppure, in caso contrario, al server DNS di livello superiore.

File /etc/resolv.conf All'interno di ogni contenitore, per impostazione predefinita apparirà così:

nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local 
eu-west-1.compute.internal
options ndots:5

Come si può notare, ci sono tre direttive:

Il server dei nomi è l'IP del servizio kube-dns
Sono indicati 4 domini di ricerca locali search
C'è un'opzione ndots:5

Una parte interessante di questa configurazione è come i domini di ricerca locali e le impostazioni ndots:5 coesistano. Per comprendere questo, è necessario capire come funziona la risoluzione DNS per i nomi incompleti.

Cos'è un nome completo?

Un nome completamente qualificato è un nome per il quale non verrà eseguita una ricerca locale e il nome sarà considerato assoluto durante la risoluzione dei nomi. Per convenzione, il software DNS considera un nome completamente qualificato se termina con un punto (.), e non completamente qualificato altrimenti. Vale a dire, google.com. è completamente qualificato, mentre google.com non lo è.

Come viene gestito un nome incompleto?

Quando un'applicazione si connette a un host remoto specificato nel nome, la risoluzione dei nomi DNS di solito avviene tramite una chiamata di sistema, ad esempio, getaddrinfo(). Se il nome non è completo (non finisce con un punto), ci si chiede se la chiamata di sistema tenterà prima di risolvere il nome come assoluto, o passerà prima attraverso i domini di ricerca locali. Questo dipende dall'opzione. ndots.

Dalla documentazione di resolv.conf:

ndots:n

imposta la soglia per il numero di punti che devono comparire nel nome prima che venga effettuata una richiesta assoluta iniziale. Il valore predefinito per n è 1, il che significa che se ci sono dei punti nel nome, esso sarà inizialmente testato come nome assoluto, prima che vengano aggiunti eventuali elementi della lista di ricerca.

Ciò significa che se per ndots è impostato a 5 e il nome contiene meno di 5 punti, la chiamata di sistema tenterà di risolverlo in sequenza, passando prima attraverso tutti i domini di ricerca locali e, se fallisce, alla fine lo risolverà come nome assoluto.

Perché `ndots:5` può influire negativamente sulle prestazioni dell'applicazione?

Come sapete, se la vostra applicazione utilizza molto traffico esterno, per ogni connessione TCP stabilita (o, più precisamente, per ogni nome risolto) verranno effettuate 5 richieste DNS prima che il nome venga risolto correttamente, poiché passerà inizialmente attraverso 4 domini di ricerca locali, per poi emettere una richiesta di risoluzione del nome assoluto.

Nel diagramma seguente è mostrato il traffico totale sui nostri 3 moduli kube-dns prima e dopo aver trasferito alcuni nomi host configurati nella nostra applicazione su nomi completamente qualificati.

Nel diagramma seguente è mostrato il ritardo dell'applicazione prima e dopo aver trasferito alcuni nomi host configurati nella nostra applicazione su nomi completi (la linea blu verticale indica il deploy):

Soluzione #1 — utilizzare nomi completamente qualificati

Se avete pochi nomi esterni statici (cioè definiti nella configurazione dell'applicazione) a cui create molte connessioni, la soluzione più semplice potrebbe essere quella di trasferirli a nomi completamente qualificati semplicemente aggiungendo '.' alla fine.

Non è una soluzione definitiva, ma aiuta a migliorare rapidamente, anche se non perfettamente, la situazione. Questa patch l'abbiamo applicata per risolvere il nostro problema, i cui risultati sono stati mostrati negli screenshot sopra.

Soluzione #2 — personalizzazione `ndots` in `dnsConfig`

In Kubernetes 1.9 è stata introdotta in modalità alpha una funzionalità (versione beta v1.10) che consente di controllare meglio i parametri DNS tramite la proprietà del pod in dnsConfig. Tra le altre cose, permette di configurare il valore ndots per un pod specifico, ovvero.

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsConfig:
    options:
      - name: ndots
        value: "1"