Beheben von PROBLEMEN bei der DNS-Auflösung in AKS

In diesem Artikel wird erläutert, wie Sie einen Problembehandlungsworkflow zum Beheben von DNS-Lösungsproblemen (Domain Name System) in Microsoft Azure Kubernetes Service (AKS) erstellen.

Voraussetzungen

• Das Kubernetes kubectl-Befehlszeilentool

  Hinweis: Führen Sie zum Installieren von Kubectl mithilfe der Azure CLI den Befehl "az aks install-cli " aus.

• Die Befehlszeilentool dig für die DNS-Suche

• Das Grep-Befehlszeilentool für die Textsuche

• Der Wireshark-Netzwerkpaketanalysator

Checkliste zur Problembehandlung

Die Behandlung von DNS-Problemen in AKS ist in der Regel ein komplexer Prozess. Sie können in den vielen verschiedenen Schritten leicht verloren gehen, ohne jemals einen klaren Weg vorwärts zu sehen. Um den Prozess einfacher und effektiver zu gestalten, verwenden Sie die "wissenschaftliche" Methode, um die Arbeit zu organisieren:

• Schritt 1. Sammeln Sie die Fakten.

• Schritt 2. Entwickeln Sie eine Hypothese.

• Schritt 3. Erstellen und Implementieren eines Aktionsplans.

• Schritt 4. Beobachten Sie die Ergebnisse, und ziehen Sie Schlussfolgerungen.

• Schritt 5. Wiederholen Sie den Vorgang nach Bedarf.

Problembehandlung Schritt 1: Sammeln der Fakten

Um den Kontext des Problems besser zu verstehen, sammeln Sie Fakten über das spezifische DNS-Problem. Mithilfe der folgenden Basisfragen als Ausgangspunkt können Sie die Art des Problems beschreiben, die Symptome erkennen und den Umfang des Problems identifizieren.

Frage	Mögliche Antworten
Wo schlägt die DNS-Auflösung fehl?	Schote Knoten Sowohl Pods als auch Knoten
Welche Art von DNS-Fehler erhalten Sie?	Timeout Kein solcher Host Anderer DNS-Fehler
Wie oft treten die DNS-Fehler auf?	Immer Zeitweilig In einem bestimmten Muster
Welche Datensätze sind betroffen?	Eine bestimmte Domäne Beliebige Domäne
Sind benutzerdefinierte DNS-Konfigurationen vorhanden?	Benutzerdefinierter DNS-Server, der im virtuellen Netzwerk konfiguriert ist Benutzerdefiniertes DNS für die CoreDNS-Konfiguration
Welche Leistungsprobleme wirken sich auf die Knoten aus?	Prozessor Gedächtnis E/A-Einschränkung
Welche Leistungsprobleme wirken sich auf die CoreDNS-Pods aus?	Prozessor Gedächtnis E/A-Einschränkung
Was verursacht DNS-Latenz?	DNS-Abfragen, die zu viel Zeit in Anspruch nehmen, um eine Antwort zu empfangen (mehr als fünf Sekunden)

Um bessere Antworten auf diese Fragen zu erhalten, folgen Sie diesem dreiteiligen Prozess.

Teil 1: Generieren von Tests auf verschiedenen Ebenen, die das Problem reproduzieren

Der DNS-Auflösungsprozess für Pods auf AKS umfasst viele Ebenen. Überprüfen Sie diese Ebenen, um das Problem zu isolieren. Die folgenden Ebenen sind typisch:

• CoreDNS-Pods
• CoreDNS-Dienst
• Knoten
• DNS des virtuellen Netzwerks

Um den Prozess zu starten, führen Sie Tests von einem Test-Pod für jede Ebene aus.

Testen der DNS-Auflösung auf CoreDNS-Pod-Ebene

1. Stellen Sie einen Test pod bereit, um DNS-Testabfragen auszuführen, indem Sie den folgenden Befehl ausführen:

   cat <<EOF | kubectl apply --filename -
   apiVersion: v1
   kind: Pod
   metadata:
     name: aks-test
   spec:
     containers:
     - name: aks-test
       image: debian:stable
       command: ["/bin/sh"]
       args: ["-c", "apt-get update && apt-get install -y dnsutils && while true; do sleep 1000; done"]
   EOF
   

2. Rufen Sie die IP-Adressen der CoreDNS-Pods ab, indem Sie den folgenden kubectl get-Befehl ausführen:

   kubectl get pod --namespace kube-system --selector k8s-app=kube-dns --output wide
   

3. Stellen Sie mithilfe des kubectl exec -it aks-test -- bash Befehls eine Verbindung mit dem Test pod her, und testen Sie die DNS-Auflösung für jede CoreDNS-Pod-IP-Adresse, indem Sie die folgenden Befehle ausführen:

   # Placeholder values
   FQDN="<fully-qualified-domain-name>"  # For example, "db.contoso.com"
   DNS_SERVER="<coredns-pod-ip-address>"
   
   # Test loop
   for i in $(seq 1 1 10)
   do
       echo "host= $(dig +short ${FQDN} @${DNS_SERVER})"
       sleep 1
   done
   

Weitere Informationen zur Problembehandlung von DNS-Auflösungsproblemen von der Podebene finden Sie unter Problembehandlung von DNS-Auflösungsfehlern innerhalb des Pods.

Testen der DNS-Auflösung auf CoreDNS-Dienstebene

