Fehlerbehebung bei Cloud DNS in GKE

Auf dieser Seite wird beschrieben, wie Sie Probleme mit Cloud DNS in der Google Kubernetes Engine (GKE) beheben.

Quelle von DNS-Problemen in Cloud DNS ermitteln

Fehler wie dial tcp: i/o timeout, no such host oder Could not resolve host deuten oft auf Probleme bei der Auflösung von Abfragen durch Cloud DNS hin.

Wenn einer dieser Fehler angezeigt wird, Sie aber nicht wissen, was die Ursache ist, finden Sie in den folgenden Abschnitten weitere Informationen. Die Abschnitte sind so angeordnet, dass mit den Schritten begonnen wird, die Ihnen am ehesten weiterhelfen. Probieren Sie daher jeden Abschnitt der Reihe nach aus.

Grundlegende Einstellungen überprüfen

Wenn Ihr Pod keine DNS-Lookups auflösen kann, prüfen Sie, ob Cloud DNS wie gewünscht konfiguriert ist. In diesem Abschnitt können Sie prüfen, ob Sie Cloud DNS verwenden, ob eine private DNS-Zone für den GKE-Cluster vorhanden ist und ob die DNS-Einträge für den Zieldienst korrekt sind.

Führen Sie die folgenden Befehle aus, um diese Einstellungen zu überprüfen:

  1. Prüfen Sie, welchen DNS-Server Ihr Pod verwendet:

    kubectl exec -it POD_NAME -- cat /etc/resolv.conf | grep nameserver

    Ersetzen Sie POD_NAME durch den Namen des Pods, bei dem Probleme mit der DNS-Auflösung auftreten.

    Wenn Sie Cloud DNS verwenden, sieht die Ausgabe so aus:

    nameserver 169.254.169.254

    Wenn ein anderer Wert angezeigt wird, verwenden Sie kein Cloud DNS. Prüfen Sie, ob Cloud DNS ordnungsgemäß aktiviert wurde.

  2. Prüfen Sie, ob die verwalteten Zonen vorhanden sind:

    gcloud dns managed-zones list --format list

    Die Ausgabe sieht in etwa so aus:

    - creationTime: 2021-02-12T19:24:37.045Z
  description: Private zone for GKE cluster "" with cluster suffix "CLUSTER_DOMAIN" in project "PROJECT_ID"
  dnsName: CLUSTER_DOMAIN.
  id: 5887499284756055830
  kind: dns#managedZone
  name: gke-CLUSTER_NAME-aa94c1f9-dns
  nameServers: ['ns-gcp-private.googledomains.com.']
  privateVisibilityConfig: {'kind': 'dns#managedZonePrivateVisibilityConfig'}
  visibility: private

    Diese Ausgabe enthält die folgenden Werte:

    • CLUSTER_DOMAIN: das DNS-Domainsuffix, das Ihrem Cluster automatisch zugewiesen wurde.
    • PROJECT_ID: Ihre Projekt-ID.
    • CLUSTER_NAME: Der Name des Clusters mit der privaten Zone.

    In dieser Ausgabe zeigt der Wert im Feld name an, dassGoogle Cloud eine Zone mit dem Namen gke-CLUSTER_NAME-aa94c1f9-dns erstellt hat.

    Wenn Sie keine verwaltete Zone sehen, wurde für Ihren Cluster keine private Zone erstellt oder Sie sind möglicherweise nicht richtig authentifiziert. Informationen zur Fehlerbehebung finden Sie in der Cloud DNS-Dokumentation unter Private Zonen.

  3. Prüfen Sie die DNS-Einträge für Ihren Dienst:

    gcloud dns record-sets list --zone ZONE_NAME | grep SERVICE_NAME

    Ersetzen Sie Folgendes:

    • ZONE_NAME ist der Name der privaten Zone.
    • SERVICE_NAME: Der Name des Diensts.

    Die Ausgabe sieht in etwa so aus:

    dns-test.default.svc.cluster.local.                A     30     10.47.255.11

    Die Ausgabe zeigt, dass Cloud DNS einen A-Eintrag für die Domain dns-test.default.svc.cluster.local. und die IP-Adresse des Clusters 10.47.255.11 enthält.

    Wenn die Einträge falsch aussehen, lesen Sie den Abschnitt Ressourceneintragssatz patchen in der Cloud DNS-Dokumentation, um sie zu aktualisieren.

Antwortrichtlinien prüfen

Prüfen Sie, ob Ihre Antwortrichtlinien vorhanden sind und richtig benannt sind:

  1. So rufen Sie eine Liste aller Antwortrichtlinien auf:

    gcloud dns response-policies list --format="table(responsePolicyName, description)"

    Die Ausgabe sieht in etwa so aus:

    RESPONSE_POLICY_NAME          DESCRIPTION
