Konfigurieren von LocalDNS in Azure Kubernetes Service (AKS)

Gilt für: ✔️ AKS Automatic ✔️ AKS Standard

Für die meisten Produktionsworkloads ist AKS Automatic die empfohlene, produktionsreife Standardeinstellung für AKS. LocalDNS ist in AKS Automatic Clusters vorkonfiguriert. In AKS Standard hängt das LocalDNS-Verhalten von der Kubernetes-Version und dem vorhandenen LocalDNS-Profil des Knotenpools ab.

LocalDNS ist ein Feature in AKS, das die Leistung und Resilienz der DNS-Auflösung für Workloads verbessert, die in Ihrem Cluster ausgeführt werden. Durch den Betrieb eines DNS-Proxys auf jedem Knoten reduziert LocalDNS die Latenz von DNS-Abfragen, verbessert die Zuverlässigkeit bei vorübergehenden Netzwerkstörungen und bietet erweiterte Steuerungsmöglichkeiten für Caching und Weiterleitung, wenn Anpassungen erforderlich sind.

Informationen dazu, was LocalDNS ist, einschließlich Architekturdetails und Schlüsselfunktionen, finden Sie unter DNS-Auflösung in Azure Kubernetes Service (AKS).

Verhalten von AKS Automatic und AKS Standard LocalDNS

Kompatibilitätsprüfungen für den Preferred-Modus

Ab Kubernetes 1.37 weist AKS Standard geeigneten Knotenpools ohne explizites LocalDNS-Profil den Modus Preferred zu, wenn diese Pools erstellt oder aktualisiert werden. AKS behält explizit konfigurierte Profile bei.

Vor der ersten Aktivierung von LocalDNS im Preferred Modus überprüft AKS die folgenden Kompatibilitätsanforderungen. Wenn eine Anforderung nicht erfüllt ist, bleibt LocalDNS deaktiviert.

Sobald AKS LocalDNS im Preferred Modus aktiviert hat, bleibt sie während nachfolgenden nicht verknüpften Knotenpoolaktualisierungen aktiviert. Um sie zu deaktivieren, legen Sie den LocalDNS mode explizit auf Disabled.

Bewährte Methoden für die LocalDNS-Konfiguration

Berücksichtigen Sie bei der Implementierung von LocalDNS in Ihren AKS-Clustern die folgenden bewährten Methoden:

• Beginnen Sie mit einer minimalen Konfiguration: Beginnen Sie mit einer einfachen Konfiguration, die den Preferred Modus verwendet, um Ihre LocalDNS-Konfigurationssyntax zu überprüfen, bevor Sie in den Required Modus wechseln. Der Preferred Modus überprüft Ihre Konfiguration, ohne LocalDNS zu aktivieren, sodass Sie Konfigurationsfehler frühzeitig abfangen können, ohne dass sich dies auf den Cluster auswirkt.
• Implementieren Sie geeignete Zwischenspeicherungsstrategien: Konfigurieren Sie Cacheeinstellungen basierend auf Ihren Workloadmerkmalen:
  • Verwenden Sie für häufig geänderte Datensätze kürzere cacheDurationInSeconds Werte. Dabei ist es wichtig zu beachten, dass cacheDurationInSeconds als Obergrenze für den DNS-Eintrag TTL fungiert, dies aber nicht erhöht. Die resultierende TTL ist der kleinere Wert, der von Upstream zurückgegeben wird oder der im Cache-Plug-In festgelegt wird.
  • Verwenden Sie bei stabilen Einträgen längere Cachedauern, um DNS-Abfragen zu reduzieren.
  • Aktivieren Sie serveStale mit geeigneten Einstellungen, um den Dienst während DNS-Ausfällen aufrechtzuerhalten.
  • Das Caching mit LocalDNS erfolgt nach bestem Bemühen und garantiert keine veralteten Antworten. Der Cache ist in 256 Shards unterteilt und hat standardmäßig eine maximale Kapazität von 10 000 Einträgen, sodass jeder Shard etwa 39 Einträge aufnehmen kann. Wenn ein Shard voll ist und ein neuer Eintrag hinzugefügt werden muss, wird einer der vorhandenen Einträge nach dem Zufallsprinzip ausgewählt und entfernt. Es gibt keine Präferenz für ältere oder abgelaufene Einträge. Infolgedessen ist ein veralteter Datensatz möglicherweise nicht immer verfügbar, insbesondere bei hohem Abfragevolumen.
