Fehlerbehebung bei kube-dns in GKE

Wenn Sie kube-dns für Service Discovery verwenden, können Verbindungsfehler wie dial tcp: i/o timeout oder no such host auftreten. Solche Fehler deuten oft auf Probleme mit den kube-dns-Pods im kube-system-Namespace hin, z. B. falsche Konfigurationen, Ressourcenbeschränkungen oder Probleme mit der Netzwerkverbindung, die sich auf diese Pods auswirken.

Auf dieser Seite können Sie häufige Probleme diagnostizieren und beheben, die speziell bei der kube-dns-Bereitstellung auftreten. So können Sie eine zuverlässige DNS-Auflösung für Ihre Arbeitslasten sicherstellen.

Diese Informationen sind wichtig für Plattformadministratoren und ‑operatoren, die für die Wartung von Kernclusterkomponenten wie kube-dns verantwortlich sind, sowie für Anwendungsentwickler, deren Anwendungen davon abhängen, um eine Verbindung zu anderen Diensten im Cluster herzustellen. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die wir in Cloud de Confiance by S3NS Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Quelle von DNS-Problemen in kube-dns identifizieren

In den folgenden Abschnitten erfahren Sie, wie Sie diagnostizieren, warum kube-dns Probleme beim Auflösen von Abfragen hat.

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

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

Prüfen Sie, ob die kube-dns-Pods ohne kürzliche Neustarts ausgeführt werden. Rufen Sie dazu den Status dieser Pods auf:

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 Kennungen, 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. Verwenden Sie die Audit-Logs für Administratoraktivitäten, um zu untersuchen, ob es in letzter Zeit Änderungen wie Cluster- oder Knotenpool-Versionsupgrades oder Änderungen an der kube-dns-ConfigMap gab. Weitere Informationen zu Audit-Logs finden Sie unter Informationen zum Audit-Logging in GKE. 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, die vor Kurzem vorgenommen wurden, 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-Logeinträgen ein Fehler wie der folgende angezeigt wird, tritt bei diesen Pods ein OOM-Fehler auf:

    Warning: OOMKilling Memory cgroup out of memory

    Diese Meldung weist darauf hin, dass Kubernetes einen Prozess aufgrund eines übermäßigen Ressourcenverbrauchs beendet hat. Kubernetes plant Pods basierend auf Ressourcenanfragen, lässt aber zu, dass Pods bis zu ihren Ressourcenlimits 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.

    Diesen Fehler können Sie beheben, indem 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 Fehlerbehebung bei OOM-Ereignissen.

  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 achten Sie darauf, 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, wiederholen Sie die Schritte in diesem Abschnitt für jeden Pod.

    Wenn die Pod-Binärdatei den Befehl kubectl exec nicht unterstützt, schlägt dieser Befehl möglicherweise fehl. In diesem Fall erstellen Sie einen einfachen Pod als Testumgebung. Mit dieser Vorgehensweise können Sie einen Test-Pod im selben Namespace wie den problematischen Pod ausführen.

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

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

    • Für Pods, die kein Hostnetzwerk verwenden, sollte die kube-dns-Service-IP-Adresse 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, prüfen Sie Ihren DNS-Server und stellen Sie sicher, dass er ordnungsgemäß funktioniert.

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

        kubectl rollout restart deployment POD_NAME

        Ersetzen Sie POD_NAME durch den Namen Ihres Pods.

  3. Prüfen Sie die Einträge search und ndots in /etc/resolv.conf. Achten Sie darauf, dass keine Rechtschreibfehler oder veralteten Konfigurationen vorhanden sind und dass 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: sh oder /bin/bash

    Dieser Befehl schlägt möglicherweise fehl, wenn Ihr Pod den Befehl kubectl exec nicht zulässt oder wenn der Pod nicht die Binärdatei „dig“ hat. Erstellen Sie in diesem Fall 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 richtig auflösen kann:

    dig kubernetes

    Da die Datei /etc/resolv.conf auf die IP-Adresse des kube-dns-Dienstes verweist, ist der DNS-Server beim Ausführen dieses Befehls der kube-dns-Dienst.

    Sie sollten eine erfolgreiche DNS-Antwort mit der IP-Adresse des Kubernetes API-Dienstes (oft etwas wie 10.96.0.1) sehen. Wenn Sie SERVFAIL oder keine Antwort sehen, bedeutet dies in der Regel, 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-Abfragen 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, werden status: NOERROR und Details des A-Eintrags angezeigt, wie im folgenden Beispiel dargestellt:

     ; <<>> 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 dem Aufzeichnen von Paketen fort.

