Fehlerbehebung bei kube-dns in GKE

Auf dieser Seite wird beschrieben, wie Sie Probleme mit kube-dns in Google Kubernetes Engine (GKE) beheben.

Quelle von DNS-Problemen in kube-dns ermitteln

Fehler wie dial tcp: i/o timeout, no such host oder Could not resolve host deuten oft auf Probleme mit der Fähigkeit von kube-dns hin, Anfragen aufzulösen.

Wenn einer dieser Fehler aufgetreten ist, Sie die Ursache aber nicht kennen, können Sie sie mithilfe der folgenden Abschnitte ermitteln. Die folgenden Abschnitte sind so angeordnet, dass Sie mit den Schritten beginnen, die Ihnen am wahrscheinlichsten helfen. Arbeiten Sie die Abschnitte daher der Reihe nach durch.

Prüfen, ob kube-dns-Pods ausgeführt werden

Kube-dns-Pods sind für die Namensauflösung im Cluster von entscheidender Bedeutung. Wenn sie nicht ausgeführt werden, treten wahrscheinlich Probleme mit der DNS-Auflösung auf.

So prüfen Sie, ob die kube-dns-Pods ohne kürzliche Neustarts ausgeführt werden:

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

Die Ausgabe sieht etwa so aus:

NAME                   READY          STATUS          RESTARTS       AGE
kube-dns-POD_ID_1      5/5            Running         0              16d
kube-dns-POD_ID_2      0/5            Terminating     0              16d

In dieser Ausgabe stehen POD_ID_1 und POD_ID_2 für eindeutige Kennzeichnungen, die automatisch an die kube-dns-Pods angehängt werden.

Wenn in der Ausgabe angezeigt wird, dass einer Ihrer kube-dns-Pods nicht den Status Running hat, führen Sie die folgenden Schritte aus:

  1. Mit den Audit-Logs für Administratoraktivitäten können Sie untersuchen, ob es in letzter Zeit Änderungen gab, z. B. Cluster- oder Knotenpool-Versionsupgrades oder Änderungen an der kube-dns-ConfigMap. Weitere Informationen zu Audit-Logs finden Sie unter GKE-Audit-Logging. Wenn Sie Änderungen finden, machen Sie sie rückgängig und sehen Sie sich den Status der Pods noch einmal an.

  2. Wenn Sie keine relevanten Änderungen finden, prüfen Sie, ob auf dem Knoten, auf dem der kube-dns-Pod ausgeführt wird, ein OOM-Fehler (Out of Memory) auftritt. Wenn in Ihren Cloud Logging-Logmeldungen ein Fehler wie der folgende angezeigt wird, tritt bei diesen Pods ein OOM-Fehler auf:

    Warning: OOMKilling Memory cgroup out of memory

    Diese Meldung gibt an, dass Kubernetes einen Prozess aufgrund von übermäßigem Ressourcenverbrauch beendet hat. Kubernetes plant Pods auf der Grundlage von Ressourcenanforderungen, lässt Pods aber bis zu ihren Ressourcenlimits Ressourcen verbrauchen. Wenn die Limits höher als die Anfragen sind oder keine Limits vorhanden sind, kann die Ressourcennutzung des Pods die Ressourcen des Systems überschreiten.

    Um diesen Fehler zu beheben, können Sie entweder die problematischen Arbeitslasten löschen oder Arbeitsspeicher- oder CPU-Limits festlegen. Weitere Informationen zum Festlegen von Limits finden Sie in der Kubernetes-Dokumentation unter Ressourcenverwaltung für Pods und Container. Weitere Informationen zu OOM-Ereignissen finden Sie unter OOM-Ereignisse beheben.

  3. Wenn Sie keine OOM-Fehlermeldungen finden, starten Sie das kube-dns-Deployment neu:

    kubectl rollout restart deployment/kube-dns --namespace=kube-system

    Prüfen Sie nach dem Neustart des Deployments, ob Ihre kube-dns-Pods ausgeführt werden.

