Behandeln von DNS-Auflösungsfehlern innerhalb des Pods, aber nicht vom Workerknoten aus

Artikel
11/20/2024

In diesem Artikel wird erläutert, wie Sie Probleme mit der Dns-Auflösung (Domain Name System) beheben, die von innerhalb des Pods auftreten, aber nicht vom Workerknoten, wenn Sie versuchen, eine ausgehende Verbindung von einem Microsoft Azure Kubernetes Service (AKS)-Cluster herzustellen.

Voraussetzungen

Das Kubernetes-Kubectl-Tool oder ein ähnliches Tool zum Herstellen einer Verbindung mit dem Cluster. Führen Sie zum Installieren von Kubectl mithilfe der Azure CLI den Befehl "az aks install-cli " aus.
Das Apt-get-Befehlszeilentool zum Behandeln von Paketen.
Das Host-Befehlszeilentool für DNS-Nachschlagevorgänge.
Das Befehlszeilentool systemctl .

Hintergrund

Bei der DNS-Auflösung senden die Pods Anforderungen an die CoreDNS-Pods im kube-system Namespace.

Wenn die DNS-Abfrage für eine interne Komponente( z. B. einen Dienstnamen) bestimmt ist, antwortet der CoreDNS-Pod selbst. Wenn die Anforderung jedoch für eine externe Domäne gilt, sendet der CoreDNS-Pod die Anforderung an den Upstream-DNS-Server.

Die upstream-DNS-Server werden basierend auf der Datei resolv.conf des Workerknotens abgerufen, in dem der Pod ausgeführt wird. Die Datei resolv.conf ( /run/systemd/resolve/resolv.conf) wird basierend auf den DNS-Einstellungen des virtuellen Netzwerks aktualisiert, in dem der Workerknoten ausgeführt wird.

Checkliste zur Problembehandlung

Verwenden Sie die Anweisungen in den folgenden Abschnitten, um DNS-Probleme innerhalb des Pods zu beheben.

Schritt 1: Behandeln von DNS-Problemen innerhalb des Pods

Sie können kubectl-Befehle verwenden, um DNS-Probleme innerhalb des Pods zu beheben, wie in den folgenden Schritten gezeigt:

Stellen Sie sicher, dass die CoreDNS-Pods ausgeführt werden:
```
kubectl get pods -l k8s-app=kube-dns -n kube-system
```

Ü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

Stellen Sie sicher, dass die Knoten, die die CoreDNS-Pods hosten, nicht überlastet sind. Rufen Sie außerdem die Knoten ab, die die CoreDNS-Pods hosten:
```
kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].spec.nodeName}'
```
Überprüfen Sie die Verwendung dieser Knoten:
```
kubectl top nodes
```
Überprüfen Sie die Protokolle für die CoreDNS-Pods:
```
kubectl logs -l k8s-app=kube-dns -n kube-system
```

Notiz

Um weitere Debuginformationen anzuzeigen, aktivieren Sie ausführliche Protokolle in CoreDNS. Informationen zum Aktivieren der ausführlichen Protokollierung in CoreDNS finden Sie unter "Problembehandlung bei CoreDNS-Anpassungen in AKS".

Schritt 2: Erstellen eines Test-Pods zum Ausführen von Befehlen

Wenn die DNS-Auflösung fehlschlägt, führen Sie die folgenden Schritte aus:

Führen Sie einen Test pod im selben Namespace wie der problematische Pod aus.
Starten Sie einen Test pod im Cluster:
```
kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
```
Wenn der Test-Pod ausgeführt wird, erhalten Sie Zugriff auf den Pod.
Führen Sie die folgenden Befehle aus, um die erforderlichen Pakete zu installieren:
```
apt-get update -y
apt-get install dnsutils -y
```

Stellen Sie sicher, dass die Datei "resolv.conf " die richtigen Einträge enthält:

cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local 00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net
nameserver 10.0.0.10
options ndots:5

Verwenden Sie den host Befehl, um zu ermitteln, ob die DNS-Anforderungen an den Upstreamserver weitergeleitet werden:

$ host -a microsoft.com
Trying "microsoft.com.default.svc.cluster.local"
Trying "microsoft.com.svc.cluster.local"
Trying "microsoft.com.cluster.local"
Trying "microsoft.com.00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net"
Trying "microsoft.com"
Trying "microsoft.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62884
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;microsoft.com.                 IN      ANY