1. Rufen Sie die IP-Adresse des CoreDNS-Diensts ab, indem Sie den folgenden kubectl get Befehl ausführen:

   kubectl get service kube-dns --namespace kube-system
   

2. Führen Sie auf dem Test pod die folgenden Befehle für die CoreDNS-Dienst-IP-Adresse aus:

   # Placeholder values
   FQDN="<fully-qualified-domain-name>"  # For example, "db.contoso.com"
   DNS_SERVER="<kubedns-service-ip-address>"
   
   # Test loop
   for i in $(seq 1 1 10)
   do
       echo "host= $(dig +short ${FQDN} @${DNS_SERVER})"
       sleep 1
   done
   

Testen der DNS-Auflösung auf Knotenebene

1. Stellen Sie eine Verbindung mit dem Knoten her.

2. Führen Sie den folgenden grep Befehl aus, um die Liste der vorgelagerten DNS-Server abzurufen, die konfiguriert sind:

   grep ^nameserver /etc/resolv.conf
   

3. Führen Sie die folgenden Textbefehle für jeden DNS aus, der im Knoten konfiguriert ist:

   # Placeholder values
   FQDN="<fully-qualified-domain-name>"  # For example, "db.contoso.com"
   DNS_SERVER="<dns-server-in-node-configuration>"
   
   # Test loop
   for i in $(seq 1 1 10)
   do
       echo "host= $(dig +short ${FQDN} @${DNS_SERVER})"
       sleep 1
   done
   

Testen der DNS-Auflösung auf der DNS-Ebene des virtuellen Netzwerks

Überprüfen Sie die DNS-Serverkonfiguration des virtuellen Netzwerks, und bestimmen Sie, ob die Server den betreffenden Eintrag auflösen können.

Teil 2: Überprüfen des Zustands und der Leistung von CoreDNS-Pods und Knoten

Überprüfen Sie die Gesundheit und Leistungsfähigkeit der CoreDNS-Pods

Sie können Befehle verwenden kubectl , um den Status und die Leistung von CoreDNS-Pods zu überprüfen. Führen Sie dazu die folgenden Schritte aus:

1. Vergewissern Sie sich, dass die CoreDNS-Pods laufen.

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

2. Überprüfen Sie, ob die CoreDNS-Pods überlastet sind:

   kubectl top pods -n kube-system -l k8s-app=kube-dns
   

   NAME                      CPU(cores)   MEMORY(bytes)
   coredns-dc97c5f55-424f7   3m           23Mi
   coredns-dc97c5f55-wbh4q   3m           25Mi
   

3. Rufen Sie die Knoten ab, die die CoreDNS-Pods hosten:

   kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].spec.nodeName}'
   

4. Stellen Sie sicher, dass die Knoten nicht überlastet sind:

   kubectl top nodes
   

5. Überprüfen Sie die Protokolle für die CoreDNS-Pods:

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

Hinweis

Um weitere Debuginformationen zu erhalten, aktivieren Sie ausführliche Protokolle in CoreDNS. Informationen hierzu finden Sie unter "Problembehandlung bei coreDNS-Anpassungen" in AKS.

Überprüfen Sie die Gesundheit und Leistung von Knoten

Möglicherweise stellen Sie zunächst Probleme mit der DNS-Auflösung als zwischendurch auftretende Fehler fest, z. B. Timeouts. Die Hauptursachen dieses Problems sind Ressourcenausschöpfung und E/A-Drosselung innerhalb von Knoten, die die CoreDNS-Pods oder den Client-Pod hosten.

Führen Sie den folgenden kubectl describe Befehl zusammen mit dem grep Befehl auf Ihren Knoten aus, um zu überprüfen, ob eine Ressourcenausschöpfung oder E/A-Drosselung auftritt. Mit dieser Reihe von Befehlen können Sie die Anforderungsanzahl überprüfen und mit dem Grenzwert für jede Ressource vergleichen. Wenn der Grenzwertprozentsatz für eine Ressource mehr als 100 Prozent beträgt, wird diese Ressource überkommissioniert.

kubectl describe node | grep -A5 '^Name:\|^Allocated resources:' | grep -v '.kubernetes.io\|^Roles:\|Labels:'

Der folgende Codeausschnitt zeigt die Beispielausgabe dieses Befehls:

Name:               aks-nodepool1-17046773-vmss00000m
--
Allocated resources:
  (Total limits might be more than 100 percent.)
  Resource           Requests           Limits
  --------           --------           ------
  cpu                250m (13 percent)  40m (2 percent)
  memory             420Mi (9 percent)  1762Mi (41 percent)
--
Name:               aks-nodepool1-17046773-vmss00000n
--
Allocated resources:
  (Total limits might be more than 100 percent.)
  Resource           Requests            Limits
  --------           --------            ------
  cpu                612m (32 percent)   8532m (449 percent)
  memory             804Mi (18 percent)  6044Mi (140 percent)
--
Name:               aks-nodepool1-17046773-vmss00000o
--
Allocated resources:
  (Total limits might be more than 100 percent.)
  Resource           Requests           Limits
  --------           --------           ------
  cpu                250m (13 percent)  40m (2 percent)
  memory             420Mi (9 percent)  1762Mi (41 percent)