Wenn diese Schritte nicht funktionieren oder alle kube-dns-Pods den Status Running haben, aber weiterhin DNS-Probleme auftreten, prüfen Sie, ob die Datei /etc/resolv.conf richtig konfiguriert ist.

Prüfen Sie, ob /etc/resolv.conf richtig konfiguriert ist.

Prüfen Sie die Datei /etc/resolv.conf der Pods, bei denen DNS-Probleme auftreten, und vergewissern Sie sich, dass die darin enthaltenen Einträge korrekt sind:

  1. Sehen Sie sich die Datei /etc/resolv.conf des Pods an:

    kubectl exec -it POD_NAME -- cat /etc/resolv.conf

    Ersetzen Sie POD_NAME durch den Namen des Pods, bei dem DNS-Probleme auftreten. Wenn mehrere Pods Probleme haben, wiederhole die Schritte in diesem Abschnitt für jeden Pod.

    Wenn das Pod-Binärprogramm den Befehl kubectl exec nicht unterstützt, kann dieser Befehl fehlschlagen. In diesem Fall erstellen Sie einen einfachen Pod, der als Testumgebung verwendet werden kann. Mit dieser Vorgehensweise können Sie einen Test-Pod im selben Namespace wie den problematischen Pod ausführen.

  2. Prüfen Sie, ob die Nameserver-IP-Adresse in der Datei /etc/resolv.conf korrekt ist:

    • Pods, die ein Hostnetzwerk verwenden, sollten die Werte in der Datei /etc/resolv.conf des Knotens verwenden. Die IP-Adresse des Nameservers sollte 169.254.169.254 sein.

    • Für Pods, die kein Hostnetzwerk verwenden, sollte die IP-Adresse des kube-dns-Dienstes mit der Nameserver-IP-Adresse identisch sein. So vergleichen Sie die IP-Adressen:

      1. Rufen Sie die IP-Adresse des kube-dns-Dienstes ab:

        kubectl get svc kube-dns -n kube-system

        Die Ausgabe sieht etwa so aus:

        NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
kube-dns   ClusterIP   192.0.2.10   <none>        53/UDP,53/TCP   64d

      2. Notieren Sie sich den Wert in der Spalte „Cluster-IP“. In diesem Beispiel ist das 192.0.2.10.

      3. Vergleichen Sie die IP-Adresse des kube-dns-Dienstes mit der IP-Adresse aus der Datei /etc/resolv.conf:

        # cat /etc/resolv.conf

search default.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_NAME google.internal
nameserver 192.0.2.10
options ndots:5

        In diesem Beispiel stimmen die beiden Werte überein. Eine falsche IP-Adresse des Nameservers ist also nicht die Ursache des Problems.

        Wenn die IP-Adressen jedoch nicht übereinstimmen, bedeutet das, dass im Manifest des Anwendungs-Pods das Feld dnsConfig konfiguriert ist.

        Wenn der Wert im Feld dnsConfig.nameservers korrekt ist, untersuchen Sie Ihren DNS-Server und prüfen Sie, ob er richtig funktioniert.

        Wenn Sie den benutzerdefinierten Nameserver nicht verwenden möchten, entfernen Sie das Feld und führen Sie einen rollierenden Neustart des Pods durch:

        kubectl rollout restart deployment POD_NAME

        Ersetzen Sie POD_NAME durch den Namen Ihres Clusters.

  3. Prüfen Sie die Einträge search und ndots in /etc/resolv.conf. Achten Sie darauf, dass keine Rechtschreibfehler und veralteten Konfigurationen vorhanden sind und die fehlgeschlagene Anfrage auf einen vorhandenen Dienst im richtigen Namespace verweist.

DNS-Lookup durchführen

