Configurare LocalDNS in Servizio Azure Kubernetes (AKS)

Si applica a: ✔️ Servizio Azure Kubernetes Standard automatico ✔️ Servizio Azure Kubernetes standard

Per la maggior parte dei carichi di lavoro di produzione, AKS Automatic è l'opzione predefinita consigliata e pronta per la produzione per AKS. LocalDNS è preconfigurato nei cluster AKS Automatic. Nella versione Standard di AKS, il comportamento di LocalDNS dipende dalla versione di Kubernetes e dal profilo LocalDNS esistente del pool di nodi.

LocalDNS è una funzionalità di AKS che migliora le prestazioni e la resilienza della risoluzione DNS per i carichi di lavoro in esecuzione nel cluster. Eseguendo un proxy DNS in ogni nodo, LocalDNS riduce la latenza delle query DNS, migliora l'affidabilità durante le interruzioni di rete temporanee e fornisce controlli avanzati di memorizzazione nella cache e inoltro quando è necessaria la personalizzazione.

Per informazioni su LocalDNS, inclusi i dettagli dell'architettura e le funzionalità chiave, vedere Risoluzione DNS in Servizio Azure Kubernetes (AKS).

Comportamento di LocalDNS in AKS Automatic e AKS Standard

Controlli di compatibilità per la modalità Preferred

A partire da Kubernetes 1.37, AKS Standard assegna la modalità Preferred ai pool di nodi idonei senza un profilo LocalDNS esplicito al momento della creazione o dell’aggiornamento di tali pool. AKS mantiene i profili configurati esplicitamente.

Prima di attivare inizialmente LocalDNS in modalità Preferred, AKS verifica i seguenti requisiti di compatibilità. Se non viene soddisfatto un requisito, LocalDNS rimane disabilitato.

Quando AKS attiva LocalDNS in modalità Preferred, rimane attivato durante i successivi aggiornamenti non correlati del pool di nodi. Per disabilitarla, impostare esplicitamente LocalDNS mode su Disabled.

Procedure consigliate per la configurazione localDNS

Implementando LocalDNS nei cluster AKS, prendere in considerazione le seguenti best practices:

• Iniziare con una configurazione minima: iniziare con una configurazione semplice che usa la modalità per convalidare la Preferred sintassi di configurazione LocalDNS prima di passare alla Required modalità. La Preferred modalità convalida la configurazione senza abilitare LocalDNS, consentendo di rilevare gli errori di configurazione in anticipo senza influire sul cluster.
• Implementare strategie di memorizzazione nella cache appropriate: configurare le impostazioni della cache in base alle caratteristiche del carico di lavoro:
  • Per i record che cambiano di frequente, usare valori più cacheDurationInSeconds brevi. In questo caso, è importante notare che cacheDurationInSeconds funge da limite per il TTL del record DNS, ma non lo aumenta. Il TTL risultante è il più piccolo di ciò che viene restituito da upstream o ciò che è impostato nel plug-in della cache.
  • Per i record stabili, usare durate della cache più lunghe per ridurre le query DNS.
  • Abilitare serveStale con le impostazioni appropriate per mantenere il servizio durante le interruzioni DNS.
  • La memorizzazione nella cache con LocalDNS opera in modo ottimale e non garantisce risposte non aggiornate. La cache è divisa in 256 partizioni e con un massimo predefinito di 10.000 voci, consentendo a ogni partizione di contenere circa 39 voci. Quando una partizione è piena e deve essere aggiunta una nuova voce, una delle voci esistenti viene scelta in modo casuale per essere rimossa. Non esiste alcuna preferenza per le voci meno recenti o scadute. Di conseguenza, un record non aggiornato potrebbe non essere sempre disponibile, soprattutto in un volume di query elevato.
• Monitorare le prestazioni DNS: dopo aver abilitato LocalDNS, monitorare le prestazioni DNS dell'applicazione usando:
  • Metriche delle prestazioni dell'applicazione.
  • Metriche dei nodi per rilevare una riduzione della pressione di rete.
  • Voci di log quando queryLogging è impostato su Log.
