Freigeben über

Anpassen von CoreDNS mit Azure Kubernetes Service

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.

  1. 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.

  2. Erstellen Sie die ConfigMap mit dem Befehl „kubectl apply configmap“, und geben Sie den Namen Ihres YAML-Manifests an.

    kubectl apply -f corednsms.yaml

  3. 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

  4. 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.

  1. 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
    }

  2. Erstellen Sie die ConfigMap mit dem Befehl „kubectl apply configmap“, und geben Sie den Namen Ihres YAML-Manifests an.

    kubectl apply -f corednsms.yaml

  3. 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.

  1. 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
    }

  2. Erstellen Sie die ConfigMap mit dem Befehl „kubectl apply configmap“, und geben Sie den Namen Ihres YAML-Manifests an.

    kubectl apply -f corednsms.yaml

  3. 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.

  1. 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
    }

  2. Erstellen Sie die ConfigMap mit dem Befehl „kubectl apply configmap“, und geben Sie den Namen Ihres YAML-Manifests an.

    kubectl apply -f corednsms.yaml

  3. 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.

  1. 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
          }

  2. Erstellen Sie die ConfigMap mit dem Befehl „kubectl apply configmap“, und geben Sie den Namen Ihres YAML-Manifests an.

    kubectl apply -f corednsms.yaml

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

  1. 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:
    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. Erstellen Sie die ConfigMap mit dem Befehl „kubectl apply configmap“, und geben Sie den Namen Ihres YAML-Manifests an.

    kubectl apply -f corednsms.yaml

  3. 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 horizontalen Skalierung von CoreDNS-Pods

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

Vertikales Skalierungsverhalten von CoreDNS-Pods

CoreDNS ist ein wesentliches Add-On, das von AKS verwaltet und standardmäßig aktiviert ist. Um die Verfügbarkeit des CoreDNS-Dienstes aufrechtzuerhalten, verwendet CoreDNS die ursprünglich bereitgestellten Ressourcenanforderungen/-grenzen, wenn das Add-On-Autoscaling-Feature aktiviert wird, um zu verhindern, dass der CoreDNS-Pod-Neustartprozess zu einer Dienstunverfügbarkeit führt.

Für das von AKS verwaltete CoreDNS-Add-On werden die standardmäßigen CPU-Anforderungen/Grenzwerte auf 100m /3 Kerne festgelegt, und Speicheranforderungen/Grenzwerte bei 70Mi/500Mi. Basierend auf diesen Standardwerten beträgt das Anforderungs-zu-Limit-Verhältnis für die CPU ungefähr 1:30, und für den Arbeitsspeicher beträgt es etwa 1/7. Wenn die empfohlenen CPU-Anforderungen 500M groß sind, passt VPA die CPU-Grenzwerte auf 15 an, um dieses Verhältnis beizubehalten. Entsprechend passt VPA, wenn die empfohlenen Speicheranforderungen 700Mi sind, den Speichergrenzwert auf 5000Mi an.

VPA legt CoreDNS CPU- und Speichergrenzwerte auf große Werte fest, die auf der empfohlenen VPA-CPU-/Mem-Anforderung und dem von AKS definierten Anforderungs-zu-Limit-Verhältnis basieren. Diese Anpassungen sind von Vorteil für die Behandlung mehrerer Anforderungen während der Spitzenzeiten. Der Nachteil ist, dass CoreDNS möglicherweise alle CPU- und den Arbeitsspeicher verfügbaren Ressourcen auf dem Knoten verbrauchen kann, wenn die Spitzenbetriebszeit erreicht wird.

Es ist schwierig, einen einzigen idealen CPU- und Speicheranforderungen/Grenzwertewert festzulegen, um die Anforderungen von großem Cluster und kleinem Cluster gleichzeitig zu erfüllen. Durch die Aktivierung einer optimierten Add-On-Skalierung haben Sie die Flexibilität, die CoreDNS-CPU- und Speicheranforderungen/-grenzwerte anzupassen oder VPA für die automatische Skalierung von CoreDNS zu verwenden, um bestimmte Clusteranforderungen zu erfüllen. Im Folgenden sind einige Szenarien zu berücksichtigen:

  • Sie überlegen, ob VPA für Ihren CoreDNS-Dienst geeignet ist und nur die VPA-Empfehlungen anzeigen möchten. Sie können VPA für CoreDNS abschalten, indem Sie den VPA-Updatemodus auf Aus stellen, wenn VPA die Pods nicht automatisch aktualisieren soll. Passen Sie die Ressourcenkonfiguration in der Bereitstellung an, um die CPU-/Arbeitsspeicheranforderungen/-grenzwerte auf den gewünschten Wert festzulegen.
  • Sie erwägen die Verwendung von VPA, möchten aber das Verhältnis von Anforderungs-zu-Limit einschränken, sodass VPA die CPU- und Speichergrenze nicht gleichzeitig auf große Werte stoßen wird. Sie können Ressourcen in der Bereitstellung anpassen und den Wert für CPU- und Arbeitsspeicheranforderungen/Grenzwerte aktualisieren, um das Verhältnis von Anforderungs-zu-Limit auf 1/2 oder 1/3 beizubehalten.
  • Wenn eine VPA-Containerrichtlinie maxAllowed CPU und Arbeitsspeicher festlegt, überschreiten die empfohlenen Ressourcenanforderungen diese Grenzwerte nicht. Durch anpassen der Ressourcenkonfiguration können Sie die maxAllowed-Werte erhöhen oder verkleinern und die Empfehlungen von VPA steuern.

