{"id":37372,"date":"2019-10-31T22:17:16","date_gmt":"2019-10-31T19:17:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya\/"},"modified":"2019-10-31T22:17:16","modified_gmt":"2019-10-31T19:17:16","slug":"etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya","title":{"rendered":"\/etc\/resolv.conf \u0434\u043b\u044f Kubernetes pods, \u043e\u043f\u0446\u0438\u044f ndots:5, \u043a\u0430\u043a \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u043d\u0435\u0433\u0430\u0442\u0438\u0432\u043d\u043e \u0441\u043a\u0430\u0437\u0430\u0442\u044c\u0441\u044f \u043d\u0430 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\/etc\/resolv.conf<\/p>\n

<\/p>\n

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\u00f9 grande cluster Kubernetes, ho iniziato a notare errori insoliti nella risoluzione dei nomi DNS registrati dalla nostra applicazione.<\/p>\n

<\/a><\/noindex><\/p>\n

Se ne \u00e8 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<\/a><\/noindex>. La causa pi\u00f9 interessante e nuova per me \u00e8 stata l'enorme aumento del traffico delle richieste DNS. Di questo e di cosa fare a riguardo \u00e8 il mio post. kube-dns<\/code> e dnsmasq<\/code>. \u0421\u0430\u043c\u044b\u043c \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c \u0438 \u043d\u043e\u0432\u044b\u043c \u0434\u043b\u044f \u043c\u0435\u043d\u044f \u043e\u043a\u0430\u0437\u0430\u043b\u0430\u0441\u044c \u0441\u0430\u043c\u0430 \u043f\u0440\u0438\u0447\u0438\u043d\u0430 \u0437\u043d\u0430\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0433\u043e \u0443\u0432\u0435\u043b\u0438\u0447\u0435\u043d\u0438\u044f \u0442\u0440\u0430\u0444\u0438\u043a\u0430 DNS-\u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432. \u041e\u0431 \u044d\u0442\u043e\u043c \u0438 \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u0441 \u044d\u0442\u0438\u043c \u0434\u0435\u043b\u0430\u0442\u044c, \u043c\u043e\u0439 \u043f\u043e\u0441\u0442.<\/p>\n

<\/p>\n

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

<\/p>\n

File \/etc\/resolv.conf<\/code> All'interno di ogni contenitore, per impostazione predefinita apparir\u00e0 cos\u00ec:<\/p>\n

<\/p>\n

nameserver 100.64.0.10\nsearch namespace.svc.cluster.local svc.cluster.local cluster.local \neu-west-1.compute.internal\noptions ndots:5<\/code><\/pre>\n
<\/p>\n
Come si pu\u00f2 notare, ci sono tre direttive:<\/p>\n
<\/p>\n
    \n
  1. Il server dei nomi \u00e8 l'IP del servizio kube-dns<\/code><\/li>\n
  2. Sono indicati 4 domini di ricerca locali search<\/code><\/li>\n
  3. C'\u00e8 un'opzione ndots:5<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    Una parte interessante di questa configurazione \u00e8 come i domini di ricerca locali e le impostazioni ndots:5<\/code> coesistano. Per comprendere questo, \u00e8 necessario capire come funziona la risoluzione DNS per i nomi incompleti.<\/p>\n
    <\/p>\n
    Cos'\u00e8 un nome completo?<\/h3>\n
    <\/p>\n
    Un nome completamente qualificato \u00e8 un nome per il quale non verr\u00e0 eseguita una ricerca locale e il nome sar\u00e0 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.<\/code> \u00e8 completamente qualificato, mentre google.com<\/code> non lo \u00e8. <\/p>\n
    <\/p>\n
    Come viene gestito un nome incompleto?<\/h3>\n
    <\/p>\n
    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()<\/code>. Se il nome non \u00e8 completo (non finisce con un punto), ci si chiede se la chiamata di sistema tenter\u00e0 prima di risolvere il nome come assoluto, o passer\u00e0 prima attraverso i domini di ricerca locali. Questo dipende dall'opzione. ndots<\/code>.<\/p>\n
    <\/p>\n
    Dalla documentazione di resolv.conf<\/code>:<\/p>\n
    <\/p>\n
    ndots:n\n\nimposta 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 \u00e8 1, il che significa che se ci sono dei punti nel nome, esso sar\u00e0 inizialmente testato come nome assoluto, prima che vengano aggiunti eventuali elementi della lista di ricerca.<\/code><\/pre>\n
    <\/p>\n
    Ci\u00f2 significa che se per ndots<\/code> \u00e8 impostato a 5 e il nome contiene meno di 5 punti, la chiamata di sistema tenter\u00e0 di risolverlo in sequenza, passando prima attraverso tutti i domini di ricerca locali e, se fallisce, alla fine lo risolver\u00e0 come nome assoluto.<\/p>\n
    <\/p>\n
    Perch\u00e9 ndots:5<\/code> pu\u00f2 influire negativamente sulle prestazioni dell'applicazione?<\/h3>\n
    <\/p>\n
    Come sapete, se la vostra applicazione utilizza molto traffico esterno, per ogni connessione TCP stabilita (o, pi\u00f9 precisamente, per ogni nome risolto) verranno effettuate 5 richieste DNS prima che il nome venga risolto correttamente, poich\u00e9 passer\u00e0 inizialmente attraverso 4 domini di ricerca locali, per poi emettere una richiesta di risoluzione del nome assoluto.<\/p>\n
    <\/p>\n
    Nel diagramma seguente \u00e8 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.<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    Nel diagramma seguente \u00e8 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):<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    Soluzione #1 \u2014 utilizzare nomi completamente qualificati<\/h3>\n
    <\/p>\n
    Se avete pochi nomi esterni statici (cio\u00e8 definiti nella configurazione dell'applicazione) a cui create molte connessioni, la soluzione pi\u00f9 semplice potrebbe essere quella di trasferirli a nomi completamente qualificati semplicemente aggiungendo '.' alla fine.<\/p>\n
    <\/p>\n
    Non \u00e8 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.<\/p>\n
    <\/p>\n
    Soluzione #2 \u2014 personalizzazione ndots<\/code> in dnsConfig<\/code><\/h3>\n
    <\/p>\n
    In Kubernetes 1.9 \u00e8 stata introdotta in modalit\u00e0 alpha una funzionalit\u00e0 (versione beta v1.10) che consente di controllare meglio i parametri DNS tramite la propriet\u00e0 del pod in dnsConfig<\/code>. Tra le altre cose, permette di configurare il valore ndots<\/code> per un pod specifico, ovvero.<\/p>\n
    <\/p>\n
    apiVersion: v1\nkind: Pod\nmetadata:\n  namespace: default\n  name: dns-example\nspec:\n  containers:\n    - name: test\n      image: nginx\n  dnsConfig:\n    options:\n      - name: ndots\n        value: \"1\"<\/code><\/pre>\n
    <\/p>\n
    Fonti<\/h3>\n
    <\/p>\n