Non molto tempo fa abbiamo lanciato Kubernetes 1.9 su AWS utilizzando Kops. Ieri, durante il rollout graduale del nuovo traffico sul più grande dei nostri cluster Kubernetes, ho iniziato a notare errori insoliti nella risoluzione dei nomi DNS registrati dalla nostra applicazione.
Su GitHub se ne è parlato a lungo kube-dns dnsmasq e . La cosa più interessante e nuova per me è stata la causa del significante aumento del traffico delle richieste DNS. Di questo e di cosa fare al riguardo parla il mio post.La risoluzione DNS all'interno di un container — come in qualsiasi sistema Linux — è determinata dal file di configurazione
. Per impostazione predefinita, la /etc/resolv.confdnsPolicy è ClusterFirst , il che significa che qualsiasi richiesta DNS verrà reindirizzata a, eseguito nel pod . La cosa più interessante e nuova per me è stata la causa del significante aumento del traffico delle richieste DNS. Di questo e di cosa fare al riguardo parla il mio post.all'interno del cluster, che a sua volta reindirizzerà la richiesta all'applicazione dnsmasq , se il nome termina con il suffisso del cluster, o, in caso contrario, al server DNS di livello superiore. dnsmasqIl file
all'interno di ogni container per impostazione predefinita apparirà così: /etc/resolv.conf nameserver 100.64.0.10 search namespace.svc.cluster.local svc.cluster.local cluster.local eu-west-1.compute.internal options ndots:5
Come puoi notare, ci sono tre direttive:Il server dei nomi è l'IP del servizio
- Sono specificati 4 domini di ricerca locali
dnsmasq - search
C'è un'opzione - ndots:5
Una parte interessante di questa configurazione è come convivono i domini di ricerca locali e le impostazioni
. Per comprenderlo, è necessario capire come funziona la risoluzione DNS per i nomi incompleti. Una parte interessante di questa configurazione è come convivono i domini di ricerca locali e le impostazioni Che 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 in caso contrario. Cioè
è completamente qualificato, mentre google.com. non lo è. Riconnessione TCP Come viene gestito un nome incompleto?
Quando un'applicazione si connette a un host remoto indicato dal nome, la risoluzione dei nomi DNS viene generalmente eseguita attraverso una chiamata di sistema, ad esempio,
getaddrinfo() . Ma se il nome è incompleto (non termina con .), è interessante osservare se la chiamata di sistema tenterà inizialmente di risolvere il nome come assoluto, o se passerà prima attraverso i domini di ricerca locali? Questo dipende dall'opzionendots Dalla guida su.
resolv.conf resolv.conf:
ndots:n
stabilisce la soglia per il numero di punti che devono apparire nel nome prima che venga effettuata la richiesta assoluta iniziale. Il valore predefinito per n è 1, il che significa che se nel nome ci sono punti, il nome sarà inizialmente provato come nome assoluto prima che vengano aggiunti eventuali elementi della lista di ricerca.Ciò significa che se per Dalla guida su è impostato il valore 5 e il nome contiene meno di 5 punti, la chiamata di sistema tenterà di risolverlo in modo sequenziale, prima attraversando tutti i domini di ricerca locali e, in caso di fallimento, alla fine lo risolverà come nome assoluto.
Perché quindi Una parte interessante di questa configurazione è come convivono i domini di ricerca locali e le impostazioni 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) genererà 5 richieste DNS prima che il nome venga risolto correttamente, poiché prima attraverserà 4 domini di ricerca locali e alla fine emetterà una richiesta per la risoluzione del nome assoluto.
Nella prossima diagramma è mostrato il traffico complessivo sui nostri 3 moduli kube-dns prima e dopo aver cambiato alcuni nomi host configurati nella nostra applicazione in nomi completamente definiti.
Nella prossima diagramma è mostrato il ritardo dell'applicazione prima e dopo aver cambiato alcuni nomi host configurati nella nostra applicazione in nomi completi (la linea blu verticale rappresenta il deployment):
Soluzione #1 — utilizzare nomi completamente definiti
Se avete pochi nomi esterni statici (cioè definiti nella configurazione dell'applicazione), a cui stabilite un gran numero di connessioni, la soluzione più semplice potrebbe essere quella di cambiarli in nomi completamente definiti, aggiungendo semplicemente un punto alla fine.
Non è una soluzione definitiva, ma aiuta a migliorare rapidamente, anche se non in modo pulito, la situazione. Questa patch l'abbiamo applicata per risolvere il nostro problema, i cui risultati sono stati mostrati negli screenshot sopra.
Soluzione #2 — personalizzazione Dalla guida su in dnsConfig
In Kubernetes 1.9 è stata introdotta in alpha una funzionalità (beta v1.10), che consente di controllare meglio i parametri DNS attraverso le proprietà del pod in dnsConfig. Tra le altre cose, consente di impostare il valore Dalla guida su per un singolo pod, cioè.
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 nel nostro blog:
Fonte: habr.com
