Configurare NodeLocal DNSCache

Autopilot Standard

Questo documento descrive come utilizzare NodeLocal DNSCache per ridurre la latenza di ricerca DNS e migliorare le prestazioni dell'applicazione nel cluster Google Kubernetes Engine (GKE).

NodeLocal DNSCache è un componente aggiuntivo di GKE che migliora le prestazioni del DNS eseguendo una cache DNS direttamente su ogni nodo cluster come DaemonSet. Quando i pod effettuano una richiesta DNS, la richiesta viene inviata prima alla cache locale sullo stesso nodo. La gestione locale delle richieste riduce significativamente i tempi medi di ricerca DNS e diminuisce il carico sul provider DNS centrale del cluster, ad esempio kube-dns o Cloud DNS per GKE. Per una spiegazione dettagliata dell'architettura DNS e dei vantaggi di NodeLocal DNSCache, consulta Informazioni sul rilevamento dei servizi.

Nei cluster GKE Autopilot, NodeLocal DNSCache è abilitato per impostazione predefinita e non puoi disabilitarlo. Nei cluster GKE Standard che eseguono la versione 1.33.1 e successive, NodeLocal DNSCache è abilitato per impostazione predefinita, ma puoi disabilitarlo.

Questo documento è rivolto agli utenti di GKE, inclusi sviluppatori, amministratori e architetti. Per saperne di più sui ruoli comuni e sulle attività di esempio in Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Questo documento presuppone che tu abbia familiarità con quanto segue:

• Servizio Kubernetes.
• Multi-cluster Services.
• Informazioni sul service discovery.
• Informazioni su Cloud DNS.

Architettura

NodeLocal DNSCache è un componente aggiuntivo di GKE che puoi eseguire in aggiunta a kube-dns.

GKE implementa NodeLocal DNSCache come DaemonSet che esegue una cache DNS su ogni nodo del cluster.

Quando un pod effettua una richiesta DNS, la richiesta viene inviata alla cache DNS in esecuzione sullo stesso nodo del pod. Se la cache non riesce a risolvere la richiesta DNS, la inoltra a una delle seguenti posizioni, in base alla destinazione della query:

• kube-dns: tutte le query per il dominio DNS del cluster (cluster.local) vengono inoltrate a kube-dns. I pod node-local-dns utilizzano il servizio kube-dns-upstream per accedere ai pod kube-dns.
• Domini stub personalizzati o server dei nomi upstream: le query vengono inoltrate direttamente dai pod NodeLocal DNSCache.
• Cloud DNS: tutte le altre query vengono inoltrate al server di metadati locale in esecuzione sullo stesso nodo da cui ha avuto origine la query. Il server di metadati locale accede a Cloud DNS.

Quando abiliti NodeLocal DNSCache su un cluster esistente, GKE ricrea tutti i nodi del cluster che eseguono GKE versione 1.15 e successive in base alla procedura di upgrade dei nodi.

Dopo che GKE ricrea i nodi, aggiunge automaticamente <x0A>l'etichetta addon.gke.io/node-local-dns-ds-ready=true ai nodi. Non devi aggiungere manualmente questa etichetta ai nodi del cluster.

Vantaggi di NodeLocal DNSCache

NodeLocal DNSCache offre i seguenti vantaggi:

• Riduzione del tempo medio di ricerca DNS
• Le connessioni dai pod alla cache locale non creano voci nella tabella conntrack. Questo comportamento impedisce le connessioni interrotte e rifiutate causate dall'esaurimento della tabella conntrack e dalle condizioni di competizione.
• Puoi utilizzare NodeLocal DNSCache con Cloud DNS per GKE.
• Le query DNS per URL esterni (URL che non fanno riferimento a risorse del cluster) vengono inoltrate direttamente al server di metadati locale e ignorano kube-dns.
• Le cache DNS locali rilevano automaticamente i domini stub e i server dei nomi upstream specificati nella sezione Aggiunta di resolver personalizzati per i domini stub.

Requisiti e limitazioni

• NodeLocal DNSCache consuma risorse di calcolo su ogni nodo del cluster.
• NodeLocal DNSCache non è supportato con i node pool Windows Server.
• NodeLocal DNSCache richiede GKE versione 1.15 o successive.
• NodeLocal DNSCache accede ai pod kube-dns utilizzando TCP.
• NodeLocal DNSCache accede a upstreamServers e stubDomains utilizzando TCP e UDP nelle versioni di GKE 1.18 o successive. Il server DNS deve essere raggiungibile tramite TCP e UDP.
• I record DNS vengono memorizzati nella cache per i seguenti periodi:
  • Il durata (TTL) del record o 30 secondi se il TTL è superiore a 30 secondi.
  • 5 secondi se la risposta DNS è NXDOMAIN.