Paketerfassung durchführen

Führen Sie eine Paketerfassung durch, um zu prüfen, ob die DNS-Abfragen von den kube-dns-Pods empfangen und entsprechend 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 Cloud de Confiance Console die Seite VM-Instanzen auf.

      Zu Seite „VM-Instanzen“

    2. Suchen Sie den Knoten, zu dem Sie eine Verbindung herstellen möchten. Wenn Sie den Namen des Knotens für Ihren 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 bei der Root-Eingabeaufforderung das Paket tcpdump:

    apt update -y && apt install -y tcpdump

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

    tcpdump -i eth0 port 53" -w FILE_LOCATION

    Ersetzen Sie FILE_LOCATION durch den Pfad, unter dem Sie die Erfassung speichern möchten.

  5. Prüfen Sie die Paketerfassung. Prüfen Sie, ob es Pakete mit Ziel-IP-Adressen gibt, die mit der kube-dns-Service-IP-Adresse übereinstimmen. So wird sichergestellt, dass die DNS-Anfragen das richtige Ziel für die Auflösung erreichen. 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 sie die erforderliche DNS-Kommunikation zulässt. 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 lautet, haben Sie keine Netzwerkrichtlinien und können dies als Ursache des Problems ausschließen. Durch die Untersuchung von Logs 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. Erstellen Sie einen Pod auf Grundlage eines vorhandenen kube-dns-Pods, um Abfragen zu aktivieren. Alle Änderungen am kube-dns-Deployment werden automatisch rückgängig gemacht.

Das Aktivieren der temporären DNS-Abfrageprotokollierung ist ein ressourcenintensiver Vorgang. Wir empfehlen daher, den erstellten Pod zu löschen, sobald Sie eine geeignete Stichprobe von Logs gesammelt haben.

Führen Sie die folgenden Schritte aus, um das temporäre Logging von DNS-Abfragen zu aktivieren:

  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. Nachdem Sie 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

Sehen Sie sich an, wie kube-dns-Pods DNS-Anfragen mit Cloud Logging empfangen und auflösen.

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

  1. Rufen Sie in der Cloud de Confiance 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 in angemessener Zeit auflösen. Diese Art von Fehler kann verschiedene Ursachen haben. Beispielsweise ist der Upstream-Server möglicherweise in der kube-dns-ConfigMap falsch konfiguriert oder es gibt viel Netzwerkverkehr.

Wenn Sie Cloud Logging nicht aktiviert haben, sehen Sie sich stattdessen die Kubernetes-Logs an:

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 in 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 prüfen Sie, ob Aktualisierungen für die Einstellungen der Stub-Domain vorliegen:

  1. Rufen Sie in der Cloud de Confiance 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 ein Update sehen, maximieren Sie das Ergebnis, um mehr über die Änderungen zu erfahren. Prüfen Sie, ob alle Stub-Domains und die entsprechenden vorgelagerten DNS-Server korrekt definiert sind. Falsche Einträge können dazu führen, dass die Auflösung für diese Domains fehlschlägt.

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

  1. Rufen Sie in der Cloud de Confiance 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 mehr über die Änderungen zu erfahren. 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, ob eine der aufgeführten Änderungen den Fehler verursacht hat.

Cloud Customer Care kontaktieren

Wenn Sie die vorherigen Abschnitte durchgearbeitet haben, aber die Ursache des Problems 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 Anleitungen in den folgenden Abschnitten.

Problem: Sporadische DNS-Zeitüberschreitungen

Wenn Sie zeitweilige DNS-Auflösungstimeouts feststellen, die bei einer Zunahme des DNS-Traffics oder zu Beginn der Geschäftszeiten auftreten, können Sie die DNS-Leistung mit den folgenden Lösungen 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.

  • Aktivieren Sie NodeLocal DNSCache, um die durchschnittliche DNS-Lookup-Zeit zu verbessern.

  • Die DNS-Auflösung für externe Namen kann den kube-dns-Pod überlasten. Wenn Sie die Anzahl der Abfragen 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, um eine Abfrage vor der ersten absoluten Abfrage aufzulösen.

    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 von einigen Knoten aus zeitweise fehl

Wenn DNS-Abfragen von einigen Knoten 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ühre 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 Cloud de Confiance 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 feststellen, 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 Version des Knotenpools und achten Sie darauf, dass sie mit der Steuerungsebene und anderen Worker-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 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