Recentemente abbiamo lanciato Kubernetes 1.9 su AWS utilizzando Kops. Ieri, mentre distribuivo senza problemi nuovo traffico al più grande dei nostri cluster Kubernetes, ho iniziato a notare errori insoliti di risoluzione dei nomi DNS registrati dalla nostra applicazione.
C'è parecchio a riguardo su GitHub , quindi ho deciso di capirlo anch'io. Alla fine, mi sono reso conto che nel nostro caso ciò è causato dall'aumento del carico kube-dns и dnsmasq. La cosa più interessante e nuova per me è stata proprio la ragione del significativo aumento del traffico delle richieste DNS. Il mio post riguarda questo e cosa fare al riguardo.
La risoluzione DNS all'interno del contenitore, come in qualsiasi sistema Linux, è determinata dal file di configurazione /etc/resolv.conf. Kubernetes predefinito dnsPolicy essa ClusterFirst, il che significa che qualsiasi richiesta DNS verrà inoltrata a dnsmasq, correndo in un baccello kube-dns all'interno del cluster, che a sua volta inoltrerà la richiesta all'applicazione kube-dns, se il nome termina con un suffisso cluster o, in caso contrario, a un server DNS di livello superiore.
file /etc/resolv.conf all'interno di ciascun contenitore l'impostazione predefinita sarà simile a questa:
nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local
eu-west-1.compute.internal
options ndots:5Come puoi vedere, ci sono tre direttive:
- Il name server è l'IP del servizio
kube-dns - 4 domini di ricerca locale specificati
search - C'è un'opzione
ndots:5
La parte interessante di questa configurazione è il modo in cui i domini e le impostazioni di ricerca locali ndots:5 andare d'accordo insieme. Per capirlo, è necessario capire come funziona la risoluzione DNS per i nomi non qualificati.
Cos'è un nome completo?
Un nome completo è un nome per il quale non verrà eseguita alcuna ricerca locale e il nome verrà considerato assoluto durante la risoluzione del nome. Per convenzione, il software DNS considera un nome pienamente qualificato se termina con un punto (.) e non completamente qualificato altrimenti. Questo è google.com. completamente definito e google.com - no.
Come viene gestito un nome non qualificato?
Quando un'applicazione si connette all'host remoto specificato nel nome, la risoluzione del nome DNS viene generalmente eseguita utilizzando una chiamata di sistema, ad es. getaddrinfo(). Ma se il nome non è qualificato (non termina con .), mi chiedo se la chiamata di sistema proverà prima a risolvere il nome come nome assoluto o passerà prima attraverso i domini di ricerca locale? Dipende dall'opzione ndots.
Dal manuale resolv.conf:
ndots:n
устанавливает порог для количества точек, которые должны появиться в имени, прежде чем будет сделан начальный абсолютный запрос. Значение по умолчанию для n равно 1, что означает, что если в имени есть какие-либо точки, имя будет сначала опробовано как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.Ciò significa che se per ndots dato un valore pari a 5 e il nome contiene meno di 5 punti, la chiamata di sistema tenterà di risolverlo in sequenza, prima attraversando tutti i domini di ricerca locale e, in caso di insuccesso, risolvendolo infine come nome assoluto.
Perché lo stesso ndots:5 potrebbe avere un impatto negativo sulle prestazioni dell'applicazione?
Come puoi immaginare, se la tua applicazione utilizza molto traffico esterno, per ogni connessione TCP stabilita (o più precisamente, per ogni nome risolto), emetterà 5 query DNS prima che il nome venga risolto correttamente, perché prima passerà attraverso 4 dominio di ricerca locale e alla fine emetterà una richiesta di risoluzione assoluta del nome.
Il grafico seguente mostra il traffico totale sui nostri 3 moduli kube-dns prima e dopo aver cambiato i pochi nomi host configurati nella nostra applicazione in nomi pienamente qualificati.
Il seguente diagramma mostra la latenza dell'applicazione prima e dopo aver cambiato diversi nomi host configurati nella nostra applicazione in nomi completi (la linea blu verticale rappresenta la distribuzione):
Soluzione n. 1: utilizzare nomi completi
Se hai pochi nomi esterni statici (cioè definiti nella configurazione dell'applicazione) a cui crei un gran numero di connessioni, forse la soluzione più semplice è trasformarli in nomi completi semplicemente aggiungendoli. alla fine.
Questa non è una soluzione definitiva, ma aiuta a migliorare rapidamente, anche se non in modo netto, la situazione. Abbiamo applicato questa patch per risolvere il nostro problema, i cui risultati sono stati mostrati negli screenshot qui sopra.
Soluzione n. 2: personalizzazione ndots в dnsConfig
In Kubernetes 1.9 è apparsa la funzionalità in modalità alpha (versione beta v1.10), che consente di controllare meglio i parametri DNS tramite la proprietà pod in dnsConfig. Tra le altre cose, consente di configurare il valore ndots per un pod specifico, ad es.
apiVersion: v1
kind: Pod
metadata:
namespace: default
name: dns-example
spec:
containers:
- name: test
image: nginx
dnsConfig:
options:
- name: ndots
value: "1"fonti
Leggi anche altri articoli sul nostro blog:
Fonte: habr.com