• I pod NodeLocal DNSCache sono in ascolto sulle porte 53, 9253, 9353 e 8080 sui nodi. Se esegui altri pod hostNetwork o configuri un hostPorts con queste porte, NodeLocal DNSCache non funziona e si verificano errori DNS. I pod NodeLocal DNSCache non utilizzano la modalità hostNetwork quando utilizzano GKE Dataplane V2 e non utilizzano Cloud DNS per GKE.
• La cache DNS locale viene eseguita solo sui node pool che eseguono GKE versioni 1.15 e successive. Se abiliti NodeLocal DNSCache in un cluster con nodi che eseguono versioni precedenti, i pod su questi nodi utilizzano kube-dns.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare la proprietà compute/region. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

• Assicurati di avere un cluster Autopilot o Standard esistente. Se ne hai bisogno, crea un cluster Autopilot. Per i cluster Autopilot, NodeLocal DNSCache è abilitato per impostazione predefinita e non può essere sostituito.

Abilita NodeLocal DNSCache

Per i cluster Standard, puoi abilitare NodeLocal DNSCache utilizzando Google Cloud CLI o la console Google Cloud .

gcloud

Per abilitare NodeLocal DNSCache in un cluster esistente, utilizza il flag --update-addons con l'argomento NodeLocalDNS=ENABLED:

gcloud container clusters update CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --update-addons=NodeLocalDNS=ENABLED

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del tuo cluster.
• COMPUTE_LOCATION: la posizione di Compute Engine per il cluster.

Console

Per abilitare NodeLocal DNSCache su un nuovo cluster:

1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud .

   Vai ai cluster Kubernetes

2. Fai clic sul nome del cluster da modificare.

3. In Networking, nel campo Provider DNS, fai clic su Modifica provider DNS.

4. Seleziona la casella di controllo Abilita NodeLocal DNSCache.

5. Fai clic su Salva modifiche.

Questa modifica richiede la ricreazione dei nodi, il che può causare interruzioni ai carichi di lavoro in esecuzione. Per informazioni dettagliate su questa modifica specifica, individua la riga corrispondente nella tabella Modifiche manuali che ricreano i nodi utilizzando una strategia di upgrade dei nodi e rispettando le norme di manutenzione. Per saperne di più sugli aggiornamenti dei nodi, consulta Pianificare le interruzioni dell'aggiornamento dei nodi.

Importante: GKE rispetta le norme di manutenzione durante la ricreazione dei nodi per questa modifica utilizzando la strategia di upgrade dei nodi e dipende dalla disponibilità delle risorse. La disattivazione degli upgrade automatici dei nodi non impedisce questa modifica. Per applicare manualmente le modifiche ai nodi, utilizza gcloud CLI per chiamare il comando gcloud container clusters upgrade, passando il flag --cluster-version con la stessa versione di GKE già in esecuzione nel pool di nodi.

Verifica che NodeLocal DNSCache sia abilitato

Puoi verificare che NodeLocal DNSCache sia in esecuzione elencando i pod node-local-dns:

kubectl get pods -n kube-system -o wide | grep node-local-dns

L'output è simile al seguente:

node-local-dns-869mt    1/1   Running   0   6m24s   10.128.0.35   gke-test-pool-69efb6b8-5d7m   <none>   <none>
node-local-dns-htx4w    1/1   Running   0   6m24s   10.128.0.36   gke-test-pool-69efb6b8-wssk   <none>   <none>
node-local-dns-v5njk    1/1   Running   0   6m24s   10.128.0.33   gke-test-pool-69efb6b8-bhz3   <none>   <none>

L'output mostra un pod node-local-dns per ogni nodo che esegue GKE versione 1.15 o successive.

Disabilita NodeLocal DNSCache

Puoi disattivare NodeLocal DNSCache utilizzando il seguente comando:

gcloud container clusters update CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --update-addons=NodeLocalDNS=DISABLED

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del cluster da disattivare.
• COMPUTE_LOCATION: la posizione di Compute Engine per il cluster.

Questa modifica richiede la ricreazione dei nodi, il che può causare interruzioni ai carichi di lavoro in esecuzione. Per informazioni dettagliate su questa modifica specifica, individua la riga corrispondente nella tabella Modifiche manuali che ricreano i nodi utilizzando una strategia di upgrade dei nodi e rispettando le norme di manutenzione. Per saperne di più sugli aggiornamenti dei nodi, consulta Pianificare le interruzioni dell'aggiornamento dei nodi.