--
Name:               aks-ubuntu-16984727-vmss000008
--
Allocated resources:
  (Total limits might be more than 100 percent.)
  Resource           Requests            Limits
  --------           --------            ------
  cpu                250m (13 percent)   40m (2 percent)
  memory             420Mi (19 percent)  1762Mi (82 percent)

Um ein besseres Bild der Ressourcennutzung auf Pod- und Knotenebene zu erhalten, können Sie auch Containereinblicke und andere cloudeigene Tools in Azure verwenden. Weitere Informationen finden Sie unter Überwachen von Kubernetes-Clustern mit Azure-Diensten und cloudeigenen Tools.

Teil 3: Analysieren des DNS-Datenverkehrs und Überprüfen der DNS-Auflösungsleistung

Die Analyse von DNS-Datenverkehr kann Ihnen helfen, zu verstehen, wie Ihr AKS-Cluster die DNS-Abfragen verarbeitet. Im Idealfall sollten Sie das Problem auf einem Test pod reproduzieren, während Sie den Datenverkehr von diesem Test pod und auf jedem der CoreDNS-Pods erfassen.

Es gibt zwei Hauptmethoden zum Analysieren des DNS-Datenverkehrs:

• Verwenden von Echtzeit-DNS-Analysetools, z. B. Inspektor Gadget, um den DNS-Datenverkehr in Echtzeit zu analysieren.
• Verwenden von Datenverkehrserfassungstools wie Retina Capture und Dumpy, um den DNS-Datenverkehr zu sammeln und mit einem Netzwerkpaketanalysetool wie Wireshark zu analysieren.

Beide Ansätze zielen darauf ab, die Integrität und Leistung von DNS-Antworten mithilfe von DNS-Antwortcodes, Antwortzeiten und anderen Metriken zu verstehen. Wählen Sie das, das Ihren Anforderungen am besten entspricht.

Echtzeit-DNS-Datenverkehrsanalyse

Sie können Inspektor Gadget verwenden, um den DNS-Datenverkehr in Echtzeit zu analysieren. Informationen zum Installieren von Inspektor Gadget auf Ihrem Cluster finden Sie unter Installieren des Inspektor Gadgets in einem AKS-Cluster.

Verwenden Sie den folgenden Befehl, um den DNS-Datenverkehr über alle Namespaces hinweg zu verfolgen:

# Get the version of Gadget
GADGET_VERSION=$(kubectl gadget version | grep Server | awk '{print $3}')
# Run the trace_dns gadget
kubectl gadget run trace_dns:$GADGET_VERSION --all-namespaces --fields "src,dst,name,qr,qtype,id,rcode,latency_ns"

Dabei --fields handelt es sich um eine durch Trennzeichen getrennte Liste von Feldern, die angezeigt werden sollen. In der folgenden Liste werden die Felder beschrieben, die im Befehl verwendet werden:

• src: Die Quelle der Anforderung mit Kubernetes-Informationen (<kind>/<namespace>/<name>:<port>).
• dst: Das Ziel der Anforderung mit Kubernetes-Informationen (<kind>/<namespace>/<name>:<port>).
• name: Der Name der DNS-Anforderung.
• qr: Das Abfrage-/Antwort-Flag.
• qtype: Der Typ der DNS-Anforderung.
• id: Die ID der DNS-Anforderung, die für die Übereinstimmung mit der Anforderung und Antwort verwendet wird.
• rcode: Der Antwortcode der DNS-Anforderung.
• latency_ns: Die Latenz der DNS-Anforderung.

Die Befehlsausgabe sieht wie folgt aus:

SRC                                  DST                                  NAME                        QR QTYPE          ID             RCODE           LATENCY_NS
p/default/aks-test:33141             p/kube-system/coredns-57d886c994-r2… db.contoso.com.             Q  A              c215                                  0ns
p/kube-system/coredns-57d886c994-r2… 168.63.129.16:53                     db.contoso.com.             Q  A              323c                                  0ns
168.63.129.16:53                     p/kube-system/coredns-57d886c994-r2… db.contoso.com.             R  A              323c           NameErr…           13.64ms
p/kube-system/coredns-57d886c994-r2… p/default/aks-test:33141             db.contoso.com.             R  A              c215           NameErr…               0ns
p/default/aks-test:56921             p/kube-system/coredns-57d886c994-r2… db.contoso.com.             Q  A              6574                                  0ns
p/kube-system/coredns-57d886c994-r2… p/default/aks-test:56921             db.contoso.com.             R  A              6574           NameErr…               0ns

Sie können das ID Feld verwenden, um zu identifizieren, ob eine Abfrage eine Antwort hat. Das RCODE Feld zeigt den Antwortcode der DNS-Anforderung an. Das LATENCY_NS Feld zeigt die Latenz der DNS-Anforderung in Nanosekunden an. Diese Felder können Ihnen helfen, die Integrität und Leistung von DNS-Antworten zu verstehen. Weitere Informationen zur Echtzeit-DNS-Analyse finden Sie unter Problembehandlung von DNS-Fehlern in einem AKS-Cluster in Echtzeit.

Erfassen von DNS-Datenverkehr

In diesem Abschnitt wird die Verwendung von Dumpy zum Sammeln von DNS-Datenverkehrsaufzeichnungen von jedem CoreDNS-Pod und einem Client-DNS-Pod (in diesem Fall der aks-test Pod) veranschaulicht.

Führen Sie den folgenden Befehl aus, um die Aufzeichnungen vom Testclient-Pod zu erfassen:

kubectl dumpy capture pod aks-test -f "-i any port 53" --name dns-cap1-aks-test

Führen Sie den folgenden Dumpy-Befehl aus, um Aufzeichnungen für die CoreDNS-Pods zu sammeln:

kubectl dumpy capture deploy coredns \
    -n kube-system \
    -f "-i any port 53" \
    --name dns-cap1-coredns

Im Idealfall sollten Sie Aufzeichnungen vornehmen, während sich das Problem reproduziert. Diese Anforderung bedeutet, dass unterschiedliche Erfassungen möglicherweise für unterschiedliche Zeitmengen ausgeführt werden, je nachdem, wie oft Sie das Problem reproduzieren können. Führen Sie die folgenden Befehle aus, um die Aufzeichnungen zu erfassen:

mkdir dns-captures
kubectl dumpy export dns-cap1-aks-test ./dns-captures
kubectl dumpy export dns-cap1-coredns ./dns-captures -n kube-system

Führen Sie den folgenden Dumpy-Befehl aus, um die Dumpy-Pods zu löschen:

kubectl dumpy delete dns-cap1-coredns -n kube-system
kubectl dumpy delete dns-cap1-aks-test

Um alle CoreDNS-Pod-Aufzeichnungen zusammenzuführen, verwenden Sie das Befehlszeilentool mergecap zum Zusammenführen von Aufnahmedateien. Das mergecap Tool ist im Wireshark-Netzwerkpaketanalysetool enthalten. Führen Sie den folgenden Befehl mergecap aus:

mergecap -w coredns-cap1.pcap dns-cap1-coredns-<coredns-pod-name-1>.pcap dns-cap1-coredns-<coredns-pod-name-2>.pcap [...]

DNS-Paketanalyse für einen einzelnen CoreDNS-Pod

Nachdem Sie Ihre Datenverkehrserfassungsdateien generiert und zusammengeführt haben, können Sie eine DNS-Paketanalyse der Aufnahmedateien in Wireshark durchführen. Führen Sie die folgenden Schritte aus, um die Paketanalyse für den Datenverkehr eines einzelnen CoreDNS-Pods anzuzeigen:

1. Wählen Sie "Start" aus, geben Sie "Wireshark" ein, und wählen Sie dann "Wireshark " in den Suchergebnissen aus.

2. Wählen Sie im Fenster "Wireshark " das Menü "Datei " und dann " Öffnen" aus.

3. Navigieren Sie zu dem Ordner, der Ihre Aufnahmedateien enthält, wählen Sie dns-cap1-db-check-db-check-pod-name.pcap<> (die clientseitige Aufnahmedatei für einen einzelnen CoreDNS-Pod) aus, und wählen Sie dann die Schaltfläche "Öffnen" aus.

4. Wählen Sie das Menü "Statistik" und dann DNS aus. Das Dialogfeld "Wireshark - DNS " wird angezeigt und zeigt eine Analyse des DNS-Datenverkehrs an. Der Inhalt des Dialogfelds wird in der folgenden Tabelle angezeigt.

   Thema /Artikel	Anzahl	Durchschnitt	Min Val	Max Val	Geschwindigkeit (ms)	Prozent	Impulsrate	Start der Burst
   ▾ Gesamtpakete	1066				0.0017	100 %	0.1200	0.000
   ▾ rcode	1066				0.0017	100.00%	0.1200	0.000
   Serverfehler	17				0.0000	1.59%	0.0100	99.332
   Kein solcher Name	353				0.0006	33.11%	0.0400	0.000
   Kein Fehler	696				0.0011	65.29%	0,0800	0.000
   ▾ opcodes	1066				0.0017	100.00%	0.1200	0.000
   Standardabfrage	1066				0.0017	100.00%	0.1200	0.000
   ▾ Abfrage/Antwort	1066				0.0017	100.00%	0.1200	0.000
   Antwort	531				0.0009	49.81%	0.0600	0.000
   Abfrage	535				0.0009	50.19%	0.0600	0.000
   ▾ Abfragetyp	1066				0.0017	100.00%	0.1200	0.000
   AAAA	167				0.0003	15.67%	0.0200	0.000
   Ein	899				0.0015	84.33%	0.1000	0.000
   ▾ Klasse	1066				0.0017	100.00%	0.1200	0.000
   IN	1066				0.0017	100.00%	0.1200	0.000
   ▾ Servicestatistiken	0				0.0000	100 %	-	-
   Anforderungsantwortzeit (msec)	531	184.42	0.067000	6308.503906	0.0009		0.0600	0.000
   Nr. von unerwünschten Antworten	0				0.0000		-	-
   Nr. von erneuten Übertragungen	0				0.0000		-	-
   ▾ Antwortstatistiken	0				0.0000	100 %	-	-
   Nr. von Fragen	1062	1.00	1	1	0.0017		0.1200	0.000
   Nr. von Behörden	1062	0.82	0	1	0.0017		0.1200	0.000
   Nr. Antworten	1062	0,15	0	1	0.0017		0.1200	0.000
   Nr. von Zusatzartikeln	1062	0,00	0	0	0.0017		0.1200	0.000
   ▾ Abfragestatistiken	0				0.0000	100 %	-	-
   Qname Len	535	32,99	14	66	0.0009		0.0600	0.000
   ▾ Label-Statistiken	0				0.0000		-	-
   4. Ebene oder mehr	365				0.0006		0.0400	0.000
   3. Ebene	170				0.0003		0.0200	0.000
   2. Ebene	0				0.0000		-	-
   1. Ebene	0				0.0000		-	-
   Größe der Nutzdaten	1066	92.87	32	194	0.0017	100 %	0.1200	0.000

