Anpassen von CoreDNS mit Azure Kubernetes Service

Artikel
10/31/2024

Azure Kubernetes Service (AKS) verwendet das CoreDNS-Projekt für die Cluster-DNS-Verwaltung und die Auflösung aller Cluster der Version 1.12.x und höher. Weitere Informationen zur CoreDNS-Anpassung und zu Kubernetes finden Sie in der offiziellen Upstream-Dokumentation.

AKS ist ein verwalteter Dienst, daher können Sie die Hauptkonfiguration für CoreDNS (ein CoreFile) nicht ändern. Stattdessen verwenden Sie eine ConfigMap von Kubernetes, um die Standardeinstellungen zu überschreiben. Um die standardmäßigen AKS CoreDNS ConfigMaps anzuzeigen, verwenden Sie den Befehl kubectl get configmaps --namespace=kube-system coredns -o yaml.

In diesem Artikel wird erläutert, wie Sie ConfigMaps für grundlegende CoreDNS-Anpassungsoptionen in AKS verwenden. Diese Vorgehensweise unterscheidet sich von der Konfiguration von CoreDNS in anderen Kontexten wie CoreFile.

Hinweis

Zuvor wurde Kube-DNS für die Cluster-DNS-Verwaltung und -Auflösung verwendet. Es ist jetzt aber veraltet. kube-dns bot verschiedene Anpassungsoptionen über eine Kubernetes-Konfigurationszuordnung. CoreDNS ist nicht abwärtskompatibel zu kube-dns. Alle Anpassungen, die Sie zuvor verwendet haben, müssen für CoreDNS aktualisiert werden.

Voraussetzungen

Es wird vorausgesetzt, dass Sie über ein AKS-Cluster verfügen. Wenn Sie einen AKS-Cluster benötigen, können Sie einen mithilfe der Azure-Befehlszeilenschnittstelle, mit Azure PowerShell oder über das Azure-Portal erstellen.
Überprüfen Sie die Version von CoreDNS, die Sie ausführen. Die Konfigurationswerte können sich von Version zu Version ändern.
Wenn Sie Konfigurationen wie die in den unten aufgeführten Beispielen erstellen, müssen die Namen im Abschnitt Daten entweder auf .server oder .override enden. Diese Namenskonvention wird in der Standard-ConfigMap von AKS CoreDNS definiert, die Sie mit dem Befehl „kubectl get configmaps --namespace=kube-system coredns -o yaml“ anzeigen können.

Plug-In-Unterstützung

Alle integrierten CoreDNS-Plug-Ins werden unterstützt. Es werden keine Add-On-/Drittparteien-Plug-Ins unterstützt.

Erneutes Schreiben des DNS

Sie können CoreDNS mit AKS anpassen, um spontane DNS-Namensneuschreibungen durchzuführen.

Erstellen Sie eine Datei namens „corednsms.yaml“, und fügen Sie die folgende Beispielkonfiguration ein. Stellen Sie sicher, dass Sie „<domain to be rewritten>“ durch Ihren eigenen vollqualifizierten Domänennamen ersetzen.

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
    }

Wichtig

Wenn Sie zu einem DNS-Server umleiten, z. B. die CoreDNS-Dienst-IP, muss dieser DNS-Server in der Lage sein, den umgeschriebenen Domänennamen aufzulösen.

Erstellen Sie die ConfigMap mit dem Befehl „kubectl apply configmap“, und geben Sie den Namen Ihres YAML-Manifests an.
```
kubectl apply -f corednsms.yaml
```
Vergewissern Sie sich, dass die Anpassungen mithilfe von kubectl get configmaps angewendet wurden, und geben Sie Ihre benutzerdefinierte CoreDNS-ConfigMap an.
```
kubectl get configmaps --namespace=kube-system coredns-custom -o yaml
```
Um die ConfigMap neu zu laden und Kubernetes Scheduler zu ermöglichen, CoreDNS ohne Ausfallzeit neu zu starten, führen Sie einen rollierenden Neustart mithilfe von kubectl rollout restart aus.
```
kubectl -n kube-system rollout restart deployment coredns
```