gke-CLUSTER_NAME-52c8f518-rp  Response Policy for GKE cluster "CLUSTER_NAME" with cluster suffix "cluster.local." in project "gke-dev" with scope "CLUSTER_SCOPE".

    In dieser Ausgabe zeigt gke-CLUSTER_NAME-52c8f518-rp an, dassGoogle Cloud eine private Zone mit dem Namen gke-CLUSTER_NAME-aa94c1f9-rp erstellt hat. Antwortrichtlinien, die vonGoogle Cloud erstellt werden, haben das Präfix gke-.

  2. So rufen Sie Antwortrichtlinien in einer bestimmten privaten Zone auf:

    gcloud dns response-policies rules list ZONE_NAME \
    --format="table(localData.localDatas[0].name, localData.localDatas[0].rrdatas[0])"

    Ersetzen Sie ZONE_NAME durch den Namen der privaten Zone, in der Probleme auftreten.

    Die Ausgabe sieht in etwa so aus:

    1.240.27.10.in-addr.arpa.    kubernetes.default.svc.cluster.local.
52.252.27.10.in-addr.arpa.   default-http-backend.kube-system.svc.cluster.local.
10.240.27.10.in-addr.arpa.   kube-dns.kube-system.svc.cluster.local.
146.250.27.10.in-addr.arpa.  metrics-server.kube-system.svc.cluster.local.

    Die erste Spalte enthält das IP‑Adress- oder Domainnamenmuster, mit dem die Regel übereinstimmt. Die zweite Spalte ist der Hostname, der mit der IP-Adresse verknüpft ist.

Wenn Sie Probleme mit der Ausgabe dieser Befehle feststellen, lesen Sie den Hilfeartikel Antwortrichtlinienregel aktualisieren in der Cloud DNS-Dokumentation.

Mit Logs, Dashboards und Messwerten untersuchen

Cloud DNS bietet mehrere Logging- und Monitoring-Optionen, mit denen Sie DNS-Probleme weiter untersuchen können:

Nach neuen Einträgen suchen

Prüfen Sie in den Protokollen, ob in der verwalteten privaten Cloud DNS-Zone neue Einträge erstellt wurden. Das kann hilfreich sein, wenn plötzlich DNS-Auflösungen im Cluster fehlschlagen.

So prüfen Sie, ob neue Einträge vorhanden sind:

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

    Zum Log-Explorer

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

    resource.type="dns_managed_zone"
protoPayload.request.change.additions.name="headless-svc-stateful.default.svc.cluster.local."
protoPayload.methodName="dns.changes.create"

  3. Klicken Sie auf Abfrage ausführen.

  4. Sehen Sie sich die Ausgabe an. Wenn Sie Änderungen finden, die mit dem Zeitpunkt übereinstimmen, zu dem Sie die Fehler zum ersten Mal bemerkt haben, sollten Sie sie rückgängig machen.

Benutzerdefinierte Stub-Domains und Nameserver prüfen

Wenn Sie einen GKE Standard-Cluster mit einer benutzerdefinierten Stub-Domain oder einem Upstream-Nameserver verwenden, prüfen Sie die ConfigMap und achten Sie darauf, dass die Werte korrekt sind.

Cloud DNS übersetzt die Werte stubDomains und upstreamNameservers in Cloud DNS-Weiterleitungszonen. Diese Ressourcen werden von Google verwaltet. Wenn Sie Fehler bemerken, wenden Sie sich bitte an den Cloud-Kundenservice.

Cloud Customer Care kontaktieren

Wenn Sie die vorherigen Abschnitte durchgearbeitet haben, die Ursache des Problems aber immer noch nicht gefunden haben, wenden Sie sich an den Cloud-Kundenservice.

Bestimmte Fehler beheben

Wenn ein bestimmter Fehler oder ein bestimmtes Problem auftritt, folgen Sie der Anleitung in den folgenden Abschnitten.

Problem: GKE-Clusterdienst kann nicht von einer Compute Engine-VM aufgelöst werden

Wenn Sie einen GKE-Clusterdienst nicht von einer Compute Engine-VM aus auflösen können, prüfen Sie den Cloud DNS-Bereich des Clusters.