Das Dialogfeld "DNS-Analyse" in Wireshark zeigt insgesamt 1.066 Pakete an. Von diesen Paketen verursachten 17 (1,59 Prozent) einen Serverfehler. Darüber hinaus betrug die maximale Antwortzeit 6.308 Millisekunden (6,3 Sekunden), und für 0,38 Prozent der Abfragen wurde keine Antwort empfangen. (Diese Summe wurde berechnet, indem die 49,81 Prozent der Pakete subtrahiert wurden, die Antworten von den 50,19 Prozent der Pakete enthielten, die Abfragen enthielten.)

Wenn Sie als Anzeigefilter in Wireshark eingeben (dns.flags.response == 0) && ! dns.response_in , zeigt dieser Filter DNS-Abfragen an, die keine Antwort erhalten haben, wie in der folgenden Tabelle gezeigt.

Nein.	Uhrzeit	Quelle	Bestimmungsort	Protokoll	Länge	Info
225	2024-04-01 16:50:40.000520	10.0.0.21	172.16.0.10	Domain Name System (DNS)	80	Standardabfrage 0x2c67 AAAA-db.contoso.com
426	2024-04-01 16:52:47.419907	10.0.0.21	172.16.0.10	Domain Name System (DNS)	132	Standardabfrage 0x8038 A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net
693	2024-04-01 16:55:23.105558	10.0.0.21	172.16.0.10	Domain Name System (DNS)	132	Standard-Abfrage 0xbcb0 A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net
768	2024-04-01 16:56:06.512464	10.0.0.21	172.16.0.10	Domain Name System (DNS)	80	Standard-Datenbankabfrage 0xe330 A db.contoso.com

Darüber hinaus zeigt die Wireshark-Statusleiste den Text Pakete: 1066 - Angezeigt: 4 (0,4%). Diese Informationen bedeuten, dass vier der 1.066 Pakete oder 0,4 Prozent DNS-Abfragen waren, die nie eine Antwort erhalten haben. Dieser Prozentsatz entspricht im Wesentlichen der 0,38 Prozent Gesamtsumme, die Sie zuvor berechnet haben.

Wenn Sie den Anzeigefilter in dns.time >= 5"" ändern, zeigt der Filter Abfrageantwortpakete an, die fünf Sekunden oder mehr empfangen wurden, wie in der aktualisierten Tabelle dargestellt.

Nein.	Uhrzeit	Quelle	Bestimmungsort	Protokoll	Länge	Info	SourcePort	Zusätzliche RRs	DNS-Antwortzeit
213	2024-04-01 16:50:32.644592	172.16.0.10	10.0.0.21	Domain Name System (DNS)	132	Standardabfrage 0x9312 Serverfehler A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net	53	0	6.229941
320	2024-04-01 16:51:55.053896	172.16.0.10	10.0.0.21	Domain Name System (DNS)	80	Standardabfrage 0xe5ce Serverfehler A db.contoso.com	53	0	6.065555
328	2024-04-01 16:51:55.113619	172.16.0.10	10.0.0.21	Domain Name System (DNS)	132	Standardabfrage 0x6681 Serverfehler A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net	53	0	6.029641
335	2024-04-01 16:52:02.553811	172.16.0.10	10.0.0.21	Domain Name System (DNS)	80	Standardabfrage 0x6cf6 Serverfehler A db.contoso.com	53	0	6,500504
541	2024-04-01 16:53:53.423838	172.16.0.10	10.0.0.21	Domain Name System (DNS)	80	Standardabfrage 0x07b3 Serverfehler AAAA-db.contoso.com	53	0	6.022195
553	2024-04-01 16:54:05.165234	172.16.0.10	10.0.0.21	Domain Name System (DNS)	132	Standardanfrage 0x1ea0 Serverfehler A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net	53	0	6.007022
774	2024-04-01 16:56:17.553531	172.16.0.10	10.0.0.21	Domain Name System (DNS)	80	Standardabfrage 0xa20f Serverfehler AAAA-db.contoso.com	53	0	6.014926
891	2024-04-01 16:56:44.442334	172.16.0.10	10.0.0.21	Domain Name System (DNS)	132	Standardabfrage 0xa279 Serverfehler A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net	53	0	6.044552

Nachdem Sie den Anzeigefilter geändert haben, wird die Statusleiste aktualisiert, um den Text "Pakete: 1066 - Angezeigt: 8 (0,8%)" anzuzeigen. Daher waren acht der 1.066 Pakete oder 0,8 Prozent DNS-Antworten, die fünf Sekunden oder mehr benötigten, um empfangen zu werden. In den meisten Clients wird jedoch erwartet, dass der Standardmäßige DNS-Timeoutwert fünf Sekunden beträgt. Diese Erwartung bedeutet, dass der Client, obwohl die CoreDNS-Pods die acht Antworten verarbeitet und übermittelt haben, bereits die Sitzung beendet hat, indem eine "Timeout"-Fehlermeldung ausgegeben wurde. Die Spalte "Info" in den gefilterten Ergebnissen zeigt, dass alle acht Pakete einen Serverfehler verursacht haben.