Benutzerdefinierter Weiterleitungsserver

Wenn Sie einen Weiterleitungsserver für den Netzwerkdatenverkehr angeben müssen, können Sie eine ConfigMap für das Anpassen von DNS erstellen.

Erstellen Sie eine Datei namens „corednsms.yaml“, und fügen Sie die folgende Beispielkonfiguration ein. Ersetzen Sie unbedingt den Namen „forward“ und die Adresse durch die Werte für Ihre eigene Umgebung.

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
    }

Erstellen Sie die ConfigMap mit dem Befehl „kubectl apply configmap“, und geben Sie den Namen Ihres YAML-Manifests an.
```
kubectl apply -f corednsms.yaml
```
Um die ConfigMap neu zu laden und Kubernetes Scheduler zu ermöglichen, CoreDNS ohne Ausfallzeit neu zu starten, führen Sie einen rollierenden Neustart mithilfe von kubectl rollout restart aus.
```
kubectl -n kube-system rollout restart deployment coredns
```

Verwenden benutzerdefinierter Domänen

Sie sollten benutzerdefinierte Domänen konfigurieren, die nur intern aufgelöst werden können. Sie sollten z. B. die benutzerdefinierte Domäne puglife.local auflösen, die keine gültige Domäne der obersten Ebene ist. Ohne eine ConfigMap für benutzerdefinierte Domänen kann der AKS-Cluster die Adresse nicht auflösen.

Erstellen Sie eine neue Datei namens corednsms.yaml, und fügen Sie die folgende Beispielkonfiguration ein. Stellen Sie sicher, dass Sie im folgenden Beispiel die benutzerdefinierte Domäne und IP-Adresse mit den Werten Ihrer eigenen Umgebung aktualisieren.

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
    }

Erstellen Sie die ConfigMap mit dem Befehl „kubectl apply configmap“, und geben Sie den Namen Ihres YAML-Manifests an.
```
kubectl apply -f corednsms.yaml
```
Um die ConfigMap neu zu laden und Kubernetes Scheduler zu ermöglichen, CoreDNS ohne Ausfallzeit neu zu starten, führen Sie einen rollierenden Neustart mithilfe von kubectl rollout restart aus.
```
kubectl -n kube-system rollout restart deployment coredns 
```

Stubdomänen

CoreDNS kann auch für das Konfigurieren von Stubdomänen verwendet werden.

Erstellen Sie eine Datei namens „corednsms.yaml“, und fügen Sie die folgende Beispielkonfiguration ein. Stellen Sie sicher, dass Sie im folgenden Beispiel die benutzerdefinierten Domänen und IP-Adressen mit den Werten Ihrer eigenen Umgebung aktualisieren.

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
    }

Erstellen Sie die ConfigMap mit dem Befehl „kubectl apply configmap“, und geben Sie den Namen Ihres YAML-Manifests an.
```
kubectl apply -f corednsms.yaml
```
Um die ConfigMap neu zu laden und Kubernetes Scheduler zu ermöglichen, CoreDNS ohne Ausfallzeit neu zu starten, führen Sie einen rollierenden Neustart mithilfe von kubectl rollout restart aus.
```
kubectl -n kube-system rollout restart deployment coredns
```

Hosts-Plug-In

Alle integrierten Plug-Ins werden unterstützt, daher ist das CoreDNS-Plug-In hosts ebenfalls für die Anpassung von „/etc/hosts“ verfügbar.

Erstellen Sie eine Datei namens „corednsms.yaml“, und fügen Sie die folgende Beispielkonfiguration ein. Aktualisieren Sie unbedingt die IP-Adressen und Hostnamen mit den Werten Ihrer eigenen Umgebung.

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
          }