Der Umfang, den Sie mit Cloud DNS verwenden, bestimmt, welche Ressourcen aufgelöst werden können:

  • Clusterbereich: Die DNS-Auflösung ist auf Ressourcen innerhalb des Kubernetes-Clusters (Pods und Dienste) beschränkt. Dies ist die Standardeinstellung und eignet sich, wenn Sie keine externen Ressourcen außerhalb des Kubernetes-Clusters oder der GKE Virtual Private Cloud (VPC) auflösen müssen.

  • VPC-Bereich: Die DNS-Auflösung erstreckt sich auf die gesamte VPC, einschließlich Ressourcen wie Compute Engine-VMs. So kann der Cluster interne DNS-Einträge für Ressourcen außerhalb des GKE-Cluster, aber innerhalb desselben VPC auflösen, z. B. Google Cloud VMs.

So überprüfen Sie den Cloud DNS-Bereich Ihres Clusters:

  1. Rufen Sie in der Google Cloud -Konsole die Seite Kubernetes-Cluster auf.

    Zur Seite "Kubernetes-Cluster"

  2. Klicken Sie auf den Namen des Clusters, bei dem Probleme mit dem DNS auftreten.

  3. Prüfen Sie auf der Seite „Clusterdetails“ im Abschnitt Clusternetzwerk die Informationen in der Zeile DNS-Anbieter.

  4. Wenn Sie Cloud DNS (Clusterbereich) sehen, verwenden Sie den Clusterbereich. Wenn Sie den DNS-Bereich ändern möchten, erstellen Sie den Cluster mit dem entsprechenden DNS-Bereich neu.

Problem: Pods verwenden nach der Aktivierung von Cloud DNS weiterhin kube-dns

Wenn Ihre Pods auch dann kube-dns verwenden, wenn Cloud DNS in einem vorhandenen Cluster aktiviert ist, müssen Sie Ihre Knotenpools aktualisieren oder neu erstellen, nachdem Sie Cloud DNS im Cluster aktiviert haben. Bis dieser Schritt abgeschlossen ist, verwenden Pods weiterhin kube-dns.

Problem: Vorhandener Cluster kann nicht aktualisiert oder Cluster mit aktiviertem Cloud DNS kann nicht erstellt werden

Prüfen Sie, ob Sie die richtige Version verwenden. Cloud DNS für GKE erfordert die GKE-Version 1.19 oder höher für Cluster mit VPC-Bereich oder die GKE-Version 1.24.7-gke.800, 1.25.3-gke.700 oder höher für Cluster mit Clusterbereich.

Problem: DNS-Lookups auf Knoten schlagen fehl, nachdem Cloud DNS in einem Cluster aktiviert wurde

Wenn Sie den Clusterbereich Cloud DNS in einem GKE-Cluster mit benutzerdefinierten Stub-Domains oder vorgelagerten Nameservern aktivieren, gilt die benutzerdefinierte Konfiguration sowohl für Knoten als auch für Pods im Cluster, da Cloud DNS nicht zwischen DNS-Anfragen von Pods und Knoten unterscheiden kann. DNS-Lookups auf Knoten können fehlschlagen, wenn der benutzerdefinierte vorgelagerte Server die Abfragen nicht auflösen kann.

Problem: Cluster kann nicht aktualisiert oder erstellt werden, wenn der additive VPC-Bereich von Cloud DNS aktiviert ist

Prüfen Sie, ob Sie die richtige Version verwenden. Für den additiven Cloud DNS-VPC-Bereich ist die GKE-Version 1.28 oder höher erforderlich.

Fehler: Cloud DNS deaktiviert

Das folgende Ereignis tritt auf, wenn die Cloud DNS API deaktiviert ist:

Warning   FailedPrecondition        service/default-http-backend
Failed to send requests to Cloud DNS: Cloud DNS API Disabled. Please enable the Cloud DNS API in your project PROJECT_NAME: Cloud DNS API has not been used in project PROJECT_NUMBER before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/dns.googleapis.com/overview?project=PROJECT_NUMBER then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.

Dieser Fehler tritt auf, weil die Cloud DNS API nicht standardmäßig aktiviert ist. Sie müssen die Cloud DNS API manuell aktivieren.

Aktivieren Sie die Cloud DNS API, um das Problem zu beheben.

Fehler: Anfragen an Cloud DNS konnten nicht gesendet werden: API-Ratenbegrenzung überschritten

Das folgende Ereignis tritt auf, wenn ein Projekt ein Cloud DNS-Kontingent oder -Limit überschreitet:

kube-system   27s         Warning   InsufficientQuota
managedzone/gke-cluster-quota-ee1bd2ca-dns     Failed to send requests to Cloud DNS: API rate limit exceeded. Contact Google Cloud support team to request a quota increase for your project PROJECT_NAME: Quota exceeded for quota metric 'Write requests' and limit 'Write limit for a minute for a region' of service 'dns.googleapis.com' for consumer 'project_number:PROJECT_NUMBER.

Informationen zum Beheben dieses Problems finden Sie unter Cloud DNS-Kontingente und Compute Engine-Kontingente und -Limits. Sie können das Kontingent über die Google Cloud Console erhöhen.