• Überwachen der DNS-Leistung: Überwachen Sie nach dem Aktivieren von LocalDNS die DNS-Leistung Ihrer Anwendung mithilfe von:
  • Metriken der Anwendungsleistung.
  • Knotenmetriken, um reduzierten Netzwerkdruck zu erkennen.
  • Protokolleinträge, wenn queryLogging auf Log gesetzt wird.
• Befolgen Sie das Prinzip der geringsten Rechte: Wenn Sie DNS-Weiterleitungsregeln konfigurieren, können Sie nur den Zugriff auf die erforderlichen DNS-Server und Domänen zulassen.
• Test vor der Produktionsbereitstellung: Testen Sie die LocalDNS-Konfiguration immer in einer Nicht-Produktionsumgebung, bevor Sie sie in Produktionscluster bereitstellen.
• Verwenden Sie Infrastruktur als Code (IaC): Speichern Sie Ihre localdnsconfig.json Datei in Ihrem Infrastruktur-Repository, und fügen Sie sie in Ihre AKS-Bereitstellungsvorlagen ein.
• Netzwerkkonfiguration für die TCP-Weiterleitung: Stellen Sie bei Verwendung von TCP für die DNS-Weiterleitung an VnetDNS sicher, dass Ihre Netzwerksicherheitsgruppen (Network Security Groups, NSGs), Firewalls oder NvAs (Network Virtual Appliances) den TCP-Datenverkehr zwischen CoreDNS/LocalDNS- und VnetDNS-Servern nicht blockieren.
• Vermeiden Sie es, sowohl NodeLocal DNSCache als auch LocalDNS zu aktivieren: Es wird nicht empfohlen, sowohl den Upstream-Kubernetes-NodeLocal-DNSCache als auch LocalDNS in Ihrem Knotenpool zu aktivieren. Während AKS diese Konfiguration nicht blockiert, wird der gesamte DNS-Datenverkehr über LocalDNS weitergeleitet, was zu unerwartetem Verhalten oder reduzierten Vorteilen von NodeLocal DNSCache führen kann.
• Stellen Sie keine TCP-Verbindungsgrenze auf dem vorgelagerten benutzerdefinierten DNS-Server fest, bevor Sie LocalDNS aktivieren: Wenn Sie LocalDNS in einem Knotenpool aktivieren, öffnet jeder Knoten langlebige TCP-Verbindungen von seinem lokalen DNS-Proxy zum Upstream-Resolver, statt der zuvor verwendeten kurzen UDP-Austausche. Wenn Ihr benutzerdefinierter DNS-Server (z. B. BIND, Unbound, Windows DNS oder eine Appliance eines Drittanbieters) mit einem festen Grenzwert für gleichzeitige TCP-Clientverbindungen konfiguriert ist, oder wenn Sie diesen Grenzwert basierend auf pre-LocalDNS-Datenverkehr angepasst haben, können die neuen TCP-Verbindungen von LocalDNS abgelehnt werden, was zu clusterweiten DNS-Auflösungsfehlern führt. Belassen Sie das Limit für TCP-Verbindungen auf einem großzügigen Standardwert, bevor Sie LocalDNS einschalten, überprüfen Sie die Anzahl der stabilen TCP-Verbindungen von Ihren AKS-Knoten nach der Aktivierung und passen Sie das Limit erst danach an, um Spielraum für das horizontale skalieren, Upgrades und Reimages zu haben.

Voraussetzungen