• Seguire il principio dei privilegi minimi: quando si configurano le regole di inoltro DNS, consentire l'accesso solo ai server e ai domini DNS necessari.
• Test prima della distribuzione di produzione: testare sempre la configurazione LocalDNS in un ambiente non di produzione prima di distribuirla nei cluster di produzione.
• Utilizzare Infrastructure as Code (IaC): archiviare il file localdnsconfig.json nel repository dell'infrastruttura e includerlo nei modelli di distribuzione AKS.
• Configurazione di rete per l'inoltro TCP: quando si usa TCP per l'inoltro DNS a VnetDNS, assicurarsi che i gruppi di sicurezza di rete (NSG), i firewall o le appliance virtuali di rete (APPLIANCE virtuali di rete) non blocchino il traffico TCP tra i server CoreDNS/LocalDNS e VnetDNS.
• Evitare di abilitare sia NodeLocal DNSCache che LocalDNS: non è consigliabile abilitare sia NodeLocal DNSCache upstream che LocalDNS nel pool di nodi. Anche se AKS non blocca questa configurazione, tutto il traffico DNS viene instradato attraverso LocalDNS, che potrebbe causare un comportamento imprevisto o ridurre i vantaggi di NodeLocal DNSCache.
• Non imporre un limite di connessione TCP sul server DNS personalizzato upstream prima di abilitare LocalDNS: quando si abilita LocalDNS in un pool di nodi, ogni nodo apre connessioni TCP di lunga durata dal proxy DNS locale al resolver upstream, anziché gli scambi UDP brevi usati in precedenza. Se il server DNS personalizzato(ad esempio BIND, Unbound, Windows DNS o un'appliance di terze parti) è configurato con un limite fisso per le connessioni client TCP simultanee o se è stato modificato tale limite in base al traffico pre-LocalDNS, le nuove connessioni TCP da LocalDNS possono essere rifiutate, causando errori di risoluzione DNS a livello di cluster. Lasciate qualsiasi limite di connessione TCP al valore predefinito, sufficientemente ampio, prima di attivare LocalDNS; dopo l'attivazione, convalidate il numero di connessioni TCP in stato stazionario dei nodi AKS e regolate il limite solo successivamente, mantenendo un margine per il ridimensionamento dei nodi, gli aggiornamenti e il reimaging.

Prerequisiti

I cluster automatici di AKS includono LocalDNS preconfigurato. I prerequisiti di questa sezione si applicano principalmente quando si attiva o si personalizza il comportamento di LocalDNS, soprattutto negli scenari di AKS Standard e di personalizzazione avanzata.

• Per usare LocalDNS, è necessario disporre di un cluster del servizio Azure Kubernetes esistente con le versioni 1.31 e successive. Se hai bisogno di un cluster AKS, puoi crearne uno usando interfaccia della riga di comando di Azure, Azure PowerShell o il portale di Azure.
• Questo articolo richiede interfaccia della riga di comando di Azure versione 2.80.0 e successive. Se si usa Azure Cloud Shell, la versione più recente è già installata.
• LocalDNS è supportato solo nei pool di nodi che eseguono Azure Linux o Ubuntu 22.04 e versioni successive.
• Lo SKU della macchina virtuale usato per il pool di nodi deve avere almeno 4 vCPU (core) per supportare LocalDNS.

Abilitare o personalizzare LocalDNS in un cluster AKS

È possibile configurare LocalDNS a livello di pool di nodi nel servizio Azure Kubernetes, in modo da poter personalizzare il comportamento in base al carico di lavoro e all'ambiente.

In AKS Automatic, LocalDNS è già preconfigurato, quindi questa sezione serve principalmente per la personalizzazione.

In AKS Standard usare questa sezione per abilitare e configurare LocalDNS.

Convalidare il DNS personalizzato prima di abilitare LocalDNS

Se la rete virtuale usa server DNS personalizzati, testa entrambi i protocolli di trasporto DNS da un nodo AKS prima di abilitare LocalDNS:

dig +udp @<custom-dns-ip> <fqdn>
dig +tcp @<custom-dns-ip> <fqdn>

Entrambi i comandi devono restituire una risposta valida. Se UDP ha esito positivo ma si verifica il timeout TCP, non abilitare LocalDNS fino a quando la porta TCP 53 non è consentita tramite il percorso di rete completo e il server DNS personalizzato è configurato per accettare query TCP.

Abilitare LocalDNS in un pool di nodi

Questo passaggio si applica in genere ad AKS Standard. AKS automatico include già LocalDNS preconfigurato.

Per abilitare LocalDNS durante la creazione del pool di nodi, usare il comando seguente con il file di configurazione personalizzato:

az aks nodepool add --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

Per abilitare LocalDNS in un pool di nodi esistente, usare il comando seguente con il file di configurazione personalizzato:

az aks nodepool update --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

Disabilitare LocalDNS in un pool di nodi

La disabilitazione di LocalDNS è un'operazione avanzata e in genere non è consigliata per le impostazioni predefinite di produzione automatica del servizio Azure Kubernetes, a meno che non si disponga di un'eccezione convalidata.

Per disabilitare LocalDNS per un pool di nodi, è necessario aggiornare il file localdnsconfig.json impostando la mode proprietà su Disabled. Questa modifica indica al servizio Azure Kubernetes di disattivare il proxy DNS locale in tutti i nodi del pool specificato, ripristinando la risoluzione DNS al comportamento del cluster predefinito. Dopo aver aggiornato il file di configurazione, applicarlo al pool di nodi usando il interfaccia della riga di comando di Azure per assicurarsi che la modifica venga applicata.

az aks nodepool update --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

Verificare l'operazione LocalDNS

In AKS Automatic, la verifica conferma che la configurazione di base LocalDNS preconfigurata è attiva per i tuoi carichi di lavoro. In AKS Standard, la verifica conferma la distribuzione di LocalDNS.

Dopo aver abilitato LocalDNS, è possibile verificarne l'operazione eseguendo query DNS dai pod nel pool di nodi specificato e controllando il SERVER campo nelle risposte per confermare che gli indirizzi LocalDNS vengono restituiti (169.254.10.10 o 169.254.10.11).

Prima di eseguire i passaggi di convalida, verificare che siano soddisfatte le condizioni seguenti:

1. Hai kubectl installato e configurato per accedere al cluster AKS.
2. L'account utente dispone di autorizzazioni sufficienti per la creazione e l'esecuzione in pod.
3. Il pool di nodi in cui si vuole convalidare LocalDNS è in uno stato Pronto .
4. L'immagine BusyBox (busybox:1.28) è accessibile dai nodi del cluster.

Esempio di convalida:

1. Creare un pod di debug nel pool di nodi in cui LocalDNS è abilitato:

   kubectl run dnstest --image=busybox:1.28 -- sleep 3600
   

2. Quando il pod è in esecuzione, eseguire il comando seguente per controllare la risoluzione DNS:

   kubectl exec -it dnstest -- nslookup kubernetes.default
   

   Controllare l'output. Se localDNS funziona correttamente, verrà visualizzata una risposta con l'indirizzo del server 169.254.10.10 o 169.254.10.11:

   Server:    169.254.10.10
   Address 1: 169.254.10.10
   
   Name:      kubernetes.default
   Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local
   

Configurare LocalDNS

LocalDNS usa un file di configurazione basato su JSON localdnsconfig.json per definire il comportamento di risoluzione DNS per ogni pool di nodi. Questo file consente di specificare modalità operative, blocchi di server per domini DNS diversi e impostazioni del plug-in, ad esempio memorizzazione nella cache, inoltro e registrazione.

Configurazione localDNS predefinita

In AKS Automatic, LocalDNS è preconfigurato. Usare la personalizzazione solo quando si ha un requisito specifico.

In AKS Standard questa configurazione predefinita è un buon punto di partenza.

Quando si personalizza LocalDNS, usare il formato di configurazione seguente come modello. È possibile definire blocchi server aggiuntivi in base alle esigenze, ma l'aggiunta di proprietà di primo livello non supportate o non standard ai risultati della configurazione comporta errori di convalida.

{
  "mode": "Required",
  "vnetDNSOverrides": {
    ".": {
      "queryLogging": "Error",
      "protocol": "PreferUDP",
      "forwardDestination": "VnetDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    },
    "cluster.local": {
      "queryLogging": "Error",
      "protocol": "ForceTCP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    }
  },
  "kubeDNSOverrides": {
    ".": {
      "queryLogging": "Error",
      "protocol": "PreferUDP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    },
    "cluster.local": {
      "queryLogging": "Error",
      "protocol": "ForceTCP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    }
  }
}

Configura il mode per LocalDNS

LocalDNS può essere abilitato in tre modalità possibili che definiscono l'estensione dell'imposizione di LocalDNS per il carico di lavoro:

• Required: LocalDNS viene applicato nel pool di nodi se tutti i prerequisiti sono soddisfatti. Se i requisiti non sono soddisfatti, la distribuzione ha esito negativo.
• Disabled: disabilita la funzionalità DNS locale, quindi le query DNS non vengono risolte localmente nel nodo.
• Preferred: AKS convalida che la configurazione di LocalDNS sia sintatticamente corretta, ma non abilita LocalDNS sui nodi. Tuttavia, l'applicazione di questa modalità attiva ancora un'operazione di ricreazione dell'immagine del nodo, in modo da poter testare la configurazione per gli errori senza influire sulla risoluzione DNS nel cluster.

Per i carichi di lavoro di produzione in AKS Automatic, mantieni il comportamento preconfigurato di LocalDNS, a meno che non vi sia un'esigenza convalidata di personalizzarlo.

La tabella seguente riepiloga il comportamento LocalDNS per ogni modalità e versione di Kubernetes:

Blocchi del server per LocalDNS

La configurazione predefinita si applica alle query dai pod che utilizzano dnsPolicy:default (sotto vnetDNSOverrides) e ai pod che utilizzano dnsPolicy:ClusterFirst (sotto kubeDNSOverrides). All'interno di ognuna sono definiti due blocchi di server predefiniti: . e cluster.local.

• . rappresenta tutte le query DNS esterne dai pod che tentano di risolvere domini pubblici o non-cluster, ad esempio microsoft.com.
• cluster.local rappresenta tutte le query di individuazione dei servizi Kubernetes interne dai pod che tentano di risolvere i nomi dei servizi Kubernetes o le risorse interne del cluster. Queste query vengono instradate tramite CoreDNS per la risoluzione all'interno del cluster.

Plug-in supportati per la configurazione localDNS

Regole di convalida della configurazione

Quando si crea la configurazione LocalDNS, tenere presente queste regole di convalida per evitare errori di distribuzione:

• Restrizioni della zona radice (.): in vnetDNSOverrides, l'oggetto forwardDestination per la zona radice non può essere ClusterCoreDNS.
• Restrizioni della zona cluster.local: in vnetDNSOverrides e kubeDNSOverrides, forwardDestination per cluster.local non può essere VnetDNS.
• Compatibilità tra protocollo e serveStale: quando protocol è impostato su ForceTCP, non è possibile impostare serveStale su Verify. Utilizzare invece Immediate.

Creare un blocco di server personalizzato in LocalDNS

CoreDNS abbina le query a un blocco di server specifico basandosi su una corrispondenza esatta per il dominio che viene queryato e non su corrispondenze parziali. Se sono necessari blocchi di server personalizzati, è possibile aggiungerli alla configurazione LocalDNS creando un file denominato localdnsconfig.json con le configurazioni aggiunte.

Ad esempio, se si dispone di esigenze DNS specifiche per l'accesso a microsoft.com, è possibile usare il blocco di server seguente:

"microsoft.com": {
  "queryLogging": "Error",
  "protocol": "ForceTCP",
  "forwardDestination": "ClusterCoreDNS",
  "forwardPolicy": "Sequential",
  "maxConcurrent": 1000,
  "cacheDurationInSeconds": 3600,
  "serveStaleDurationInSeconds": 3600,
  "serveStale": "Immediate"
}

Monitorare LocalDNS

In AKS Automatic, LocalDNS è preconfigurato, quindi inizia con una convalida iniziale e monitora il comportamento prima di applicare ottimizzazioni personalizzate.

LocalDNS espone le metriche di Prometheus che è possibile usare per il monitoraggio e gli avvisi. Le metriche vengono esposte sulla porta 9253 dell'INDIRIZZO IP del nodo.

Configurazione di scrape di esempio per il componente aggiuntivo Prometheus gestito da Azure come DaemonSet:

kind: ConfigMap
apiVersion: v1
metadata:
  name: ama-metrics-prometheus-config-node
  namespace: kube-system
data:
  prometheus-config: |-
    global:
      scrape_interval: 1m
    scrape_configs:
    - job_name: localdns-metrics
      scrape_interval: 1m
      scheme: http
      metrics_path: /metrics
      relabel_configs:
      - source_labels: [__metrics_path__]
        regex: (.*)
        target_label: metrics_path
      - source_labels: [__address__]
        replacement: '$NODE_NAME'
        target_label: instance
      static_configs:
      - targets: ['$NODE_IP:9253']

Risolvere i problemi relativi a LocalDNS

Le query DNS a domini specifici falliscono

Se le query DNS in domini specifici hanno esito negativo dopo l'abilitazione di LocalDNS:

1. Controllare se sono presenti override specifici del dominio nel localdnsconfig.json che potrebbero essere configurati in modo errato.

2. Rimuovere temporaneamente gli override specifici del dominio e utilizzare solo la configurazione predefinita ..

3. Controllare se il problema si verifica sia con il protocollo UDP (User Datagram Protocol) che tcp (Transmission Control Protocol) modificando l'impostazione protocol .

4. Verificare nei log di CoreDNS eventuali timeout verso gli indirizzi LocalDNS 169.254.10.10:53 o 169.254.10.11:53. Da un nodo interessato, verificare separatamente il server DNS upstream personalizzato tramite UDP e TCP:

   dig +udp @<custom-dns-ip> <fqdn>
   dig +tcp @<custom-dns-ip> <fqdn>
   

   Se UDP ha esito positivo ma TCP ha esito negativo, verificare che:

   • Il server DNS personalizzato è in ascolto sulla porta TCP 53.
   • I gruppi di sicurezza di rete (NSG) e i firewall consentono il traffico sulla porta TCP 53 dalla subnet dei nodi di AKS.
   • Le appliance virtuali di rete e le route non scartano né instradano in modo asimmetrico il traffico DNS su TCP.

   Per disabilitare LocalDNS in un pool di nodi interessato, aggiornare la modalità LocalDNS su Disabled. La modifica di un pool abilitato in Disabled attiva la ricreazione dell'immagine di un nodo come parte dell'aggiornamento. Per una correzione permanente, assicurarsi che il server DNS personalizzato e il percorso di rete supportino DNS su UDP e TCP sulla porta 53.

Aggiornare i server DNS della rete virtuale per LocalDNS

Quando si aggiornano i server DNS personalizzati direttamente nella configurazione della rete virtuale (usando il portale di Azure o l'interfaccia della riga di comando), i nodi del cluster del servizio Azure Kubernetes non applicano automaticamente queste modifiche. L'aggiornamento delle impostazioni DNS a livello di rete virtuale informa solo il provider di risorse di rete (NRP), ma non notifica il provider di risorse di AKS. Di conseguenza, i nodi del servizio Azure Kubernetes continuano a usare le impostazioni precedenti del server DNS fino a quando non si esegue un'ulteriore azione.

Per assicurarsi che i nodi del servizio Azure Kubernetes rilevino le nuove impostazioni del server DNS della rete virtuale:

1. Aggiornare la configurazione DNS della rete virtuale usando il portale di Azure o le API in base alle esigenze.

2. Usare il provider di risorse AKS per rigenerare l'immagine del pool di nodi, per garantire che le impostazioni DNS aggiornate siano applicate e mantenute.

   az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only
   

Questo processo garantisce che il provider di risorse AKS sia al corrente delle modifiche DNS e le applica a tutti i nodi del pool.

Aggiornare i criteri di rete Cilium per consentire la risoluzione DNS con LocalDNS

Se si distribuiscono criteri di rete Cilium nel cluster, è necessario consentire in modo esplicito l'uscita dei pod agli indirizzi IP LocalDNS.

I criteri di rete applicano un modello di negazione predefinito per le destinazioni non specificate, quindi il traffico DNS verso LocalDNS viene bloccato a meno che non sia consentito in modo esplicito.

• Su Azure CNI con tecnologia Cilium <=v1.16 con k8s <=1.31, ciò si può ottenere mediante un criterio basato su CIDR.
• In Azure CNI con tecnologia Cilium >=v1.17 con K8s >=1.32, è possibile usare criteri di rete Cilium che consentono l'uscita alle entità host.

Per un criterio di rete di Cilium che consente il traffico tra tutte le versioni, vedi DNS locale di AKS è supportato con Azure CNI basato su Cilium?

Contenuti correlati

• Che cos'è AKS Automatic?
• Creare un cluster automatico di AKS
• LocalDNS in servizio Azure Kubernetes (concettuale)
• Risolvere i problemi di LocalDNS in AKS
• Guida alla personalizzazione coreDNS
• Pagina del progetto upstream CoreDNS
• Concetti di rete per applicazioni in AKS