Nachdem Sie bestätigt haben, dass /etc/resolv.conf richtig konfiguriert ist und der DNS-Eintrag korrekt ist, führen Sie mit dem Befehlszeilentool „dig“ DNS-Lookups vom Pod aus durch, der DNS-Fehler meldet:

  1. Sie können einen Pod direkt abfragen, indem Sie eine Shell darin öffnen:

    kubectl exec -it POD_NAME -n NAMESPACE_NAME -- SHELL_NAME

    Ersetzen Sie Folgendes:

    • POD_NAME: der Name des Pods, der DNS-Fehler meldet.
    • NAMESPACE_NAME: der Namespace, zu dem der Pod gehört.
    • SHELL_NAME: Der Name der Shell, die Sie öffnen möchten. Beispiel: shoder /bin/bash

    Dieser Befehl schlägt möglicherweise fehl, wenn Ihr Pod den kubectl exec-Befehl nicht zulässt oder wenn der Pod das Binärprogramm „dig“ nicht enthält. Wenn dies der Fall ist, erstellen Sie einen Test-Pod mit einem Image, auf dem „dig“ installiert ist:

    kubectl run "test-$RANDOM" ti --restart=Never --image=thockin/dnsutils - bash

  2. Prüfen Sie, ob der Pod den internen DNS-Dienst des Clusters korrekt auflösen kann:

    dig kubernetes

    Da die Datei /etc/resolv.conf auf die IP-Adresse des kube-dns-Dienstes verweist, ist der DNS-Server der kube-dns-Dienst, wenn Sie diesen Befehl ausführen.

    Sie sollten eine erfolgreiche DNS-Antwort mit der IP-Adresse des Kubernetes API-Dienstes sehen (oft etwa 10.96.0.1). Wenn Sie SERVFAIL oder keine Antwort sehen, deutet dies in der Regel darauf hin, dass der kube-dns-Pod die internen Dienstnamen nicht auflösen kann.

  3. Prüfen Sie, ob der kube-dns-Dienst einen externen Domainnamen auflösen kann:

    dig example.com

  4. Wenn Sie Probleme mit einem bestimmten kube-dns-Pod haben, der auf DNS-Anfragen antwortet, prüfen Sie, ob dieser Pod einen externen Domainnamen auflösen kann:

     dig example.com @KUBE_DNS_POD_IP

    Ersetzen Sie KUBE_DNS_POD_IP durch die IP-Adresse des kube-dns-Pods. Wenn Sie den Wert dieser IP-Adresse nicht kennen, führen Sie den folgenden Befehl aus:

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

    Die IP-Adresse befindet sich in der Spalte IP.

    Wenn die Auflösung des Befehls erfolgreich ist, sehen Sie status: NOERROR und Details des A-Eintrags, wie im folgenden Beispiel gezeigt:

     ; <<>> DiG 9.16.27 <<>> example.com
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31256
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 512
 ;; QUESTION SECTION:
 ;example.com.                   IN      A

 ;; ANSWER SECTION:
 example.com.            30      IN      A       93.184.215.14

 ;; Query time: 6 msec
 ;; SERVER: 10.76.0.10#53(10.76.0.10)
 ;; WHEN: Tue Oct 15 16:45:26 UTC 2024
 ;; MSG SIZE  rcvd: 56

  5. Beenden Sie die Shell:

    exit

Wenn einer dieser Befehle fehlschlägt, führen Sie einen rollierenden Neustart des kube-dns-Deployments durch:

kubectl rollout restart deployment/kube-dns --namespace=kube-system

Nachdem Sie den Neustart abgeschlossen haben, versuchen Sie es noch einmal mit den dig-Befehlen und prüfen Sie, ob sie jetzt erfolgreich ausgeführt werden. Wenn sie weiterhin fehlschlagen, fahren Sie mit der Aufzeichnung von Paketen fort.

Paketerfassung durchführen