AKS Automatic-Cluster enthalten LocalDNS vorkonfiguriert. Die Voraussetzungen in diesem Abschnitt gelten hauptsächlich, wenn Sie das LocalDNS-Verhalten aktivieren oder anpassen, das in AKS Standard- und erweiterten Anpassungsszenarien am häufigsten verwendet wird.

• Sie müssen über einen vorhandenen AKS-Cluster mit Kubernetes-Versionen 1.31 und höher verfügen, um LocalDNS zu verwenden. Wenn Sie einen AKS-Cluster benötigen, können Sie einen mit Azure CLI, Azure PowerShell oder dem portal Azure erstellen.
• Dieser Artikel erfordert Azure CLI Version 2.80.0 und höher. Wenn Sie Azure Cloud Shell verwenden, ist die neueste Version bereits installiert.
• LocalDNS wird ausschließlich auf Knotenpools unterstützt, auf denen Azure Linux oder Ubuntu 22.04 und neuer läuft.
• Die für den Knotenpool verwendete SKU für virtuelle Computer (VM) muss mindestens 4 vCPUs (Cores) aufweisen, um LocalDNS zu unterstützen.

Aktivieren oder Anpassen von LocalDNS auf einem AKS-Cluster

Sie konfigurieren LocalDNS auf Der Knotenpoolebene in AKS, sodass Sie das Verhalten nach Workload und Umgebung anpassen können.

In AKS Automatic ist LocalDNS bereits vorkonfiguriert, daher ist dieser Abschnitt in erster Linie für die Anpassung vorgesehen.

Verwenden Sie in AKS Standard diesen Abschnitt, um LocalDNS zu aktivieren und zu konfigurieren.

Überprüfen des benutzerdefinierten DNS vor dem Aktivieren von LocalDNS

Wenn Ihr virtuelles Netzwerk benutzerdefinierte DNS-Server verwendet, testen Sie beide DNS-Transporte von einem AKS-Knoten, bevor Sie LocalDNS aktivieren:

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

Beide Befehle müssen eine gültige Antwort zurückgeben. Wenn UDP erfolgreich ist, aber TCP-Zeitüberschreitungen auftreten, aktivieren Sie LocalDNS erst, wenn TCP-Port 53 über den vollständigen Netzwerkpfad zulässig ist und der benutzerdefinierte DNS-Server so konfiguriert ist, dass TCP-Abfragen akzeptiert werden.

Aktivieren von LocalDNS in einem Knotenpool

Dieser Schritt gilt in der Regel für AKS Standard. AKS Automatic enthält bereits vorkonfiguriertes LocalDNS.

Verwenden Sie zum Aktivieren von LocalDNS während der Erstellung des Knotenpools den folgenden Befehl mit Ihrer benutzerdefinierten Konfigurationsdatei:

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

Verwenden Sie zum Aktivieren von LocalDNS in einem vorhandenen Knotenpool den folgenden Befehl mit der benutzerdefinierten Konfigurationsdatei:

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

Deaktivieren von LocalDNS in einem Knotenpool

Das Deaktivieren von LocalDNS ist ein erweiterter Vorgang und wird in der Regel nicht für automatische AKS-Produktionsstandardwerte empfohlen, es sei denn, Sie haben eine validierte Ausnahme.

Um LocalDNS für einen Knotenpool zu deaktivieren, müssen Sie ihre localdnsconfig.json Datei aktualisieren, indem Sie die mode Eigenschaft auf Disabledfestlegen. Diese Änderung weist AKS an, den lokalen DNS-Proxy auf allen Knoten im angegebenen Pool zu deaktivieren, wobei die DNS-Auflösung auf das Standardclusterverhalten zurückgesetzt wird. Wenden Sie sie nach dem Aktualisieren der Konfigurationsdatei mithilfe der Azure CLI auf den Knotenpool an, um sicherzustellen, dass die Änderung wirksam wird.

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

Überprüfen des LocalDNS-Vorgangs

In AKS Automatic bestätigt die Überprüfung, dass die vorkonfigurierte LocalDNS-Baseline für Ihre Workloads aktiv ist. In AKS Standard bestätigt die Überprüfung Ihren LocalDNS-Rollout.