Erstellen Sie die ConfigMap mit dem Befehl „kubectl apply configmap“, und geben Sie den Namen Ihres YAML-Manifests an.
```
kubectl apply -f corednsms.yaml
```
Um die ConfigMap neu zu laden und Kubernetes Scheduler zu ermöglichen, CoreDNS ohne Ausfallzeit neu zu starten, führen Sie einen rollierenden Neustart mithilfe von kubectl rollout restart aus.
```
kubectl -n kube-system rollout restart deployment coredns
```

Ungültige Suchdomänenvervollständigungen für internal.cloudapp.net und reddog.microsoft.com

Azure DNS konfiguriert die standardmäßige Suchdomäne <vnetId>.<region>.internal.cloudapp.net in virtuellen Netzwerken mit Azure DNS und einen nicht funktionsfähigen Rumpf reddog.microsoft.com in virtuellen Netzwerken mit benutzerdefinierten DNS-Servern (weitere Details finden Sie in der Dokumentation zur Namensauflösung für Ressourcen). Kubernetes konfiguriert Pod-DNS-Einstellungen mit ndots: 5, um die Auflösung des Hostnamens für den Clusterdienst ordnungsgemäß zu unterstützen. Diese beiden Konfigurationen führen zu ungültigen Abfragen für Suchdomänenvervollständigungen, die nie erfolgreich an Upstreamnamenserver gesendet werden, während das System die Domänensuchliste verarbeitet. Diese ungültigen Abfragen verursachen Namensauflösungsverzögerungen und können zu zusätzlichen Lasten auf Upstream-DNS-Servern führen.

Ab AKS-Version v20241025 konfiguriert AKS CoreDNS so, dass in den folgenden beiden Fällen mit NXDOMAIN geantwortet wird, um zu verhindern, dass diese ungültigen Abfragen für Suchdomänenvervollständigungen an Upstream-DNS weitergeleitet werden:

Jede Abfrage für die Stammdomäne oder eine Unterdomäne des Typs reddog.microsoft.com.
Jede Abfrage für eine Unterdomäne des Typs internal.cloudapp.net mit sieben oder mehr Bezeichnungen im Domänennamen.
- Durch diese Konfiguration ist die Auflösung virtueller Computer nach Hostnamen weiterhin möglich. CoreDNS sendet z. B. aks12345.myvnetid.myregion.internal.cloudapp.net (6 Bezeichnungen) an Azure DNS, lehnt jedoch mcr.microsoft.com.myvnetid.myregion.internal.cloudapp.net (8 Bezeichnungen) ab.

Dieser Block wird im Standardserverblock in der Corefile-Datei für den Cluster implementiert. Bei Bedarf kann diese Ablehnungskonfiguration deaktiviert werden, indem benutzerdefinierte Serverblöcke für die entsprechende Domäne mit aktiviertem Weiterleitungs-Plug-In erstellt werden:

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
       }

Erstellen Sie die ConfigMap mit dem Befehl „kubectl apply configmap“, und geben Sie den Namen Ihres YAML-Manifests an.
```
kubectl apply -f corednsms.yaml
```
Um die ConfigMap neu zu laden und Kubernetes Scheduler zu ermöglichen, CoreDNS ohne Ausfallzeit neu zu starten, führen Sie einen rollierenden Neustart mithilfe von kubectl rollout restart aus.
```
kubectl -n kube-system rollout restart deployment coredns
```

Problembehandlung

Allgemeine Schritte zur Problembehandlung für CoreDNS, z. B. das Überprüfen der Endpunkte oder die Auflösung, finden Sie unter Debuggen der DNS-Auflösung.

Konfigurieren der CoreDNS-Pod-Skalierung