Erstellen Sie eine Paketerfassung, um zu prüfen, ob die DNS-Anfragen von den kube-dns-Pods empfangen und richtig beantwortet werden:

  1. Stellen Sie über SSH eine Verbindung zum Knoten her, auf dem der kube-dns-Pod ausgeführt wird. Beispiel:

    1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

      Zu Seite „VM-Instanzen“

    2. Suchen Sie den Knoten, mit dem Sie eine Verbindung herstellen möchten. Wenn Sie den Namen des Knotens in Ihrem kube-dns-Pod nicht kennen, führen Sie den folgenden Befehl aus:

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

      Der Name des Knotens wird in der Spalte Knoten aufgeführt.

    3. Klicken Sie in der Spalte Verbinden auf SSH.

  2. Starten Sie im Terminal toolbox, ein vorinstalliertes Debugging-Tool:

    toolbox

  3. Installieren Sie an der Root-Eingabeaufforderung das Paket tcpdump:

    apt update -y && apt install -y tcpdump

  4. So erfassen Sie mit tcpdump eine Paketaufzeichnung Ihres DNS-Traffics:

    tcpdump -i eth0 port 53" -w FILE_LOCATION

    Ersetzen Sie FILE_LOCATION durch einen Pfad, unter dem Sie die Aufnahme speichern möchten.

  5. Sehen Sie sich die Paketerfassung an. Prüfen Sie, ob Pakete mit Ziel-IP-Adressen vorhanden sind, die mit der IP-Adresse des kube-dns-Dienstes übereinstimmen. So wird sichergestellt, dass die DNS-Anfragen zur Auflösung an das richtige Ziel gesendet werden. Wenn kein DNS-Traffic auf den richtigen Pods eingeht, kann das darauf hindeuten, dass eine Netzwerkrichtlinie die Anfragen blockiert.

Nach einer Netzwerkrichtlinie suchen

Restriktive Netzwerkrichtlinien können manchmal den DNS-Traffic stören. Führen Sie den folgenden Befehl aus, um zu prüfen, ob im Namespace „kube-system“ eine Netzwerkrichtlinie vorhanden ist:

kubectl get networkpolicy -n kube-system

Wenn Sie eine Netzwerkrichtlinie finden, prüfen Sie sie und stellen Sie sicher, dass die erforderliche DNS-Kommunikation zulässig ist. Wenn Sie beispielsweise eine Netzwerkrichtlinie haben, die den gesamten ausgehenden Traffic blockiert, werden auch DNS-Anfragen blockiert.

Wenn die Ausgabe No resources found in kube-system namespace ist, haben Sie keine Netzwerkrichtlinien und können dies als Ursache des Problems ausschließen. Wenn Sie die Protokolle untersuchen, können Sie weitere Fehlerquellen finden.

Temporäres Logging von DNS-Abfragen aktivieren

Um Probleme wie falsche DNS-Antworten zu erkennen, können Sie vorübergehend das Debug-Logging von DNS-Abfragen aktivieren. Um Abfragen zu aktivieren, erstellen Sie einen Pod auf Grundlage eines vorhandenen kube-dns-Pods. Alle Änderungen am kube-dns-Deployment werden automatisch rückgängig gemacht.

Die temporäre Protokollierung von DNS-Abfragen ist ein ressourcenintensiver Vorgang. Wir empfehlen daher, den erstellten Pod zu löschen, sobald Sie eine geeignete Stichprobe von Protokollen gesammelt haben.