Sobald LocalDNS aktiviert ist, können Sie den Vorgang überprüfen, indem Sie DNS-Abfragen von Pods im angegebenen Knotenpool ausführen und das SERVER Feld in den Antworten überprüfen, um zu bestätigen, dass LocalDNS-Adressen zurückgegeben werden (169.254.10.10 oder 169.254.10.11).

Stellen Sie vor dem Ausführen der Überprüfungsschritte sicher, dass die folgenden Bedingungen erfüllt sind:

1. Sie haben kubectl installiert und für den Zugriff auf Ihren AKS-Cluster konfiguriert.
2. Ihr Benutzerkonto verfügt über ausreichende Berechtigungen zum Erstellen und Ausführen in Pods.
3. Der Knotenpool, in dem Sie LocalDNS überprüfen möchten, befindet sich im Zustand "Bereit" .
4. Auf das BusyBox-Image (busybox:1.28) kann über Ihre Clusterknoten zugegriffen werden.

Überprüfungsbeispiel:

1. Erstellen Sie einen Debug-Pod im Knotenpool, in dem LocalDNS aktiviert ist:

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

2. Sobald der Pod läuft, führen Sie den folgenden Befehl aus, um die DNS-Auflösung zu überprüfen.

   kubectl exec -it dnstest -- nslookup kubernetes.default
   

   Überprüfen Sie die Ausgabe. Wenn localDNS ordnungsgemäß funktioniert, sollte eine Antwort mit der Serveradresse 169.254.10.10 oder 169.254.10.11 angezeigt werden:

   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
   

Konfigurieren von LocalDNS

LocalDNS verwendet eine JSON-basierte Konfigurationsdatei localdnsconfig.json zum Definieren des DNS-Auflösungsverhaltens für jeden Knotenpool. Mit dieser Datei können Sie Betriebsmodi, Serverblöcke für verschiedene DNS-Domänen und Plug-In-Einstellungen wie Zwischenspeichern, Weiterleitung und Protokollierung angeben.

Standardkonfiguration für LocalDNS

In AKS Automatic ist LocalDNS vorkonfiguriert. Verwenden Sie Anpassungen nur, wenn Sie eine bestimmte Anforderung haben.

In AKS Standard ist diese Standardkonfiguration ein guter Ausgangspunkt.

Verwenden Sie beim Anpassen von LocalDNS das folgende Konfigurationsformat als Vorlage. Sie können zusätzliche Serverblöcke nach Bedarf definieren, aber das Hinzufügen nicht unterstützter oder nicht standardmäßiger Eigenschaften auf oberster Ebene zur Konfiguration führt zu Überprüfungsfehlern.

{
  "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"
    }
  }
}

Konfigurieren des mode für LocalDNS

LocalDNS kann in drei möglichen Modi aktiviert werden, die den Umfang der Erzwingung von LocalDNS für die Workload definieren:

• Required: LocalDNS wird für den Knotenpool erzwungen, wenn alle Voraussetzungen erfüllt sind. Wenn die Anforderungen nicht erfüllt sind, schlägt die Bereitstellung fehl.
• Disabled: Deaktiviert das lokale DNS-Feature, sodass DNS-Abfragen nicht lokal auf dem Knoten aufgelöst werden.
• Preferred: AKS überprüft, ob Ihre LocalDNS-Konfiguration syntaktisch korrekt ist, aktiviert jedoch nicht LocalDNS auf den Knoten. Das Anwenden dieses Modus löst jedoch weiterhin einen Knotenumbildvorgang aus, sodass Sie Ihre Konfiguration auf Fehler testen können, ohne die DNS-Auflösung in Ihrem Cluster zu beeinträchtigen.

Behalten Sie für Produktionsworkloads in AKS Automatic das vorkonfigurierte Verhalten von LocalDNS bei, sofern keine validierte Anforderung zur Anpassung besteht.

