Fehlerbehebung bei Cloud DNS in GKE

Auf dieser Seite wird beschrieben, wie Sie Probleme mit Cloud DNS in 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 weisen oft auf Probleme bei der Fähigkeit von Cloud 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 Abschnitte sind so angeordnet, dass Sie mit den Schritten beginnen, die Ihnen am wahrscheinlichsten helfen. Arbeiten Sie die Abschnitte daher der Reihe nach durch.

Grundeinstellungen ü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 erfahren Sie, wie 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 Sie einen anderen Wert sehen, verwenden Sie Cloud DNS nicht. 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 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 sehen Sie, dass der Wert im Feld name angibt, 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. DNS-Einträge für Ihren Dienst überprüfen:

    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 etwa so aus:

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

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

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

Antwortrichtlinien prüfen

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

  1. So rufen Sie eine Liste aller Ihrer Antwortrichtlinien auf:

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

    Die Ausgabe sieht 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 sehen Sie unter gke-CLUSTER_NAME-52c8f518-rp, 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 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.

    In der ersten Spalte sehen Sie das IP-Adress- oder Domainnamensmuster, das mit der Regel übereinstimmt. Die zweite Spalte enthält den Hostnamen, der mit der IP-Adresse verknüpft ist.

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

Mithilfe von Logs, Dashboards und Messwerten untersuchen

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

Nach neuen Einträgen suchen

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

So prüfen Sie, ob neue Datensätze vorhanden sind:

  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.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, an dem Sie die Fehler zum ersten Mal bemerkt haben, sollten Sie sie rückgängig machen.

Benutzerdefinierte Stub-Domains und Nameserver überprüfen

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

Cloud DNS übersetzt die Werte stubDomains und upstreamNameservers in Cloud DNS-Weiterleitungszonen. Google verwaltet diese Ressourcen. Wenn Sie Fehler feststellen, wenden Sie sich an Cloud Customer Care.

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.

Spezifische Fehler beheben

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

Problem: GKE-Clusterdienst kann nicht über eine 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 Bereich, 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 derselben VPC, z. B. Google Cloud -VMs, auflösen.

Führen Sie die folgenden Schritte aus, um den Cloud DNS-Bereich Ihres Clusters zu überprüfen:

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

    Zur Seite "Kubernetes-Cluster"

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

  3. Sehen Sie sich auf der Seite mit den Clusterdetails im Abschnitt Clusternetzwerk die Informationen in der Zeile DNS-Anbieter an.

  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 kube-dns weiterhin, nachdem Cloud DNS aktiviert wurde

Wenn Ihre Pods kube-dns verwenden, auch nachdem Cloud DNS in einem vorhandenen Cluster aktiviert wurde, 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 mit aktiviertem additivem Cloud DNS-VPC-Bereich erstellt werden

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: Fehler beim Senden von Anfragen an Cloud DNS: 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 mit der 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