Fehler: Aufgrund eines vorherigen Fehlers konnte keine Anfrage an Cloud DNS gesendet werden

Das folgende Ereignis tritt auf, wenn Fehler zu kaskadierenden Ausfällen führen:

kube-system   27s         Warning   InsufficientQuota
managedzone/gke-cluster-quota-ee1bd2ca-dns     Failed to send requests to Cloud DNS: API rate limit exceeded. Contact Google Cloud support team to request a quota increase for your project PROJECT_NAME: Quota exceeded for quota metric 'Write requests' and limit 'Write limit for a minute for a region' of service 'dns.googleapis.com' for consumer 'project_number:PROJECT_NUMBER.
kube-system   27s         Warning   FailedPrecondition               service/default-http-backend                         Failed to send requests to Cloud DNS due to a previous error. Please check the cluster events.

Prüfen Sie zur Behebung dieses Problems die Clusterereignisse, um die Quelle des ursprünglichen Fehlers zu finden, und folgen Sie der Anleitung.

Im vorherigen Beispiel hat der Fehler InsufficientQuota für die verwaltete Zone kaskadierende Ausfälle ausgelöst. Der zweite Fehler für FailedPrecondition gibt an, dass ein vorheriger Fehler aufgetreten ist, bei dem es sich um das anfängliche Problem mit unzureichendem Kontingent handelt. Zur Behebung dieses Beispielproblems folgen Sie der Anleitung für den Cloud DNS-Kontingentfehler.

Fehler: Antwortrichtlinie konnte nicht gebunden werden

Das folgende Ereignis tritt auf, wenn eine Antwortrichtlinie an das Netzwerk des Clusters gebunden ist und Cloud DNS for GKE versucht, eine Antwortrichtlinie an das Netzwerk zu binden:

kube-system   9s          Warning   FailedPrecondition               responsepolicy/gke-2949673445-rp
Failed to bind response policy gke-2949673445-rp to test. Please verify that another Response Policy is not already associated with the network: Network 'https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/networks/NETWORK_NAME' cannot be bound to this response policy because it is already bound to another response policy.
kube-system   9s          Warning   FailedPrecondition               service/kube-dns
Failed to send requests to Cloud DNS due to a previous error. Please check the cluster events.

So beheben Sie das Problem:

  1. Rufen Sie die Antwortrichtlinie ab, die an das Netzwerk gebunden ist:

    gcloud dns response-policies list --filter='networks.networkUrl: NETWORK_URL'

    Ersetzen Sie NETWORK_URL durch die Netzwerk-URL aus dem Fehler, z. B. https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/NETWORK_NAME.

    Wenn die Ausgabe leer ist, befindet sich die Antwortrichtlinie möglicherweise nicht im selben Projekt. Fahren Sie mit dem nächsten Schritt fort, um nach der Antwortrichtlinie zu suchen.

    Wenn die Ausgabe in etwa so aussieht, fahren Sie mit Schritt 4 fort, um die Antwortrichtlinie zu löschen.

    [
   {
      "description": "Response Policy for GKE cluster \"CLUSTER_NAME\" with cluster suffix \"cluster.local.\" in project \"PROJECT_ID\" with scope \"CLUSTER_SCOPE\".",
      ...
      "kind": "dns#responsePolicy",
      "responsePolicyName": "gke-CLUSTER_NAME-POLICY_ID-rp"
   }
]

  2. Rufen Sie mit dem IAM Policy Analyzer eine Liste der Projekte mit der Berechtigung dns.networks.bindDNSResponsePolicy ab.

  3. Prüfen Sie, ob jedes Projekt die Antwortrichtlinie hat, die an das Netzwerk gebunden ist:

    gcloud dns response-policies list --filter='networks.networkUrl:NETWORK_URL' \
    --project=PROJECT_NAME

  4. Löschen Sie die Antwortrichtlinie.

Fehler: Ungültige Konfiguration in kube-dns angegeben

Das folgende Ereignis tritt auf, wenn Sie eine benutzerdefinierte kube-dns-ConfigMap anwenden, die für Cloud DNS for GKE nicht gültig ist:

kube-system   49s         Warning   FailedValidation                 configmap/kube-dns
Invalid configuration specified in kube-dns: error parsing stubDomains for ConfigMap kube-dns: dnsServer [8.8.8.256] validation: IP address "8.8.8.256" invalid

Folgen Sie den Details im Fehler, um den ungültigen Teil der ConfigMap zu korrigieren und das Problem zu beheben. Im vorherigen Beispiel ist 8.8.8.256 keine gültige IP-Adresse.

Nächste Schritte