Die folgende Tabelle fasst das LocalDNS-Verhalten für jeden Modus und jede Kubernetes-Version zusammen:

Serverblöcke für LocalDNS

Die Standardkonfiguration gilt für Abfragen von Pods, die dnsPolicy:default verwenden (unter vnetDNSOverrides) und Pods, die dnsPolicy:ClusterFirst verwenden (unter kubeDNSOverrides). In jedem sind zwei Standardserverblöcke definiert: . und cluster.local.

• . stellt alle externen DNS-Abfragen von Pods dar, die versuchen, öffentliche oder nicht-Cluster-Domänen aufzulösen (z. B. microsoft.com).
• cluster.local steht für alle internen Kubernetes-Service-Discovery-Abfragen von Pods, die versuchen, Kubernetes-Servicenamen oder interne Clusterressourcen aufzulösen. Diese Abfragen werden über CoreDNS zur Auflösung innerhalb des Clusters weitergeleitet.

Unterstützte Plug-Ins für die LocalDNS-Konfiguration

Konfigurationsprüfungsregeln

Beachten Sie beim Erstellen der LocalDNS-Konfiguration diese Überprüfungsregeln, um Bereitstellungsfehler zu vermeiden:

• Einschränkungen der Stammzone (.) : Unter vnetDNSOverrideskann forwardDestination für die Stammzone nicht ClusterCoreDNS sein.
• Einschränkungen für Cluster.local-Zonen: Sowohl vnetDNSOverrides als auch kubeDNSOverrides, forwardDestination für cluster.local kann nicht VnetDNS sein.
• Protokoll- und ServeStale-Kompatibilität: Wenn protocol auf ForceTCP festgelegt ist, serveStale kann nicht auf Verify gesetz sein. Verwenden Sie stattdessen Immediate.

Erstellen eines benutzerdefinierten Serverblocks in LocalDNS

CoreDNS gleicht Abfragen mit einem bestimmten Serverblock ab, basierend auf einer genauen Übereinstimmung für die abgefragte Domäne und nicht für partielle Übereinstimmungen. Wenn Sie über die Notwendigkeit benutzerdefinierter Serverblöcke verfügen, können Sie diese ihrer LocalDNS-Konfiguration hinzufügen, indem Sie eine Datei namens localdnsconfig.json mit den hinzugefügten Konfigurationen erstellen.

Wenn Sie beispielsweise bestimmte DNS-Anforderungen beim Zugriff auf microsoft.com haben, können Sie den folgenden Serverblock verwenden:

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

Überwachen von LocalDNS

In AKS Automatic ist LocalDNS vorkonfiguriert. Beginnen Sie also mit der Basisüberprüfung, und überwachen Sie das Verhalten vor der Anwendung der benutzerdefinierten Optimierung.

LocalDNS macht Prometheus-Metriken verfügbar, die Sie für die Überwachung und Warnung verwenden können. Metriken werden am Port 9253 der Knoten-IP verfügbar gemacht.

Beispiel für eine Scrape-Konfiguration für Azure Managed Prometheus add-on as a 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']

Problembehandlung bei LocalDNS

DNS-Abfragen für bestimmte Domänen schlagen fehl

Wenn DNS-Abfragen für bestimmte Domänen nach dem Aktivieren von LocalDNS fehlschlagen:

1. Überprüfen Sie, ob in Ihrer localdnsconfig.json-Datei domänenspezifische Überschreibungen vorhanden sind, die möglicherweise falsch konfiguriert sind.

2. Versuchen Sie vorübergehend, domänenspezifische Überschreibungen zu entfernen und ausschließlich die Standardkonfiguration . zu verwenden.

3. Überprüfen Sie, ob das Problem sowohl mit dem User Datagram Protocol (UDP) als auch mit tcp (Transmission Control Protocol) auftritt, indem Sie die protocol Einstellung anpassen.