So aktivieren Sie die temporäre DNS-Abfrageprotokollierung:

  1. Rufen Sie einen kube-dns-Pod ab und speichern Sie ihn in der Variablen POD:

    POD=$(kubectl -n kube-system get pods --selector=k8s-app=kube-dns -o jsonpath="{.items[0].metadata.name}")

  2. Erstellen Sie einen Pod mit dem Namen kube-dns-debug. Dieser Pod ist eine Kopie des Pods, der in der Variablen POD gespeichert ist, aber mit aktivierter dnsmasq-Protokollierung. Mit diesem Befehl wird der ursprüngliche kube-dns-Pod nicht geändert:

    kubectl apply -f <(kubectl get pod -n kube-system ${POD} -o json | jq -e '

(

(.spec.containers[] | select(.name == "dnsmasq") | .args) += ["--log-queries"]

)

| (.metadata.name = "kube-dns-debug")

| (del(.metadata.labels."pod-template-hash"))

')

  3. Logs prüfen:

    kubectl logs -f --tail 100 -c dnsmasq -n kube-system kube-dns-debug

    Sie können die Anfragen auch in Cloud Logging aufrufen.

  4. Wenn Sie sich die DNS-Abfragelogs angesehen haben, löschen Sie den kube-dns-debug-Pod:

    kubectl -n kube-system delete pod kube-dns-debug

kube-dns-Pod untersuchen

Mit Cloud Logging können Sie nachvollziehen, wie kube-dns-Pods DNS-Anfragen empfangen und auflösen.

So rufen Sie Logeinträge für den kube-dns-Pod auf:

  1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

    Zum Log-Explorer

  2. Geben Sie im Bereich „Abfrage“ den folgenden Filter ein, um Ereignisse im Zusammenhang mit dem kube-dns-Container aufzurufen:

    resource.type="k8s_container"
resource.labels.namespace_name="kube-system"
resource.labels.Pod_name:"kube-dns"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="CLUSTER_LOCATION"

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: der Name des Clusters, zu dem der kube-dns-Pod gehört.
    • CLUSTER_LOCATION: Der Standort Ihres Clusters.

  3. Klicken Sie auf Abfrage ausführen.

  4. Sehen Sie sich die Ausgabe an. Die folgende Beispielausgabe zeigt einen möglichen Fehler:

    {
   "timestamp": "2024-10-10T15:32:16.789Z",
   "severity": "ERROR",
   "resource": {
      "type": "k8s_container",
      "labels": {
      "namespace_name": "kube-system",
      "Pod_name": "kube-dns",
      "cluster_name": "CLUSTER_NAME",
      "location": "CLUSTER_LOCATION"
      }
   },
   "message": "Failed to resolve 'example.com': Timeout."
},

    In diesem Beispiel konnte kube-dns example.com nicht innerhalb eines angemessenen Zeitrahmens auflösen. Diese Art von Fehler kann durch verschiedene Probleme verursacht werden. Beispielsweise ist der Upstream-Server möglicherweise falsch in der kube-dns-ConfigMap konfiguriert oder es gibt viel Netzwerk-Traffic.

Wenn Sie Cloud Logging nicht aktiviert haben, rufen Sie stattdessen die Kubernetes-Logs auf:

Pod=$(kubectl get Pods -n kube-system -l k8s-app=kube-dns -o name | head -n1)
kubectl logs -n kube-system $Pod -c dnsmasq
kubectl logs -n kube-system $Pod -c kubedns
kubectl logs -n kube-system $Pod -c sidecar

Letzte Änderungen an der kube-dns-ConfigMap untersuchen

Wenn in Ihrem Cluster plötzlich DNS-Auflösungsfehler auftreten, kann das an einer falschen Konfigurationsänderung der kube-dns-ConfigMap liegen. Insbesondere Konfigurationsänderungen an den Definitionen von Stub-Domains und Upstream-Servern können Probleme verursachen.

So suchen Sie nach Updates für die Einstellungen der Stubs-Domain:

  1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

    Zum Log-Explorer

  2. Geben Sie im Bereich „Abfrage“ die folgende Abfrage ein:

    resource.labels.cluster_name="clouddns"
resource.type="k8s_container"
resource.labels.namespace_name="kube-system"
labels.k8s-pod/k8s-app="kube-dns" jsonPayload.message=~"Updated stubDomains to"

  3. Klicken Sie auf Abfrage ausführen.

  4. Sehen Sie sich die Ausgabe an. Wenn es Updates gab, sieht die Ausgabe in etwa so aus:

    Updated stubDomains to map[example.com: [8.8.8.8 8.8.4.4 1.1.3.3 1.0.8.111]]

    Wenn Sie eine Aktualisierung sehen, maximieren Sie das Ergebnis, um mehr über die Änderungen zu erfahren. Prüfen Sie, ob alle Stub-Domains und die zugehörigen vorgelagerten DNS-Server richtig definiert sind. Falsche Einträge können zu Auflösungsfehlern für diese Domains führen.

So prüfen Sie, ob sich der Upstream-Server geändert hat:

  1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

    Zum Log-Explorer

  2. Geben Sie im Bereich „Abfrage“ die folgende Abfrage ein:

    resource.labels.cluster_name="clouddns"
resource.type="k8s_container" resource.labels.namespace_name="kube-system"
labels.k8s-pod/k8s-app="kube-dns" jsonPayload.message=~"Updated upstreamNameservers to"

  3. Klicken Sie auf Abfrage ausführen.

  4. Sehen Sie sich die Ausgabe an. Wenn Änderungen vorgenommen wurden, sieht die Ausgabe in etwa so aus:

    Updated upstreamNameservers to [8.8.8.8]

    Klicken Sie auf das Ergebnis, um weitere Informationen zu den Änderungen zu erhalten. Prüfen Sie, ob die Liste der Upstream-DNS-Server korrekt ist und ob diese Server von Ihrem Cluster aus erreichbar sind. Wenn diese Server nicht verfügbar oder falsch konfiguriert sind, kann die allgemeine DNS-Auflösung fehlschlagen.

Wenn Sie nach Änderungen an den Stub-Domains und Upstream-Servern gesucht, aber keine Ergebnisse gefunden haben, suchen Sie mit dem folgenden Filter nach allen Änderungen:

resource.type="k8s_cluster"
protoPayload.resourceName:"namespaces/kube-system/configmaps/kube-dns"
protoPayload.methodName=~"io.k8s.core.v1.configmaps."

Prüfen Sie die aufgeführten Änderungen, um festzustellen, ob sie den Fehler verursacht haben.

Cloud Customer Care kontaktieren

Wenn Sie die vorangegangenen Abschnitte durchgearbeitet haben, die Ursache des Problems aber immer noch nicht ermitteln können, wenden Sie sich an den Cloud Customer Care.

Häufige Probleme beheben

Wenn ein bestimmter Fehler oder ein bestimmtes Problem aufgetreten ist, folgen Sie den Ratschlägen in den folgenden Abschnitten.

Problem: Intermittierende DNS-Zeitüberschreitungen

Wenn Sie zeitweilige DNS-Auflösungszeitüberschreitungen feststellen, die bei einer Zunahme des DNS-Traffics oder zu Beginn der Geschäftszeiten auftreten, können Sie die folgenden Lösungen ausprobieren, um die DNS-Leistung zu optimieren:

  • Prüfen Sie die Anzahl der kube-dns-Pods, die im Cluster ausgeführt werden, und vergleichen Sie sie mit der Gesamtzahl der GKE-Knoten. Wenn nicht genügend Ressourcen vorhanden sind, sollten Sie die kube-dns-Pods hochskalieren.

  • Um die durchschnittliche DNS-Lookup-Zeit zu verbessern, aktivieren Sie NodeLocal DNSCache.

  • Die DNS-Auflösung für externe Namen kann den kube-dns-Pod überlasten. Wenn Sie die Anzahl der Anfragen reduzieren möchten, passen Sie die Einstellung ndots in der Datei /etc/resolv.conf an. ndots steht für die Anzahl der Punkte, die in einem Domainnamen enthalten sein müssen, damit eine Anfrage vor der ursprünglichen absoluten Anfrage aufgelöst wird.

    Das folgende Beispiel zeigt die /etc/resolv.conf-Datei eines Anwendungs-Pods:

    search default.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_ID.internal google.internal
nameserver 10.52.16.10
options ndots:5

    In diesem Beispiel sucht kube-dns nach fünf Punkten in der abgefragten Domain. Wenn der Pod einen DNS-Auflösungsaufruf für example.com ausführt, sehen Ihre Logs in etwa so aus:

    "A IN example.com.default.svc.cluster.local." NXDOMAIN
"A IN example.com.svc.cluster.local." NXDOMAIN
"A IN example.com.cluster.local." NXDOMAIN
"A IN example.com.google.internal." NXDOMAIN
"A IN example.com.c.PROJECT_ID.internal." NXDOMAIN
"A IN example.com." NOERROR

    Um dieses Problem zu beheben, ändern Sie den Wert von „ndots“ in 1, um nur nach einem einzelnen Punkt zu suchen, oder hängen Sie einen Punkt (.) an das Ende der Domain an, die Sie abfragen oder verwenden. Beispiel:

    dig example.com.

Problem: DNS-Abfragen schlagen auf einigen Knoten zeitweise fehl

Wenn DNS-Abfragen von einigen Knoten aus zeitweise fehlschlagen, können die folgenden Symptome auftreten:

  • Wenn Sie „dig“-Befehle für die kube-dns-Dienst-IP-Adresse oder die Pod-IP-Adresse ausführen, schlagen die DNS-Abfragen zeitweise mit Zeitüberschreitungen fehl.
  • Das Ausführen von „dig“-Befehlen über einen Pod auf demselben Knoten wie der kube-dns-Pod schlägt fehl.

So beheben Sie das Problem:

  1. Führen Sie einen Konnektivitätstest durch. Legen Sie den problematischen Pod oder Knoten als Quelle und die IP-Adresse des kube-dns-Pods als Ziel fest. So können Sie prüfen, ob Sie die erforderlichen Firewallregeln eingerichtet haben, um diesen Traffic zuzulassen.

  2. Wenn der Test nicht erfolgreich ist und der Traffic durch eine Firewallregel blockiert wird, können Sie mit Cloud Logging alle manuellen Änderungen an den Firewallregeln auflisten. Suchen Sie nach Änderungen, die eine bestimmte Art von Traffic blockieren:

    1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

      Zum Log-Explorer

    2. Geben Sie im Bereich „Abfrage“ die folgende Abfrage ein:

      logName="projects/project-name/logs/cloudaudit.googleapis.com/activity"
resource.type="gce_firewall_rule"

    3. Klicken Sie auf Abfrage ausführen. Anhand der Ausgabe der Abfrage können Sie feststellen, ob Änderungen vorgenommen wurden. Wenn Sie Fehler bemerken, korrigieren Sie sie und wenden Sie die Firewallregel noch einmal an.

      Nehmen Sie keine Änderungen an automatisierten Firewallregeln vor.

  3. Wenn sich die Firewallregeln nicht geändert haben, prüfen Sie die Knotenpoolversion und stellen Sie sicher, dass sie mit der Steuerungsebene und anderen funktionierenden Knotenpools kompatibel ist. Wenn einer der Knotenpools eines Clusters mehr als zwei Nebenversionen älter als die Steuerungsebene ist, kann dies zu Problemen führen. Weitere Informationen zu dieser Inkompatibilität finden Sie unter Knotenversion ist nicht mit Version der Steuerungsebene kompatibel.

  4. Um festzustellen, ob die Anfragen an die richtige kube-dns-Dienst-IP gesendet werden, erfassen Sie den Netzwerkverkehr auf dem problematischen Knoten und filtern Sie nach Port 53 (DNS-Traffic). Erfassen Sie den Traffic auf den kube-dns-Pods selbst, um zu sehen, ob die Anfragen die vorgesehenen Pods erreichen und ob sie erfolgreich aufgelöst werden.

Nächste Schritte