Importante: GKE rispetta le norme di manutenzione durante la ricreazione dei nodi per questa modifica utilizzando la strategia di upgrade dei nodi e dipende dalla disponibilità delle risorse. La disattivazione degli upgrade automatici dei nodi non impedisce questa modifica. Per applicare manualmente le modifiche ai nodi, utilizza gcloud CLI per chiamare il comando gcloud container clusters upgrade, passando il flag --cluster-version con la stessa versione di GKE già in esecuzione nel pool di nodi.

Risolvi i problemi di NodeLocal DNSCache

Per informazioni generali sulla diagnosi dei problemi DNS di Kubernetes, consulta la pagina Debug della risoluzione DNS.

NodeLocal DNSCache non è abilitato immediatamente

Quando abiliti NodeLocal DNSCache su un cluster esistente, GKE potrebbe non aggiornare immediatamente i nodi se il cluster ha una finestra o un'esclusione di manutenzione configurata. Per maggiori informazioni, consulta Avvertenze per la ricreazione dei nodi e i periodi di manutenzione.

Se preferisci non aspettare, puoi applicare manualmente le modifiche ai nodi chiamando il comando gcloud container clusters upgrade e passando il flag --cluster-version con la stessa versione GKE già in esecuzione nel pool di nodi. Per questa soluzione alternativa devi utilizzare Google Cloud CLI.

NodeLocal DNSCache con Cloud DNS

Se utilizzi NodeLocal DNSCache con Cloud DNS, il cluster utilizza l'indirizzo IP del server dei nomi 169.254.20.10, come mostrato nel seguente diagramma:

Di conseguenza, l'indirizzo IP del servizio kube-dns potrebbe essere diverso dall'indirizzo IP del server dei nomi utilizzato dai pod. Questa differenza negli indirizzi IP è prevista, perché l'indirizzo IP del server dei nomi 169.254.20.10 è necessario per il corretto funzionamento di Cloud DNS.

Per controllare gli indirizzi IP, esegui questi comandi:

1. Visualizza l'indirizzo IP del servizio kube-dns:

   kubectl get svc -n kube-system kube-dns -o jsonpath="{.spec.clusterIP}"
   

   L'output è l'indirizzo IP di kube-dns, ad esempio 10.0.0.10

2. Apri una sessione shell nel pod:

   kubectl exec -it POD_NAME -- /bin/bash
   

3. Nella sessione della shell del pod, leggi i contenuti del file /etc/resolv.conf:

   cat /etc/resolv.conf
   

   L'output è 169.254.20.10

Policy di rete con NodeLocal DNSCache

Se utilizzi i criteri di rete con NodeLocal DNSCache e non utilizzi Cloud DNS o GKE Dataplane V2, devi configurare le regole per consentire ai tuoi carichi di lavoro e ai pod node-local-dns di inviare query DNS.

Utilizza una regola ipBlock nel manifest per consentire la comunicazione tra i tuoi pod e kube-dns.

Il seguente manifest descrive un criterio di rete che utilizza una regola ipBlock:

spec:
  egress:
  - ports:
    - port: 53
      protocol: TCP
    - port: 53
      protocol: UDP
    to:
    - ipBlock:
        cidr: KUBE_DNS_SVC_CLUSTER_IP/32
  podSelector: {}
  policyTypes:
    - Egress

Sostituisci KUBE_DNS_SVC_CLUSTER_IP con l'indirizzo IP del servizio kube-dns. Puoi ottenere l'indirizzo IP del servizio kube-dns utilizzando il seguente comando:

kubectl get svc -n kube-system kube-dns -o jsonpath="{.spec.clusterIP}"

Problemi noti

Questa sezione elenca i problemi noti di NodeLocal DNSCache.

Timeout DNS in dnsPolicy ClusterFirstWithHostNet quando si utilizzano NodeLocal DNSCache e GKE Dataplane V2

Nei cluster che utilizzano GKE Dataplane V2 e NodeLocal DNSCache, i pod con il campo hostNetwork impostato su true e il campo dnsPolicy impostato su ClusterFirstWithHostNet non possono raggiungere i backend DNS del cluster. I log DNS potrebbero contenere voci simili alle seguenti:

dnslookup: write to 'a.b.c.d': Operation not permitted

;; connection timed out; no servers could be reached

L'output indica che le richieste DNS non possono raggiungere i server di backend.

Una soluzione alternativa consiste nell'impostare i campi dnsPolicy e dnsConfig per i pod hostNetwork:

spec:
 dnsPolicy: "None"
 dnsConfig:
   nameservers:
     - KUBE_DNS_UPSTREAM
   searches:
     - NAMESPACE.svc.cluster.local
     - svc.cluster.local
     - cluster.local
     - c.PROJECT_ID.internal
     - google.internal
   options:
     - name: ndots
       value: "5"

Sostituisci quanto segue:

• NAMESPACE: lo spazio dei nomi del pod hostNetwork.
• PROJECT_ID: l'ID del tuo Google Cloud progetto.

• KUBE_DNS_UPSTREAM: il ClusterIP del servizio kube-dns upstream. Puoi ottenere questo valore utilizzando il seguente comando:

  kubectl get svc -n kube-system kube-dns-upstream -o jsonpath="{.spec.clusterIP}"
  

Le richieste DNS dal pod ora possono raggiungere kube-dns e bypassare NodeLocal DNSCache.

Errori di timeout di NodeLocal DNSCache

Nei cluster in cui è abilitato NodeLocal DNSCache, i log potrebbero contenere voci simili alle seguenti:

[ERROR] plugin/errors: 2 <hostname> A: read tcp <node IP: port>-><kubedns IP>:53: i/o timeout

Nota: se l'output contiene 169.254.169.254:53 i/o timeout, i timeout provengono dal server di metadati e le seguenti soluzioni alternative non si applicano.

L'output include l'indirizzo IP del servizio kube-dns-upstream Cluster IP. In questo esempio, la risposta a una richiesta DNS non è stata ricevuta da kube-dns in due secondi. Questo problema potrebbe essere dovuto a uno dei seguenti motivi:

• Un problema di connettività di rete sottostante.
• Aumento significativo delle query DNS dal workload o dallo scale up del pool di nodi.

Di conseguenza, i pod kube-dns esistenti non possono gestire tutte le richieste in tempo. La soluzione alternativa consiste nell'aumentare il numero di repliche kube-dns mediante lo scaling up di kube-dns.

Aumento della scalabilità di kube-dns

Puoi utilizzare un valore inferiore per il campo nodesPerReplica per assicurarti che vengano creati più pod kube-dns durante lo scale up dei nodi del cluster. Ti consigliamo vivamente di impostare un valore max esplicito per garantire che la macchina virtuale (VM) del control plane GKE non sia sovraccarica a causa del numero elevato di pod kube-dns che monitorano l'API Kubernetes.

Puoi impostare il campo max sul numero di nodi nel cluster. Se il cluster ha più di 500 nodi, imposta il campo max su 500.

Nota :l'impostazione del campo max su 500 non crea 500 repliche. ma contribuisce a garantire che le repliche di kube-dns non vengano scalate oltre il valore dell'impostazione max. Nella maggior parte dei casi, devi impostare il campo max su un valore molto inferiore a 500.

Per i cluster Standard, puoi modificare il numero di repliche kube-dns modificando il ConfigMap kube-dns-autoscaler. Questa configurazione non è supportata nei cluster Autopilot.

kubectl edit configmap kube-dns-autoscaler --namespace=kube-system

L'output è simile al seguente:

linear: '{"coresPerReplica":256, "nodesPerReplica":16,"preventSinglePointFailure":true}'

Il numero di repliche di kube-dns viene calcolato utilizzando la seguente formula:

replicas = max(ceil(cores * 1/coresPerReplica), ceil(nodes * 1/nodesPerReplica))

Se definisci i campi min e max in ConfigMap, le repliche sono limitate da questi valori. Per aumentare la scalabilità, modifica il valore del campo nodesPerReplica impostandolo su un valore inferiore e includi un valore per il campo max:

linear: '{"coresPerReplica":256, "nodesPerReplica":8,"max": 15,"preventSinglePointFailure":true}'

La configurazione crea un pod kube-dns per ogni otto nodi del cluster. Un cluster di 24 nodi ha tre repliche, mentre un cluster di 40 nodi ne ha cinque. Se il cluster supera i 120 nodi, il numero di repliche di kube-dns non supera 15, ovvero il valore di max.

Per garantire un livello di base di disponibilità DNS nel cluster, imposta un numero minimo di repliche per kube-dns.

L'output per ConfigMap kube-dns-autoscaler con un campo min definito sarebbe simile al seguente:

linear: '{"coresPerReplica":256, "nodesPerReplica":8,"max": 15,"min": 5,"preventSinglePointFailure":true}'

Passaggi successivi

• Leggi una panoramica di come GKE fornisce DNS gestito.
• Leggi DNS per servizi e pod per una panoramica generale di come viene utilizzato il DNS nei cluster Kubernetes.
• Scopri come utilizzare Cloud DNS per GKE.