DNS-Paketanalyse für alle CoreDNS-Pods

Öffnen Sie in Wireshark die Aufnahmedatei der CoreDNS-Pods, die Sie zuvor zusammengeführt haben (coredns-cap1.pcap), und öffnen Sie dann die DNS-Analyse, wie im vorherigen Abschnitt beschrieben. Es wird ein Wireshark-Dialogfeld angezeigt, in dem die folgende Tabelle angezeigt wird.

Thema /Artikel	Anzahl	Durchschnitt	Min Val	Max Val	Geschwindigkeit (ms)	Prozent	Impulsrate	Start der Burst
▾ Gesamtpakete	4540233				7.3387	100 %	84.7800	592.950
▾ rcode	4540233				7.3387	100.00%	84.7800	592.950
Serverfehler	121781				0.1968	2.68%	8.4600	599.143
Kein solcher Name	574658				0.9289	12,66 %	10,9800	592.950
Kein Fehler	3843794				6,2130	84.66%	73.2500	592.950
▾ opcodes	4540233				7.3387	100.00%	84.7800	592.950
Standardabfrage	4540233				7.3387	100.00%	84.7800	592.950
▾ Abfrage/Antwort	4540233				7.3387	100.00%	84.7800	592.950
Antwort	2135116				3.4512	47.03%	39.0400	581.680
Abfrage	2405117				3,8876	52.97%	49.1400	592.950
▾ Abfragetyp	4540233				7.3387	100.00%	84.7800	592.950
SRV	3647				0.0059	0.08%	0.1800	586.638
PTR (PTR)	554630				0.8965	12.22%	11.5400	592.950
NS	15918				0.0257	0,35 %	0.7200	308.225
MX	393016				0.6353	8.66%	7.9700	426.930
AAAA	384032				0.6207	8,46 %	8.4700	438.155
Ein	3188990				5.1546	70.24%	57,9600	592.950
▾ Klasse	4540233				7.3387	100.00%	84.7800	592.950
IN	4540233				7.3387	100.00%	84.7800	592.950
▾ Servicestatistiken	0				0.0000	100 %	-	-
Anforderungsantwortzeit (msec)	2109677	277.18	0.020000	12000.532227	3.4100		38.0100	581.680
Nr. von unerwünschten Antworten	25402				0.0411		5.1400	587.832
Nr. von erneuten Übertragungen	37				0.0001		0.0300	275.702
▾ Antwortstatistiken	0				0.0000	100 %	-	-
Nr. von Fragen	4244830	1.00	1	1	6.8612		77.0500	581.680
Nr. von Behörden	4244830	0.39	0	11	6.8612		77.0500	581.680
Nr. Antworten	4244830	1.60	0	22	6,8612		77.0500	581.680
Nr. von Zusatzartikeln	4244830	0,29	0	26	6.8612		77.0500	581.680
▾ Abfragestatistiken	0				0.0000	100 %	-	-
Qname Len	2405117	20,42	2	113	3,8876		49.1400	592.950
▾ Label-Statistiken	0				0.0000		-	-
4. Ebene oder mehr	836034				1.3513		16.1900	592.950
3. Ebene	1159513				1.8742		23.8900	592.950
2. Ebene	374182				0.6048		8.7800	592.955
1. Ebene	35388				0.0572		0.9200	294.492
Größe der Nutzdaten	4540233	89.87	17	1128	7.3387	100 %	84.7800	592.950

Das Dialogfeld gibt an, dass insgesamt rund 4,5 Millionen (4.540.233) Pakete vorhanden waren, von denen 2,68 Prozent einen Serverausfall verursachten. Der Unterschied bei Abfrage- und Antwortpaketprozentsätzen zeigt, dass 5,94 Prozent der Abfragen (52,97 Prozent minus 47,03 Prozent) keine Antwort erhalten haben. Die maximale Reaktionszeit betrug 12 Sekunden (12.000,532227 Millisekunden).

Wenn Sie den Anzeigefilter für Abfrageantworten anwenden, die fünf Sekunden oder mehr (dns.time >= 5) dauerten, geben die meisten Pakete in den Filterergebnissen an, dass ein Serverfehler aufgetreten ist. Dies liegt wahrscheinlich an einem Clientfehler "Timeout".

Die folgende Tabelle enthält eine Zusammenfassung der Erfassungsergebnisse.

Erfassen von Überprüfungskriterien	Ja	Nein
Der Unterschied zwischen DNS-Abfragen und Antworten überschreitet zwei Prozent.	☑	☐
DIE DNS-Latenz beträgt mehr als eine Sekunde.	☑	☐

Problembehandlung schritt 2: Entwickeln einer Hypothese

In diesem Abschnitt werden allgemeine Problemtypen kategorisiert, um potenzielle Probleme einzugrenzen und Komponenten zu identifizieren, die Möglicherweise Anpassungen erfordern. Mit diesem Ansatz wird die Grundlage für die Schaffung eines gezielten Aktionsplans festgelegt, um diese Probleme effektiv zu beheben und zu lösen.

Allgemeine DNS-Antwortcodes

In der folgenden Tabelle sind die am häufigsten verwendeten DNS-Rückgabecodes zusammengefasst.