;; ANSWER SECTION:
microsoft.com.          30      IN      NS      ns1-39.azure-dns.com.
...
...
ns4-39.azure-dns.info.  30      IN      A       13.107.206.39

Received 2121 bytes from 10.0.0.10#53 in 232 ms

Überprüfen Sie im Pod den Upstream-DNS-Server, um zu ermitteln, ob die DNS-Auflösung ordnungsgemäß funktioniert. Führen Sie beispielsweise für Azure DNS den folgenden nslookup-Befehl aus:
```
$ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85
```

Schritt 3: Überprüfen, ob DNS-Anforderungen funktionieren, wenn der upstream-DNS-Server explizit angegeben wird

Wenn die DNS-Anforderungen von Pods funktionieren, wenn Sie den Upstream-DNS-Server explizit angeben, überprüfen Sie die folgenden Bedingungen:

Suchen Sie nach einer benutzerdefinierten ConfigMap für CoreDNS:
```
kubectl describe cm coredns-custom -n kube-system
```
Wenn eine benutzerdefinierte ConfigMap vorhanden ist, überprüfen Sie, ob die Konfiguration korrekt ist. Weitere Informationen finden Sie unter Anpassen von CoreDNS mit Azure Kubernetes Service.
Überprüfen Sie, ob eine Netzwerkrichtlinie den Datenverkehr im UDP-Port 53 (User Datagram Protocol) zu den CoreDNS-Pods im kube-system Namespace blockiert.
Überprüfen Sie, ob sich die CoreDNS-Pods in einem anderen Knotenpool (Systemknotenpool) befinden. Überprüfen Sie, ob eine Netzwerksicherheitsgruppe (Network Security Group, NSG) dem Systemknotenpool zugeordnet ist, der Datenverkehr auf UDP-Port 53 blockiert.
Überprüfen Sie, ob das virtuelle Netzwerk kürzlich aktualisiert wurde, um die neuen DNS-Server hinzuzufügen.

Wenn eine Aktualisierung des virtuellen Netzwerks aufgetreten ist, überprüfen Sie, ob auch eines der folgenden Ereignisse aufgetreten ist:
- Die Knoten wurden neu gestartet.
- Der Netzwerkdienst im Knoten wurde neu gestartet.
Damit das Update in den DNS-Einstellungen wirksam wird, müssen der Netzwerkdienst auf dem Knoten und die CoreDNS-Pods neu gestartet werden. Verwenden Sie eine der folgenden Methoden, um den Netzwerkdienst oder die Pods neu zu starten:
- Starten Sie den Knoten neu.
- Skalieren sie neue Knoten. (Neue Knoten haben die aktualisierte Konfiguration.)
- Starten Sie den Netzwerkdienst in den Knoten neu, und starten Sie dann die CoreDNS-Pods neu. Führen Sie folgende Schritte aus:
  1. Herstellen einer Ssh-Verbindung (Secure Shell) mit den Knoten. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit Azure Kubernetes Service-Clusterknoten (AKS) zur Wartung oder Problembehandlung.
  2. Starten Sie den Netzwerkdienst von innerhalb des Knotens neu:
```
systemctl restart systemd-networkd
```
  3. Überprüfen Sie, ob die Einstellungen aktualisiert werden:
```
cat /run/systemd/resolve/resolv.conf
```
  4. Nachdem der Netzwerkdienst neu gestartet wurde, verwenden Sie kubectl, um die CoreDNS-Pods neu zu starten:
```
kubectl delete pods -l k8s-app=kube-dns -n kube-system
```

Prüfen Sie, ob in den DNS-Einstellungen des virtuellen Netzwerks mehrere DNS-Server angegeben sind.

Wenn mehrere DNS-Server im virtuellen AKS-Netzwerk angegeben sind, tritt eine der folgenden Sequenzen auf:

Der AKS-Knoten sendet eine Anforderung an den upstream-DNS-Server als Teil einer Reihe. In dieser Sequenz wird die Anforderung an den ersten DNS-Server gesendet, der im virtuellen Netzwerk konfiguriert ist (wenn die DNS-Server erreichbar und ausgeführt werden können). Wenn der erste DNS-Server nicht erreichbar ist und nicht reagiert, wird die Anforderung an den nächsten DNS-Server gesendet.

AKS-Knoten verwenden den Resolverbefehl , um Anforderungen an die DNS-Server zu senden. Die Konfigurationsdatei für diesen Resolver finden Sie unter /run/systemd/resolve/resolve.conf in den AKS-Knoten.

