Condividi tramite

Personalizzare CoreDNS con il servizio Azure Kubernetes

  • Articolo

Il servizio Azure Kubernetes usa il progetto CoreDNS per la gestione e la risoluzione dns del cluster DNS con tutti i cluster 1.12.x e versioni successive. Per altre informazioni sulla personalizzazione di CoreDNS e Su Kubernetes, vedere la documentazione upstream ufficiale.

Il servizio Azure Kubernetes è un servizio gestito, quindi non è possibile modificare la configurazione principale di CoreDNS (CoreFile). Usare invece un ConfigMap di Kubernetes per eseguire l'override delle impostazioni predefinite. Per visualizzare le mappe di configurazione predefinite del servizio Azure Kubernetes CoreDNS, usare il comando kubectl get configmaps --namespace=kube-system coredns -o yaml.

Questo articolo illustra come usare ConfigMaps per le opzioni di personalizzazione CoreDNS di base di nel servizio Azure Kubernetes. Questo approccio è diverso dalla configurazione di CoreDNS in altri contesti, ad esempio CoreFile.

Nota

In precedenza, kube-dns è stato usato per la gestione e la risoluzione DNS del cluster, ma è ora deprecato. kube-dns ha offerto diverse opzioni di personalizzazione tramite una mappa di configurazione Kubernetes. CoreDNS nonè compatibile con kube-dns. Tutte le personalizzazioni usate in precedenza devono essere aggiornate per CoreDNS.

Operazioni preliminari

  • Questo articolo presuppone che si disponga di un cluster del servizio Azure Kubernetes esistente. Se è necessario un cluster del servizio Azure Kubernetes, è possibile crearne uno usando l'interfaccia della riga di comando di Azure, Azure PowerShell o il portale di Azure.
  • Verificare la versione di CoreDNS in esecuzione. I valori di configurazione possono cambiare tra le versioni.
  • Quando si creano configurazioni come gli esempi seguenti, i nomi nella sezione dati devono terminare in .server o .override. Questa convenzione di denominazione è definita nell'oggetto ConfigMap predefinito del servizio Azure Kubernetes CoreDNS, che è possibile visualizzare usando il comando kubectl get configmaps --namespace=kube-system coredns -o yaml.

Supporto del plug-in

Sono supportati tutti i plug-in CoreDNS predefiniti. Non sono supportati plug-in di componenti aggiuntivi o di terze parti.

Riscrivere DNS

È possibile personalizzare CoreDNS con il servizio Azure Kubernetes per eseguire riscrizioni dei nomi DNS a comparsa.

  1. Creare un file denominato corednsms.yaml e incollare la configurazione di esempio seguente. Assicurarsi di sostituire <domain to be rewritten> con il proprio nome di dominio completo.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: |
    <domain to be rewritten>.com:53 {
    log
    errors
    rewrite stop {
      name regex (.*)\.<domain to be rewritten>\.com {1}.default.svc.cluster.local
      answer name (.*)\.default\.svc\.cluster\.local {1}.<domain to be rewritten>.com
    }
    forward . /etc/resolv.conf # you can redirect this to a specific DNS server such as 10.0.0.10, but that server must be able to resolve the rewritten domain name
    }

    Importante

    Se si esegue il reindirizzamento a un server DNS, come l'IP del servizio CoreDNS, tale server DNS deve essere in grado di risolvere il nome di dominio riscritto.

  2. Creare ConfigMap usando il comando kubectl apply configmap e specificare il nome del manifesto YAML.

    kubectl apply -f corednsms.yaml

  3. Verificare che le personalizzazioni siano state applicate usando kubectl get configmaps e specificare coredns-custom ConfigMap.

    kubectl get configmaps --namespace=kube-system coredns-custom -o yaml

  4. Per ricaricare ConfigMap e abilitare l'utilità di pianificazione kubernetes per riavviare CoreDNS senza tempi di inattività, eseguire un riavvio in sequenza usando kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Server di inoltro personalizzato

Se è necessario specificare un server di inoltro per il traffico di rete, è possibile creare un oggetto ConfigMap per personalizzare il DNS.

  1. Creare un file denominato corednsms.yaml e incollare la configurazione di esempio seguente. Assicurarsi di sostituire il nome forward e l'indirizzo con i valori per il proprio ambiente.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: | # you may select any name here, but it must end with the .server file extension
    <domain to be rewritten>.com:53 {
        forward foo.com 1.1.1.1
    }

  2. Creare ConfigMap usando il comando kubectl apply configmap e specificare il nome del manifesto YAML.

    kubectl apply -f corednsms.yaml

  3. Per ricaricare ConfigMap e abilitare l'utilità di pianificazione kubernetes per riavviare CoreDNS senza tempi di inattività, eseguire un riavvio in sequenza usando kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Usare domini personalizzati