DNS-Rückgabecode	DNS-Rückmeldung	BESCHREIBUNG
RCODE:0	NOERROR	Die DNS-Abfrage wurde erfolgreich abgeschlossen.
RCODE:1	FORMERR	Es ist ein DNS-Abfrageformatfehler vorhanden.
RCODE:2	SERVFAIL	Der Server hat die DNS-Anforderung nicht abgeschlossen.
RCODE:3	NXDOMAIN	Der Domänenname ist nicht vorhanden.
RCODE:5	REFUSED	Der Server hat sich geweigert, die Abfrage zu beantworten.
RCODE:8	NOTAUTH	Der Server ist nicht autoritativ für die Zone.

Allgemeine Problemtypen

In der folgenden Tabelle sind Problemtypkategorien aufgeführt, mit denen Sie die Problemsymptome aufteilen können.

Problemtyp	BESCHREIBUNG
Leistung	Leistungsprobleme bei der DNS-Auflösung können zeitweilige Fehler verursachen, z. B. Timeout-Fehler aus der Sicht eines Clients. Diese Probleme können auftreten, weil Knoten eine Ressourcenauslastung oder E/A-Drosselung erfahren. Darüber hinaus können Einschränkungen für Computeressourcen in CoreDNS-Pods die Auflösungslatenz verursachen. Wenn die CoreDNS-Latenz im Laufe der Zeit hoch ist oder erhöht wird, kann dies auf ein Ladeproblem hinweisen. Wenn CoreDNS-Instanzen überlastet sind, treten möglicherweise Probleme bei der DNS-Namensauflösung und -verzögerungen auf, oder es treten Probleme in Workloads und kubernetes internen Diensten auf.
Konfiguration	Konfigurationsprobleme können zu einer falschen DNS-Auflösung führen. In diesem Fall können NXDOMAIN- oder "Zeitüberschreitung"-Fehler auftreten. Falsche Konfigurationen können in CoreDNS, Knoten, Kubernetes, Routing, virtuelles Netzwerk-DNS, private DNS-Zonen, Firewalls, Proxys usw. auftreten.
Netzwerkkonnektivität	Netzwerkkonnektivitätsprobleme können sich auf die Pod-zu-Pod-Konnektivität (Ost-West-Datenverkehr) oder die Pod-and-Node-Konnektivität mit externen Ressourcen (Nord-Süd-Datenverkehr) auswirken. Dieses Szenario kann zu Timeout-Fehlern führen. Die Konnektivitätsprobleme können auftreten, wenn die CoreDNS-Dienstendpunkte nicht auf dem neuesten Stand sind (z. B. aufgrund von Kube-Proxy-Problemen, Routingproblemen, Paketverlust usw.). Die Abhängigkeit externer Ressourcen in Kombination mit Verbindungsproblemen (z. B. Abhängigkeit von benutzerdefinierten DNS-Servern oder externen DNS-Servern) kann ebenfalls zum Problem beitragen.

Erforderliche Eingaben

Bevor Sie eine Hypothese von wahrscheinlichen Ursachen für das Problem formulieren, fassen Sie die Ergebnisse aus den vorherigen Schritten des Problembehandlungsworkflows zusammen.

Sie können die Ergebnisse mithilfe der folgenden Tabellen erfassen.

Ergebnisse der Basisfragebogenvorlage

Frage	Mögliche Antworten
Wo schlägt die DNS-Auflösung fehl?	☐ Schote ☐ Knoten ☐ Pod und Knoten
Welche Art von DNS-Fehler erhalten Sie?	☐ Zeitüberschreitung ☐ NXDOMAIN ☐ Anderer DNS-Fehler
Wie oft treten die DNS-Fehler auf?	☐ Immer ☐ Zeitweise ☐ In einem bestimmten Muster
Welche Datensätze sind betroffen?	☐ Eine bestimmte Domäne ☐ Beliebige Domäne
Sind benutzerdefinierte DNS-Konfigurationen vorhanden?	☐ Benutzerdefinierte DNS-Server in einem virtuellen Netzwerk ☐ Benutzerdefinierte CoreDNS-Konfiguration

Ergebnisse von Tests auf unterschiedlichen Ebenen

Lösungstestergebnisse	Werk	Gescheitert
Von Pod zu CoreDNS-Dienst	☐	☐
Von Pod zu CoreDNS-Pod-IP-Adresse	☐	☐
Von Pod zu Azure internal DNS	☐	☐
Von Pod zu virtuellem Netzwerk-DNS	☐	☐
Vom Knoten zum internen Azure-DNS	☐	☐
Von Knoten zu virtuellem Netzwerk-DNS	☐	☐

Ergebnisse der Gesundheit und Leistung der Knoten und der CoreDNS-Pods

Ergebnisse der Leistungsüberprüfung	Gesund	Ungesund
Knotenleistung	☐	☐
Leistung von CoreDNS-Pods	☐	☐

Ergebnisse von Datenverkehrserfassungen und DNS-Auflösungsleistung

Erfassen von Überprüfungskriterien	Ja	Nein
Der Unterschied zwischen DNS-Abfragen und Antworten überschreitet zwei Prozent.	☐	☐
DIE DNS-Latenz beträgt mehr als eine Sekunde.	☐	☐

Zuordnen erforderlicher Eingaben zu Problemtypen