Gibt es mehrere Server? In diesem Fall fragt die Auflösungsbibliothek sie in der aufgeführten Reihenfolge ab. (Die verwendete Strategie besteht darin, zuerst einen Namensserver zu versuchen. Wenn die Abfrage ausgeht, probieren Sie den nächsten Namensserver aus, und fahren Sie fort, bis die Liste der Namenserver erschöpft ist. Anschließend versucht die Abfrage weiterhin, eine Verbindung mit den Namenservern herzustellen, bis die maximale Anzahl von Wiederholungen erfolgt.)

CoreDNS verwendet das Weiterleitungs-Plug-In , um Anforderungen an upstream-DNS-Server zu senden. Dieses Plug-In verwendet einen zufälligen Algorithmus, um den Upstream-DNS-Server auszuwählen. In dieser Sequenz könnte die Anforderung zu einem der DNS-Server gehen, die im virtuellen Netzwerk erwähnt werden. Sie können beispielsweise die folgende Ausgabe erhalten:

$ kubectl describe cm coredns -n kube-system
Name:         coredns
Namespace:    kube-system
Labels:       addonmanager.kubernetes.io/mode=Reconcile
              k8s-app=kube-dns
              kubernetes.io/cluster-service=true
Annotations:  <none>

Data
====
Corefile:
----
.:53 {
    errors
    ready
    health
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
    prometheus :9153
    forward . /etc/resolv.conf                            # Here!
    cache 30
    loop
    reload
    loadbalance
    import custom/*.override
}
import custom/*.server


BinaryData
====

Events:  <none>

Im CoreDNS-Plug-In forward gibt policy die Richtlinie an, die zum Auswählen von Upstreamservern verwendet werden soll. Die folgende Tabelle enthält die definierten Richtlinien.

Richtlinienname	BESCHREIBUNG
`random`	Eine Richtlinie, die eine zufällige Auswahl von Upstreamservern implementiert. Diese Richtlinie ist die Standardrichtlinie.
`round_robin`	Eine Richtlinie, die die Reihenfolge der Hosts nach dem Roundrobinprinzip auswählt.
`sequential`	Eine Richtlinie, die Hosts anhand einer sequenziellen Reihenfolge auswählt.

Wenn das virtuelle AKS-Netzwerk mehrere DNS-Server enthält, gehen die Anforderungen des AKS-Knotens möglicherweise zum ersten DNS-Server. Die Anforderungen des Pods können jedoch zum zweiten DNS-Server gehen.

Ursache: Mehrere Ziele für DNS-Anforderungen

Wenn zwei benutzerdefinierte DNS-Server angegeben sind und der dritte DNS-Server als Azure DNS (168.63.129.16) angegeben wird, sendet der Knoten Anforderungen an den ersten benutzerdefinierten DNS-Server, wenn er ausgeführt und erreichbar ist. In diesem Setup kann der Knoten die benutzerdefinierte Domäne auflösen. Einige der DNS-Anforderungen des Pods werden jedoch möglicherweise an Azure DNS weitergeleitet. Dies liegt daran, dass CoreDNS den Upstreamserver zufällig auswählen kann. In diesem Szenario kann die benutzerdefinierte Domäne nicht aufgelöst werden. Daher schlägt die DNS-Anforderung fehl.

Lösung: Entfernen von Azure DNS aus den Einstellungen für virtuelle Netzwerke

Es wird empfohlen, Azure DNS nicht mit benutzerdefinierten DNS-Servern in den Einstellungen des virtuellen Netzwerks zu kombinieren. Wenn Sie die benutzerdefinierten DNS-Server verwenden möchten, fügen Sie nur die benutzerdefinierten DNS-Server in den Einstellungen des virtuellen Netzwerks hinzu. Konfigurieren Sie dann Azure DNS in den Weiterleitungseinstellungen Ihrer benutzerdefinierten DNS-Server.

Weitere Informationen finden Sie unter Namensauflösung mithilfe eines eigenen DNS-Servers.

Haftungsausschluss für Kontaktinformationen von Drittanbietern

Die Kontaktinformationen zu den in diesem Artikel erwähnten Drittanbietern sollen Ihnen helfen, zusätzliche Informationen zu diesem Thema zu finden. Diese Kontaktinformationen können ohne vorherige Ankündigung geändert werden. Sie werden von Microsoft ohne jede Gewähr weitergegeben.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.

Freigeben über