È possibile configurare domini personalizzati che possono essere risolti solo internamente. Ad esempio, è possibile risolvere il puglife.local del dominio personalizzato, che non è un dominio di primo livello valido. Senza un oggetto ConfigMap del dominio personalizzato, il cluster del servizio Azure Kubernetes non riesce a risolvere l'indirizzo.

  1. Creare un nuovo file denominato corednsms.yaml e incollare la configurazione di esempio seguente. Assicurarsi di aggiornare il dominio personalizzato e l'indirizzo IP con i valori per il proprio ambiente.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  puglife.server: | # you may select any name here, but it must end with the .server file extension
    puglife.local:53 {
        errors
        cache 30
        forward . 192.11.0.1  # this is my test/dev DNS server
    }

  2. Creare ConfigMap usando il comando kubectl apply configmap e specificare il nome del manifesto YAML.

    kubectl apply -f corednsms.yaml

  3. Per ricaricare ConfigMap e abilitare l'utilità di pianificazione kubernetes per riavviare CoreDNS senza tempi di inattività, eseguire un riavvio in sequenza usando kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Domini Stub

CoreDNS può essere usato anche per configurare i domini stub.

  1. Creare un file denominato corednsms.yaml e incollare la configurazione di esempio seguente. Assicurarsi di aggiornare i domini personalizzati e gli indirizzi IP con i valori per il proprio ambiente.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: | # you may select any name here, but it must end with the .server file extension
    abc.com:53 {
     errors
     cache 30
     forward . 1.2.3.4
    }
    my.cluster.local:53 {
        errors
        cache 30
        forward . 2.3.4.5
    }

  2. Creare ConfigMap usando il comando kubectl apply configmap e specificare il nome del manifesto YAML.

    kubectl apply -f corednsms.yaml

  3. Per ricaricare ConfigMap e abilitare l'utilità di pianificazione kubernetes per riavviare CoreDNS senza tempi di inattività, eseguire un riavvio in sequenza usando kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Plug-in host

Tutti i plugin integrati sono supportati, quindi è disponibile anche il plugin CoreDNS hosts per personalizzare /etc/hosts.

  1. Creare un file denominato corednsms.yaml e incollare la configurazione di esempio seguente. Assicurarsi di aggiornare gli indirizzi IP e i nomi host con i valori per il proprio ambiente.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom # this is the name of the configmap you can overwrite with your changes
  namespace: kube-system
data:
    test.override: | # you may select any name here, but it must end with the .override file extension
          hosts { 
              10.0.0.1 example1.org
              10.0.0.2 example2.org
              10.0.0.3 example3.org
              fallthrough
          }

  2. Creare ConfigMap usando il comando kubectl apply configmap e specificare il nome del manifesto YAML.

    kubectl apply -f corednsms.yaml

  3. Per ricaricare ConfigMap e abilitare l'utilità di pianificazione kubernetes per riavviare CoreDNS senza tempi di inattività, eseguire un riavvio in sequenza usando kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Completamento del dominio di ricerca non valido per internal.cloudapp.net e reddog.microsoft.com

DNS di Azure configura un dominio di ricerca predefinito di <vnetId>.<region>.internal.cloudapp.net nelle reti virtuali usando DNS di Azure e uno stub reddog.microsoft.com non funzionale nelle reti virtuali usando server DNS personalizzati . Per altre informazioni, vedere la documentazione relativa alla risoluzione dei nomi per le risorse. Kubernetes configura le impostazioni DNS dei pod con ndots: 5 per supportare correttamente la risoluzione del nome host del servizio cluster. Queste due configurazioni combinano per ottenere query di completamento del dominio di ricerca non valide che non riescono mai a essere inviate ai server dei nomi upstream mentre il sistema elabora tramite l'elenco di ricerca del dominio. Queste query non valide causano ritardi nella risoluzione dei nomi e possono comportare un carico aggiuntivo nei server DNS upstream.

A partire dalla versione del servizio Azure Kubernetes v20241025, il servizio Azure Kubernetes configura CoreDNS per rispondere con NXDOMAIN nei due casi seguenti per impedire che queste query di completamento del dominio di ricerca non valide vengano inoltrate al DNS upstream:

  • Qualsiasi query per il dominio radice o un sottodominio di reddog.microsoft.com.
  • Qualsiasi query per un sottodominio di con sette o più etichette nel nome di internal.cloudapp.net dominio.
    • Questa configurazione consente la risoluzione della macchina virtuale in base al nome host. Ad esempio, CoreDNS invia aks12345.myvnetid.myregion.internal.cloudapp.net (6 etichette) a DNS di Azure, ma rifiuta mcr.microsoft.com.myvnetid.myregion.internal.cloudapp.net (8 etichette)

Questo blocco viene implementato nel blocco del server predefinito nel Corefile per il cluster. Se necessario, questa configurazione di rifiuto può essere disabilitata creando blocchi di server personalizzati per il dominio appropriato con un plug-in di inoltro abilitato:

  1. Creare un file denominato corednsms.yaml e incollare la configurazione di esempio seguente. Assicurarsi di aggiornare gli indirizzi IP e i nomi host con i valori per il proprio ambiente.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom # this is the name of the configmap you can overwrite with your changes
  namespace: kube-system