Um Ihre erste Hypothese zu entwickeln, ordnen Sie die einzelnen Ergebnisse aus den erforderlichen Eingaben einem oder mehreren der Problemtypen zu. Indem Sie diese Ergebnisse im Kontext von Problemtypen analysieren, können Sie Hypothesen über die potenziellen Ursachen der DNS-Lösungsprobleme entwickeln. Anschließend können Sie einen Aktionsplan für gezielte Untersuchung und Problembehandlung erstellen.

Zeiger zur Fehlertypzuordnung

• Wenn Testergebnisse DNS-Auflösungsfehler beim CoreDNS-Dienst anzeigen oder Fehler wie "Zeitüberschreitung" beim Versuch, bestimmte Endpunkte zu erreichen, besteht möglicherweise ein Problem mit der Konfiguration oder der Konnektivität.

• Anzeichen für einen Engpass bei Berechnungsressourcen auf der Ebene eines CoreDNS-Pods oder Knotens könnten auf Leistungsprobleme hindeuten.

• DNS-Erfassungen, die einen erheblichen Konflikt zwischen DNS-Abfragen und DNS-Antworten aufweisen, können darauf hinweisen, dass Pakete verloren gehen. Dieses Szenario schlägt vor, dass Konnektivitäts- oder Leistungsprobleme auftreten.

• Das Vorhandensein von benutzerdefinierten Konfigurationen auf virtueller Netzwerkebene oder Kubernetes-Ebene kann Setups enthalten, die nicht wie erwartet mit AKS und CoreDNS funktionieren.

Problembehandlung in Schritt 3: Erstellen und Implementieren eines Aktionsplans

Sie sollten jetzt über genügend Informationen verfügen, um einen Aktionsplan zu erstellen und zu implementieren. Die folgenden Abschnitte enthalten zusätzliche Empfehlungen, um Ihren Plan für bestimmte Problemtypen zu formulieren.

Leistungsprobleme

Wenn Sie mit Problemen bei der DNS-Auflösungsleistung zu tun haben, überprüfen und implementieren Sie die folgenden bewährten Methoden und Hinweise.

Beste Praxis	Beratung
Richten Sie einen dedizierten Systemknotenpool ein, der die Mindestanforderungen an die Größe erfüllt.	Verwalten von Systemknotenpools in Azure Kubernetes Service (AKS)
Um datenträger-E/A-Drosselung zu vermeiden, verwenden Sie Knoten mit ephemeren Betriebssystemdatenträgern.	Standardgröße des Betriebssystemdatenträgers und GitHub-Problem 1373 in Azure AKS
Befolgen Sie die bewährten Methoden für das Ressourcenmanagement von Workloads innerhalb der Knoten.	Bewährte Anwendungsentwicklermethoden zum Verwalten von Ressourcen in Azure Kubernetes Service (AKS)

Wenn die DNS-Leistung nach dem Vornehmen dieser Änderungen immer noch nicht gut genug ist, erwägen Sie die Verwendung von Node Local DNS.

Konfigurationsprobleme

Je nach Komponente sollten Sie die Auswirkungen des jeweiligen Setups überprüfen und verstehen. In der folgenden Liste der komponentenspezifischen Dokumentation finden Sie Konfigurationsdetails:

• Kubernetes DNS-Konfigurationsoptionen
• Benutzerdefinierte Konfigurationsoptionen für AKS CoreDNS
• Private DNS-Zonen fehlen eine virtuelle Netzwerkverbindung

Probleme mit der Netzwerkkonnektivität

• Fehler, die die ContainerNetzwerkschnittstelle (Container Networking Interface, CNI) oder andere Kubernetes- oder Betriebssystemkomponenten umfassen, erfordern in der Regel interventionen von der AKS-Unterstützung oder der AKS-Produktgruppe.

• Infrastrukturprobleme, z. B. Hardwarefehler oder Hypervisorprobleme, erfordern möglicherweise die Zusammenarbeit von Infrastruktursupportteams. Alternativ könnten diese Probleme über selbstheilende Eigenschaften verfügen.

Problembehandlung Schritt 4: Beobachten von Ergebnissen und Ziehen von Schlussfolgerungen

Beobachten Sie die Ergebnisse der Implementierung Ihres Aktionsplans. An diesem Punkt sollte Ihr Aktionsplan in der Lage sein, das Problem zu beheben oder zu mildern.

Problembehandlung in Schritt 5: Wiederholen Sie nach Bedarf

Wenn das Problem durch diese Schritte zur Problembehandlung nicht behoben wird, wiederholen Sie die Schritte zur Problembehandlung nach Bedarf.

Haftungsausschluss für Informationen Dritter

Die in diesem Artikel erläuterten Produkte von Drittanbietern werden von Unternehmen hergestellt, die unabhängig von Microsoft sind. Microsoft übernimmt keine Garantie, weder ausdrücklich noch implizit, bezüglich der Leistung oder Zuverlässigkeit dieser Produkte.

Haftungsausschluss für Drittanbieterkontakte

Microsoft stellt Kontaktinformationen von Drittanbietern bereit, um Ihnen bei der Suche nach zusätzlichen Informationen zu diesem Thema zu helfen. Diese Kontaktinformationen können ohne vorherige Ankündigung geändert werden. Microsoft gibt keine Garantie für die Genauigkeit von Kontaktinformationen Dritter.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe benötigen, erstellen Sie eine Support-Anfrage oder wenden Sie sich an den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.