Plötzliche Spitzen des DNS-Datenverkehrs in AKS-Clustern sind aufgrund der Elastizität, die AKS für Workloads bietet, ein häufiges Phänomen. Diese Spitzen können zu einem Anstieg des Arbeitsspeicherverbrauchs durch CoreDNS-Pods führen. In einigen Fällen kann dieser erhöhte Arbeitsspeicherverbrauch zu Out of memory-Problemen führen. Um diesem Problem vorzubeugen, skalieren AKS-Cluster CoreDNS-Pods automatisch, um die Arbeitsspeicherverbrauch pro Pod zu reduzieren. Die Standardeinstellungen für diese Logik zur automatischen Skalierung werden in der coredns-autoscaler-ConfigMap gespeichert. Möglicherweise stellen Sie jedoch fest, dass die automatische Standardskalierung für CoreDNS-Pods nicht immer aggressiv genug ist, um Out of memory-Probleme für Ihre CoreDNS-Pods zu verhindern. In diesem Fall können Sie die coredns-autoscaler-ConfigMap direkt ändern. Bitte beachten Sie, dass eine einfache Erhöhung der Anzahl von CoreDNS-Pods, ohne die Grundursache des Out of memory-Problems zu beheben, möglicherweise nur einen temporären Fix bietet. Wenn auf den Knoten, auf denen die CoreDNS-Pods ausgeführt werden, nicht genügend Arbeitsspeicher verfügbar ist, wird das Erhöhen der Anzahl von CoreDNS-Pods nicht helfen. Möglicherweise müssen Sie weitere Untersuchungen durchführen und geeignete Lösungen implementieren, z. B. die Optimierung des Ressourcenverbrauchs, das Anpassen von Ressourcenanforderungen und Grenzwerten oder das Hinzufügen von mehr Arbeitsspeicher zu den Knoten.

CoreDNS verwendet horizontale Cluster-proportionale Autoskalierung für die automatische Pod-Skalierung. Die coredns-autoscaler-ConfigMap kann bearbeitet werden, um die Skalierungslogik für die Anzahl von CoreDNS-Pods zu konfigurieren. Die coredns-autoscaler-ConfigMap unterstützt derzeit zwei unterschiedliche ConfigMap-Schlüsselwerte linear und ladder, die zwei unterstützten Steuerungsmodi entsprechen. Der linear-Controller liefert eine Reihe von Replikaten im [min,max]-Bereich, der max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) ) entspricht. Der ladder-Controller berechnet die Anzahl der Replikate, indem er zwei verschiedene Schrittfunktionen konsultiert, eine für die Kernskalierung und eine andere für die Knotenskalierung, was den Höchstwert der beiden Replikate ergibt. Weitere Informationen zu den Steuerungsmodi und dem ConfigMap-Format finden Sie in der Upstream-Dokumentation.

Wichtig

Es werden mindestens 2 CoreDNS-Podreplikate pro Cluster empfohlen. Das Konfigurieren von mindestens 1 CoreDNS-Podreplikat kann zu Fehlern bei Vorgängen führen, bei denen ein Knotenausgleich erforderlich ist, z. B. Clusterupgradevorgänge.

Um die coredns-autoscaler-ConfigMap abzurufen, können Sie den kubectl get configmap coredns-autoscaler -n kube-system -o yaml-Befehl ausführen, der Folgendes zurückgeben wird:

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: "..."

Aktivieren der DNS-Abfrageprotokollierung

Fügen Sie der benutzerdefinierten CoreDNS -ConfigMap die folgende Konfiguration hinzu:

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

Wenden Sie die Konfigurationsänderungen an, und erzwingen Sie, dass CoreDNS die ConfigMap mithilfe der folgenden Befehle erneut lädt:

# Apply configuration changes
kubectl apply -f corednsms.yaml

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

Zeigen Sie die CoreDNS-Debugprotokollierung mit dem Befehl „kubectl logs“ an.
```
kubectl logs --namespace kube-system -l k8s-app=kube-dns
```

Nächste Schritte

In diesem Artikel wurden einige Beispielszenarios für die CoreDNS-Anpassung gezeigt. Informationen zum CoreDNS-Projekt finden Sie auf der Seite des CoreDNS-Upstream-Projekts.

Weitere Informationen zu den Kernnetzwerkkonzepten finden Sie unter Netzwerkkonzepte für Anwendungen in Azure Kubernetes Service (AKS).

Freigeben über