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

Artikel
04/12/2024

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

Voraussetzungen

Das Kubernetes kubectl-Tool oder ein ähnliches Tool zum Herstellen einer Verbindung mit dem Cluster. Um kubectl mithilfe der Azure CLI zu installieren, führen Sie den Befehl az aks install-cli aus.
Das Befehlszeilentool apt-get zum Verarbeiten von Paketen.
Das Hostbefehlszeilentool für DNS-Lookups.
Das Befehlszeilentool systemctl .

Hintergrund

Für die DNS-Auflösung senden die Pods Anforderungen an die CoreDNS-Pods im kube-system Namespace.

Wenn es sich bei der DNS-Abfrage um eine interne Komponente handelt, z. B. für einen Dienstnamen, 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 Resolv.conf-Datei 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:

Überprüfen Sie, ob die CoreDNS-Pods ausgeführt werden:
```
kubectl get pods -l k8s-app=kube-dns -n kube-system
```

Überprüfen Sie, ob die CoreDNS-Pods übermäßig verwendet werden:

$ 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 übermäßig ausgelastet 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
```

Hinweis

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

Schritt 2: Erstellen eines Testpods zum Ausführen von Befehlen

Wenn bei der DNS-Auflösung ein Fehler auftritt, führen Sie die folgenden Schritte aus:

Führen Sie einen Testpod im selben Namespace wie der problematische Pod aus.
Starten Sie einen Testpod im Cluster:
```
kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
```
Wenn der Testpod 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
```

Vergewissern Sie sich, 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 bestimmen, ob die DNS-Anforderungen an den Upstream Server 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 den Upstream DNS-Server des Pods, 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 ist

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 datenverkehr über 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 befinden (Systemknotenpool). Wenn dies der Fall ist, überprüfen Sie, ob dem Systemknotenpool, der Datenverkehr an UDP-Port 53 blockiert, eine Netzwerksicherheitsgruppe (NSG) zugeordnet ist.
Überprüfen Sie, ob das virtuelle Netzwerk kürzlich aktualisiert wurde, um die neuen DNS-Server hinzuzufügen.

Wenn ein Virtuelles Netzwerk aktualisiert wurde, ü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 verfügen über die aktualisierte Konfiguration.)
- Starten Sie den Netzwerkdienst auf den Knoten und dann die CoreDNS-Pods neu. Gehen Sie folgendermaßen vor:
  1. Stellen Sie eine SSH-Verbindung (Secure Shell) mit den Knoten her. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit Azure Kubernetes Service Clusterknoten (AKS) zur Wartung oder Problembehandlung.
  2. Starten Sie den Netzwerkdienst 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
```

Überprüfen Sie, ob in den DNS-Einstellungen des virtuellen Netzwerks mehr als ein DNS-Server angegeben ist.

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

Der AKS-Knoten sendet im Rahmen einer Reihe eine Anforderung an den Upstream DNS-Server. In dieser Sequenz wird die Anforderung an den ersten DNS-Server gesendet, der im virtuellen Netzwerk konfiguriert ist (wenn die DNS-Server erreichbar sind und ausgeführt werden). Wenn der erste DNS-Server nicht erreichbar ist und nicht antwortet, wird die Anforderung an den nächsten DNS-Server gesendet.

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

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

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 kann die Anforderung an jeden der DNS-Server weitergeleitet werden, 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>

Gibt im CoreDNS-Plug-In forward die Richtlinie an, policy die zum Auswählen Upstream Servers verwendet werden soll. Die Richtlinien werden in der folgenden Tabelle definiert.

Richtlinienname	Beschreibung
`random`	Eine Richtlinie, die zufällige Upstream Auswahl implementiert. Diese Richtlinie ist die Standardrichtlinie.
`round_robin`	Eine Richtlinie, die Hosts basierend auf der Roundrobinreihenfolge auswählt.
`sequential`	Eine Richtlinie, die Hosts basierend auf sequenzieller Reihenfolge auswählt.

Wenn das virtuelle AKS-Netzwerk mehrere DNS-Server enthält, gehen die Anforderungen vom AKS-Knoten möglicherweise an den ersten DNS-Server. Die Anforderungen des Pods können jedoch an den zweiten DNS-Server gesendet werden.

Ursache: Mehrere Ziele für DNS-Anforderungen

Wenn zwei benutzerdefinierte DNS-Server angegeben werden und der dritte DNS-Server als Azure DNS (168.63.129.16) angegeben ist, sendet der Knoten Anforderungen an den ersten benutzerdefinierten DNS-Server, wenn er ausgeführt wird und erreichbar ist. In diesem Setup kann der Knoten die benutzerdefinierte Domäne auflösen. Einige der DNS-Anforderungen vom Pod können jedoch an Azure DNS weitergeleitet werden. Dies liegt daran, dass CoreDNS den Upstream Server nach dem Zufallsprinzip 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 des virtuellen Netzwerks

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, die Ihren eigenen DNS-Server verwendet.

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.