4. Überprüfen Sie die CoreDNS-Protokolle auf Timeouts für die LocalDNS-Adressen 169.254.10.10:53 oder 169.254.10.11:53. Testen Sie von einem betroffenen Knoten den upstream-benutzerdefinierten DNS-Server separat über UDP und TCP:

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

   Wenn UDP erfolgreich ist, TCP aber fehlschlägt, überprüfen Sie folgendes:

   • Der benutzerdefinierte DNS-Server lauscht auf TCP-Port 53.
   • NSGs und Firewalls lassen TCP-Port 53 vom AKS-Knotensubnetz zu.
   • NVAs und Routen verwerfen keinen TCP-DNS-Datenverkehr und routen ihn nicht asymmetrisch.

   Um LocalDNS für einen betroffenen Knotenpool zu deaktivieren, aktualisieren Sie den LocalDNS-Modus auf Disabled. Das Ändern eines aktivierten Pools in Disabled löst im Rahmen der Aktualisierung ein Reimage eines Knotens aus. Stellen Sie für einen dauerhaften Fix sicher, dass der benutzerdefinierte DNS-Server und der Netzwerkpfad DNS sowohl über UDP als auch tcp auf Port 53 unterstützen.

Aktualisieren von VNet-DNS-Servern für LocalDNS

Wenn Sie benutzerdefinierte DNS-Server direkt in der VNet-Konfiguration (mithilfe des Azure Portals oder der CLI) aktualisieren, wenden die AKS-Clusterknoten diese Änderungen nicht automatisch an. Durch das Aktualisieren von DNS-Einstellungen auf VNet-Ebene wird nur der Netzwerkressourcenanbieter (Network Resource Provider, NRP) informiert, der AKS-Ressourcenanbieter wird jedoch nicht benachrichtigt. Daher verwenden AKS-Knoten weiterhin die vorherigen DNS-Servereinstellungen, bis Sie weitere Maßnahmen ergreifen.

So stellen Sie sicher, dass AKS-Knoten die neuen VNet-DNS-Servereinstellungen übernehmen:

1. Aktualisieren Sie die VNet-DNS-Konfiguration nach Bedarf mithilfe des Azure-Portals oder der APIs.

2. Verwenden Sie den AKS-Ressourcenanbieter, um den Knotenpool neu zu abbilden, um sicherzustellen, dass die aktualisierten DNS-Einstellungen angewendet und beibehalten werden:

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

Dieser Prozess stellt sicher, dass der AKS-Ressourcenanbieter die DNS-Änderungen kennt und sie auf alle Knoten im Knotenpool anwendet.

Aktualisieren von Cilium-Netzwerkrichtlinien, um die DNS-Auflösung mit LocalDNS zuzulassen

Wenn Sie Cilium-Netzwerkrichtlinien in Ihrem Cluster bereitstellen, müssen Sie den Pod-Egress explizit auf die LocalDNS-IP-Adressen zulassen.

Netzwerkrichtlinien erzwingen ein Standardverweigerungsmodell für nicht angegebene Ziele, sodass DER DNS-Datenverkehr an LocalDNS blockiert wird, es sei denn, er ist explizit zulässig.

• Unter Azure CNI Powered by Cilium <=v1.16 mit k8s <=1.,31 kann dies durch eine CIDR-basierte Richtlinie erreicht werden.
• Unter Azure CNI Powered by Cilium >=v1.17 mit K8s >=1.32 kann eine Cilium-Netzwerkrichtlinie verwendet werden, die ausgehenden Datenverkehr zu Host-Entitäten erlaubt.

Informationen zu einer Cilium-Netzwerkrichtlinie, die den versionsübergreifenden Datenverkehr zulässt, finden Sie unter Wird AKS Local DNS mit Azure CNI Powered by Cilium unterstützt?

Verwandte Inhalte

• Was ist AKS Automatic?
• Erstellen eines automatischen AKS-Clusters
• LocalDNS in Azure Kubernetes Service (konzeptionell)
• Behandeln von Problemen mit LocalDNS in AKS
• CoreDNS-Anpassungshandbuch
• CoreDNS-Upstreamprojektseite
• Netzwerkkonzepte für Anwendungen in AKS