data:
    override-block.server:
       internal.cloudapp.net:53 {
           errors
           cache 30
           forward . /etc/resolv.conf
       }
       reddog.microsoft.com:53 {
           errors
           cache 30
           forward . /etc/resolv.conf
       }

  2. Creare ConfigMap usando il comando kubectl apply configmap e specificare il nome del manifesto YAML.

    kubectl apply -f corednsms.yaml

  3. Per ricaricare ConfigMap e abilitare l'utilità di pianificazione kubernetes per riavviare CoreDNS senza tempi di inattività, eseguire un riavvio in sequenza usando kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Risoluzione dei problemi

Per i passaggi generali per la risoluzione dei problemi di CoreDNS, ad esempio per controllare gli endpoint o la risoluzione, vedere Debug della risoluzione DNS.

Configurare il ridimensionamento dei pod CoreDNS

I picchi improvvisi nel traffico DNS all'interno dei cluster del servizio Azure Kubernetes sono un'occorrenza comune a causa dell'elasticità fornita dal servizio Azure Kubernetes per i carichi di lavoro. Questi picchi possono causare un aumento del consumo di memoria da parte dei pod CoreDNS. In alcuni casi, questo aumento del consumo di memoria potrebbe causare Out of memory problemi. Per evitare questo problema, i cluster del servizio Azure Kubernetes ridimensionano automaticamente i pod CoreDNS per ridurre l'utilizzo della memoria per ogni pod. Le impostazioni predefinite per questa logica di ridimensionamento automatico vengono archiviate in coredns-autoscaler ConfigMap. Tuttavia, è possibile osservare che il ridimensionamento automatico predefinito dei pod CoreDNS non è sempre abbastanza aggressivo per evitare Out of memory problemi per i pod CoreDNS. In questo caso, è possibile modificare direttamente ConfigMap coredns-autoscaler. Si noti che è sufficiente aumentare il numero di pod CoreDNS senza risolvere la causa radice del problema Out of memory può fornire solo una correzione temporanea. Se non è disponibile memoria sufficiente nei nodi in cui sono in esecuzione i pod CoreDNS, l'aumento del numero di pod CoreDNS non sarà utile. Potrebbe essere necessario esaminare ulteriormente e implementare soluzioni appropriate, ad esempio l'ottimizzazione dell'utilizzo delle risorse, la regolazione delle richieste e i limiti delle risorse o l'aggiunta di più memoria ai nodi.

CoreDNS usa il componente di scalabilità automatica proporzionale del cluster orizzontale per il ridimensionamento automatico dei pod. È possibile modificare coredns-autoscaler ConfigMap per configurare la logica di ridimensionamento per il numero di pod CoreDNS. ConfigMap coredns-autoscaler supporta attualmente due valori di chiave ConfigMap diversi: linear e ladder che corrispondono a due modalità di controllo supportate. Il controller linear restituisce un numero di repliche nell'intervallo [min,max] equivalente a max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) ). Il controller ladder calcola il numero di repliche consultando due funzioni di passaggio diverse, una per il ridimensionamento principale e un'altra per il ridimensionamento dei nodi, ottenendo il massimo dei due valori di replica. Per altre informazioni sulle modalità di controllo e sul formato ConfigMap, vedere la documentazione upstream.

Importante

È consigliabile usare almeno 2 repliche pod CoreDNS per ogni cluster. La configurazione di almeno 1 replica pod CoreDNS può causare errori durante le operazioni che richiedono lo svuotamento dei nodi, ad esempio le operazioni di aggiornamento del cluster.

Per recuperare ConfigMap coredns-autoscaler, è possibile eseguire il comando kubectl get configmap coredns-autoscaler -n kube-system -o yaml che restituirà quanto segue:

apiVersion: v1
data:
  ladder: '{"coresToReplicas":[[1,2],[512,3],[1024,4],[2048,5]],"nodesToReplicas":[[1,2],[8,3],[16,4],[32,5]]}'
kind: ConfigMap
metadata:
  name: coredns-autoscaler
  namespace: kube-system
  resourceVersion: "..."
  creationTimestamp: "..."

Abilitare la registrazione delle query DNS

  1. Aggiungere la configurazione seguente all'oggetto ConfigMap coredns-custom:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  log.override: | # you may select any name here, but it must end with the .override file extension
        log

  2. Applicare le modifiche alla configurazione e forzare CoreDNS a ricaricare ConfigMap usando i comandi seguenti:

    # Apply configuration changes
kubectl apply -f corednsms.yaml

# Force CoreDNS to reload the ConfigMap
kubectl -n kube-system rollout restart deployment coredns

  3. Visualizzare la registrazione di debug CoreDNS usando il comando kubectl logs.

    kubectl logs --namespace kube-system -l k8s-app=kube-dns

Passaggi successivi

Questo articolo ha illustrato alcuni scenari di esempio per la personalizzazione coreDNS. Per informazioni sul progetto CoreDNS, vedere la pagina del progetto upstream CoreDNS.

Per altre informazioni sui concetti di base della rete, vedere Concetti di rete per le applicazioni nel servizio Azure Kubernetes.