Weitere Informationen finden Sie unter Aktivieren der automatischen Skalierung von Add-Ons in Ihrem AKS-Cluster (Vorschau).

Aktivieren der DNS-Abfrageprotokollierung

  1. 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

  2. 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

  3. Zeigen Sie die CoreDNS-Debugprotokollierung mit dem Befehl „kubectl logs“ an.

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

Fehlerbehebung bei Ungleichgewicht im CoreDNS-Pod-Datenverkehr

Möglicherweise stellen Sie fest, dass ein oder zwei CoreDNS-Pods eine deutlich höhere CPU-Auslastung aufweisen und mehr DNS-Abfragen verarbeiten als andere, auch wenn mehrere CoreDNS-Pods in Ihrem AKS-Cluster ausgeführt werden. Dies ist ein bekanntes Problem in Kubernetes und kann dazu führen, dass einer der CoreDNS-Pods überlastet und abstürzt.

Diese ungleiche Verteilung von DNS-Abfragen wird in erster Linie durch UDP-Lastenausgleichseinschränkungen in Kubernetes verursacht. Die Plattform verwendet einen Fünf-Tupel-Hash (Quell-IP, Quellport, Ziel-IP, Zielport, Protokoll), um UDP-Datenverkehr zu verteilen. Wenn eine Anwendung denselben Quellport für DNS-Abfragen wiederverwendet, werden alle Abfragen dieses Clients an denselben CoreDNS-Pod weitergeleitet, was zu einer unverhältnismäßigen Menge an Datenverkehr führt.

Darüber hinaus verwenden einige Anwendungen verbindungspooling und wiederverwenden DNS-Verbindungen. Dieses Verhalten kann DNS-Abfragen weiter auf einen einzelnen CoreDNS-Pod konzentrieren, das Ungleichgewicht verschlimmern und das Risiko von Überlastung und potenziellen Abstürze erhöhen.

Überprüfen Ihrer Verteilung des CoreDNS-Poddatenverkehrs

Bevor Sie beginnen, führen Sie die Schritte im Abschnitt "Aktivieren der DNS-Abfrageprotokollierung " aus, um erforderliche DNS-Abfrageprotokolle von CoreDNS-Pods zu erfassen. Nachdem dies aktiviert ist, führen Sie die folgenden Befehle aus:

  1. Führen Sie den folgenden Befehl aus, um die Namen aller CoreDNS-Pods in Ihrem Cluster abzurufen:

    kubectl get pods --namespace kube-system -l k8s-app=kube-dns

  2. Überprüfen Sie die Protokolle für jeden CoreDNS-Pod, um DNS-Abfragemuster zu analysieren:

    kubectl logs --namespace kube-system <coredns-pod1>
kubectl logs --namespace kube-system <coredns-pod2>
# Repeat on all CoreDNS pods

  3. Suchen Sie nach wiederholten Client-IP-Adressen und Ports, die nur in den Protokollen eines einzelnen CoreDNS-Pods angezeigt werden. Dies weist darauf hin, dass DNS-Abfragen von bestimmten Clients nicht gleichmäßig verteilt werden.

    Beispielprotokolleintrag:

    [INFO] 10.244.0.247:5556 - 42621 "A IN myservice.default.svc.cluster.local. udp 28" NOERROR qr,aa,rd 106 0.000141s
    • 10.244.0.247: Client-IP-Adresse, die die DNS-Abfrage macht
    • 5556: Clientquellport
    • 42621: Abfrage-ID

    Wenn die gleiche Client-IP und derselbe Port wiederholt in den Protokollen eines pods angezeigt werden, bestätigt dies ein Datenverkehrsungleichgewicht.

Wenn Sie dieses Ungleichgewicht feststellen, kann Ihre Anwendung UDP-Quellports wiederverwenden oder ihre Verbindungen poolen. Basierend auf der Grundursache können Sie die folgenden Gegenmaßnahmen ergreifen:

  • Durch die Wiederverwendung des UDP-Quellports verursacht:

    Die Wiederverwendung des UDP-Quellports erfolgt, wenn eine Clientanwendung mehrere DNS-Abfragen vom gleichen UDP-Quellport sendet. Wenn dies das Problem ist, aktualisieren Sie Ihre Anwendungen oder DNS-Clients so, dass Quellports für jede DNS-Abfrage zufällig verteilt werden, wodurch Anforderungen gleichmäßiger über Pods verteilt werden.

  • Verursacht durch Verbindungspooling:
    Verbindungspools sind Mechanismen, die von Anwendungen verwendet werden, um vorhandene Netzwerkverbindungen wiederzuverwenden, anstatt für jede Anforderung eine neue Verbindung zu erstellen. Dies verbessert zwar die Effizienz, kann aber dazu führen, dass alle DNS-Abfragen einer Anwendung über dieselbe Verbindung gesendet und somit an denselben CoreDNS-Pod weitergeleitet werden. Um dies zu verringern, passen Sie die DNS-Verbindungsbehandlung Ihrer Anwendung an, indem Sie die Verbindungs-TTLs (Time to Live) oder die Randomisierung der Verbindungserstellung reduzieren und sicherstellen, dass Abfragen nicht auf einen einzelnen CoreDNS-Pod konzentriert sind.

Diese Änderungen können dazu beitragen, eine ausgewogenere DNS-Abfrageverteilung zu erzielen und das Risiko einer Überlastung einzelner Pods zu verringern.

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).