Cloud DNS für GKE verwenden

Auf dieser Seite wird erläutert, wie Sie Cloud DNS als Kubernetes-DNS-Anbieter für Google Kubernetes Engine (GKE) verwenden.

Wenn Sie Cloud DNS als DNS-Anbieter verwenden, können Clients außerhalb eines Clusters keine Kubernetes-Dienste auflösen und direkt erreichen. Sie müssen die Dienste weiterhin extern über einen Load-Balancer freigeben und die externen IP-Adressen des Clusters in Ihrer DNS-Infrastruktur registrieren.

Weitere Informationen zur Verwendung von kube-dns als DNS-Anbieter finden Sie unter Diensterkennung und DNS.

Informationen zur Verwendung einer benutzerdefinierten Version von kube-dns oder benutzerdefinierten DNS-Anbietern finden Sie unter Benutzerdefiniertes kube-dns-Deployment einrichten.

Funktionsweise von Cloud DNS für GKE

Cloud DNS kann als DNS-Anbieter für GKE verwendet werden und bietet Pod- und Dienst-DNS-Auflösung mit verwaltetem DNS, für das kein Cluster-gehosteter DNS-Anbieter erforderlich ist. DNS-Einträge für Pods und Dienste werden in Cloud DNS automatisch für Cluster-IP-Adresse-Dienste, monitorlose Dienste und externe Namensdienste bereitgestellt.

Cloud DNS unterstützt die vollständige Kubernetes DNS-Spezifikation und bietet eine Auflösung für A-, AAAA-, SRV- und PTR-Einträge für Dienste in einem GKE-Cluster. PTR-Einträge werden mithilfe von Antwortrichtlinienregeln implementiert.

Die Verwendung von Cloud DNS als DNS-Anbieter für GKE bietet gegenüber dem DNS, das im Cluster gehostet wird, viele Vorteile:

  • Kein Aufwand für die Verwaltung des im Cluster gehosteten DNS-Servers. Cloud DNS erfordert keine Skalierung, Überwachung oder Verwaltung von DNS-Instanzen, da es ein vollständig verwalteter Dienst in der hoch skalierbaren Google-Infrastruktur ist.
  • Lokale Auflösung der DNS-Abfragen auf jedem GKE-Knoten. Ähnlich wie NodeLocal DNSCache speichert Cloud DNS die DNS-Antworten lokal im Cache und bietet DNS-Auflösung mit niedriger Latenz und hoher Skalierbarkeit.

Architektur

Wenn Cloud DNS der DNS-Anbieter für GKE ist, wird ein Controller als von GKE verwalteter Pod ausgeführt. Dieser Pod wird auf den Knoten der Steuerungsebene Ihres Clusters ausgeführt und synchronisiert die DNS-Einträge des Clusters mit einer verwalteten privaten DNS-Zone.

Das folgende Diagramm zeigt, wie Clusternamen von der Cloud DNS-Steuerungsebene und der Datenebene aufgelöst werden:

Ein Pod fordert mit Cloud DNS die IP-Adresse eines Dienstes an.
Diagramm: Clusternamen auflösen

Im Diagramm wählt der Dienst backend die laufenden backend-Pods aus. clouddns-controller erstellt einen DNS-Eintrag für den Dienst backend.

Der Pod frontend sendet eine DNS-Anfrage, um die IP-Adresse des Dienstes backend an den lokalen Compute Engine-Metadatenserver unter 169.254.169.254 aufzulösen. Der Metadatenserver wird lokal auf dem Knoten ausgeführt und sendet Cache-Fehler an Cloud DNS.

Die Cloud DNS-Datenebene wird lokal in jedem GKE-Knoten oder in jeder Compute Engine-VM-Instanz ausgeführt. Je nach Typ des Kubernetes-Dienstes löst Cloud DNS den Dienstnamen in die virtuelle IP-Adresse (bei Cluster-IP-Diensten) oder die Liste der Endpunkt-IP-Adressen (bei monitorlosen Diensten) auf.

Nachdem der Pod frontend die IP-Adresse aufgelöst hat, kann der Pod Traffic an den Dienst backend und alle Pods hinter dem Dienst senden.

DNS-Bereiche

Cloud DNS nutzt die folgenden DNS-Bereiche. Ein Cluster kann nicht in mehreren Modi gleichzeitig ausgeführt werden.

  • GKE-Clusterbereich: DNS-Einträge können nur innerhalb des Clusters aufgelöst werden. Dies entspricht dem Verhalten von kube-dns. Nur Knoten, die im GKE-Cluster ausgeführt werden, können Dienstnamen auflösen. Cluster haben standardmäßig DNS-Namen, die auf *.cluster.local enden. Diese DNS-Namen sind nur innerhalb des Clusters sichtbar und überschneiden sich nicht mit *.cluster.local-DNS-Namen für andere GKE-Cluster im selben Projekt. Dies ist der Standardmodus.

    • Additiver VPC-Bereich für Cloud DNS:

      Der additive VPC-Bereich von Cloud DNS ist ein optionales Feature, das den GKE-Clusterbereich erweitert, um monitorlose Dienste von anderen Ressourcen in der VPC aufzulösen, z. B. von Compute Engine-VMs oder lokalen Clients, die über Cloud VPN verbunden sind oder Cloud Interconnect. Der additive VPC-Bereich ist ein zusätzlicher Modus, der neben dem Clusterbereich aktiviert wird. Sie können ihn in Ihrem Cluster aktivieren oder deaktivieren, ohne DNS-Betriebszeit zu beeinflussen oder -Fähigkeit (Clusterbereich).

  • VPC-Bereich: DNS-Einträge können in der gesamten VPC aufgelöst werden. Compute Engine-VMs und lokale Clients können über Cloud Interconnect oder Cloud VPN eine Verbindung herstellen und GKE-Dienstnamen direkt auflösen. Sie müssen für jeden Cluster eine eindeutige benutzerdefinierte Domain festlegen. Dies bedeutet, dass alle Dienst- und Pod-DNS-Einträge innerhalb der VPC eindeutig sind. Dieser Modus reduziert die Kommunikationsgeschwindigkeit zwischen GKE- und Nicht-GKE-Ressourcen.

In der folgenden Tabelle werden die Unterschiede zwischen DNS-Bereichen aufgeführt:

Funktion GKE-Clusterbereich: Additiver Cloud DNS-VPC-Bereich VPC-Bereich
Umfang der DNS-Einblicke Nur innerhalb des GKE-Clusters Wird auf das gesamte VPC-Netzwerk erweitert. Gesamtes VPC-Netzwerk
Auflösung von monitorlosen Diensten Im Cluster auflösbar Auflösbar innerhalb des Clusters mit "cluster.local" und in der VPC mithilfe des Clustersuffixes Auflösbar innerhalb des Clusters und in der gesamten VPC mithilfe des Clustersuffixes
eindeutige Domain nötig Nein. Verwendet den Standardwert "*.cluster.local". Ja, Sie müssen eine eindeutige benutzerdefinierte Domain festlegen Ja, Sie müssen eine eindeutige benutzerdefinierte Domain festlegen
Einrichtungs-Konfiguration Standardeinstellung, keine zusätzlichen Schritte Bei Clustererstellung optional
Kann jederzeit aktiviert/deaktiviert werden		 Muss während der Clustererstellung konfiguriert werden

Cloud DNS-Ressourcen

Wenn Sie Cloud DNS als DNS-Anbieter für Ihren GKE-Cluster verwenden, erstellt der Cloud DNS-Controller Ressourcen in Cloud DNS für Ihr Projekt. Welche Ressourcen GKE erstellt, hängt vom Cloud DNS-Bereich ab.

Umfang Forward-Lookup-Zone Reverse-Lookup-Zone
Clusterbereich 1 private Zone pro Cluster pro Compute Engine-Zone (in der Region) 1 Antwortrichtlinienzone pro Cluster pro Compute Engine-Zone (in der Region)
Additiver Cloud DNS-VPC-Bereich 1 private Zone pro Cluster pro Compute Engine-Zone (in der Region) pro Cluster (globale Zone)
1 VPC-bezogen Private Zone pro Cluster (globale Zone) 		1 Antwortrichtlinienzone pro Cluster pro Compute Engine-Zone (in der Region) pro Cluster (globale Zone)
1 VPC-bezogene Zone für Antwortrichtlinie pro Cluster (globale Zone)
VPC-Bereich 1 private Zone pro Cluster (globale Zone) 1 Antwortrichtlinienzone pro Cluster (globale Zone)

Für diese Cloud DNS-Ressourcen wird folgende Namenskonvention verwendet:

Umfang Forward-Lookup-Zone Reverse-Lookup-Zone
Clusterbereich gke-CLUSTER_NAME-CLUSTER_HASH-dns gke-CLUSTER_NAME-CLUSTER_HASH-rp
Additiver Cloud DNS-VPC-Bereich gke-CLUSTER_NAME-CLUSTER_HASH-dns für clusterbezogene Zonen
gke-CLUSTER_NAME-CLUSTER_HASH-dns-vpc für VPC-bezogene Zonen 		gke-CLUSTER_NAME-CLUSTER_HASH-rp für clusterbezogene Zonen
gke-NETWORK_NAME_HASH-rp für clusterbezogene Zonen
VPC-Bereich gke-CLUSTER_NAME-CLUSTER_HASH-dns gke-NETWORK_NAME_HASH-rp

Zusätzlich zu den in der vorherigen Tabelle genannten Zonen erstellt der Cloud DNS-Controller je nach Konfiguration die folgenden Zonen in Ihrem Projekt:

Benutzerdefinierte DNS-Konfiguration Zonentyp Namenskonvention für Zonen
Stub-Domain Weiterleitung (globale Zone) gke-CLUSTER_NAME-CLUSTER_HASH-DOMAIN_NAME_HASH
Benutzerdefinierte vorgelagerte Nameserver Weiterleitung (globale Zone) gke-CLUSTER_NAME-CLUSTER_HASH-upstream

Weitere Informationen zum Erstellen von benutzerdefinierten Stub-Domains oder benutzerdefinierten vorgelagerten Nameservern finden Sie unter Benutzerdefinierte Resolver für Stub-Domains hinzufügen.

Verwaltete Zonen und Weiterleitungszonen

Zur Bereitstellung des internen DNS-Traffics erstellt der Cloud DNS-Controller eine verwaltete DNS-Zone in jeder Compute Engine-Zone der Region, zu der der Cluster gehört.

Wenn Sie beispielsweise einen Cluster in der Zone us-central1-c bereitstellen, erstellt der Cloud DNS-Controller eine verwaltete Zone in us-central1-a, us-central1-b, us-central1-c und us-central1-f:

Für jede DNS-stubDomain erstellt der Cloud DNS-Controller eine Weiterleitungszone.

Cloud DNS verarbeitet jedes DNS-Upstream mithilfe einer verwalteten Zone mit dem DNS-Namen ..

Preise

Wenn Cloud DNS der DNS-Anbieter für GKE-Standardcluster ist, werden DNS-Abfragen von Pods innerhalb des GKE-Clusters gemäß den Preisen für Cloud DNS abgerechnet.

Abfragen an eine von GKE verwaltete VPC-bezogene DNS-Zone werden zu den Standardpreisen für Cloud DNS abgerechnet.

Voraussetzungen

Die Cloud DNS API muss in Ihrem Projekt aktiviert sein.

Cloud DNS für GKE hat folgende Anforderungen an den Clusterbereich:

  • Für Standard, GKE-Version 1.24.7-gke.800, 1.25.3-gke.700 oder höher.
  • Für Autopilot, GKE-Version 1.25.9-gke.400, 1.26.4-gke.500 oder höher.
  • Google Cloud CLI-Version 411.0.0 oder höher.

Cloud DNS für GKE hat folgende Anforderungen an den additiven VPC-Bereich:

  • Für Standard, GKE-Version 1.24.7-gke.800, 1.25.3-gke.700 oder höher.
  • Für Autopilot, GKE-Version 1.28 oder höher.
  • Google Cloud CLI-Version 471.0.0.
  • Der GKE-Cluster muss den Cloud DNS-Clusterbereich als Standard-DNS-Anbieter verwenden.

Cloud DNS für GKE hat folgende Anforderungen an den VPC-Bereich:

  • Für Standard, GKE-Version 1.19 oder höher.
  • Google Cloud CLI-Version 364.0.0 oder höher.
  • Die Cloud DNS API muss in Ihrem Projekt aktiviert sein.

Limits und Einschränkungen

Es gelten folgende Einschränkungen:

  • Der VPC-Bereich wird auf Autopilot-Clustern nicht unterstützt, sondern nur der Clusterbereich. Wenn Sie monitorlose Dienstnamen auflösen müssen, die in GKE Autopilot-Clustern ausgeführt werden, müssen Sie einen additiven VPC-Bereich verwenden.
  • Cloud DNS ist nicht mit einer IL4-Compliance-Richtlinie (Impact Level 4) konform. Cloud DNS für GKE kann nicht in einer Assured Workloads-Umgebung mit einer IL4-Compliance-Richtlinie verwendet werden. Sie müssen kube-dns in einer solchen regulierten Umgebung verwenden. Bei GKE Autopilot-Clustern erfolgt die Auswahl von kube-dns oder Cloud DNS automatisch anhand Ihrer Compliance-Richtlinie.
  • Manuelle Änderungen an den verwalteten privaten DNS-Zonen werden nicht unterstützt und vom Cloud DNS-Controller überschrieben. Änderungen an den DNS-Einträgen in diesen Zonen gehen verloren, wenn der Controller neu gestartet wird.
  • Sie können den DNS-Bereich in einem Cluster nicht mehr ändern, nachdem Sie den Bereich mit dem Flag --cluster-dns-scope festgelegt haben. Wenn Sie den DNS-Bereich ändern müssen, erstellen Sie den Cluster mit einem anderen DNS-Bereich neu.
  • Benutzerdefinierte Stub-Domains und vorgelagerte DNS-Serverkonfigurationen gelten für die DNS-Konfigurationen von Pods und Knoten. Pods, die das Hostnetzwerk oder Prozesse verwenden, die direkt auf dem Host ausgeführt werden, verwenden auch die Stub-Domain und die vorgelagerten Nameserver-Konfigurationen. Dies wird nur in Standard unterstützt.
  • Benutzerdefinierte Stub-Domains und vorgelagerte Nameserver, die über die kube-dns Configmap konfiguriert wurden, werden für den Clusterbereich-DNS automatisch auf Cloud DNS angewendet. Das VPC-Bereichs-DNS ignoriert die kube-dns-ConfigMap und Sie müssen diese Konfigurationen direkt auf Cloud DNS anwenden. Dies wird nur in Standard unterstützt.
  • Es gibt keinen Migrationspfad von kube-dns zum VPC-Bereich. Der Vorgang ist disruptiv. Erstellen Sie den Cluster neu, wenn Sie von kube-dns zum VPC-Bereich oder umgekehrt wechseln.
  • Für den VPC-Bereich darf der sekundäre IP-Adressbereich für Dienste nicht für andere Cluster in diesem Subnetzwerk freigegeben werden.
  • Für den VPC-Bereich ist die mit einem PTR-Eintrag verknüpfte Antwortrichtlinie an das VPC-Netzwerk angehängt. Wenn andere Antwortrichtlinien an das Clusternetzwerk gebunden sind, schlägt die Auflösung des PTR-Eintrags für IP-Adressen von Kubernetes-Diensten fehl.
  • Wenn Sie versuchen, einen monitorlosen Dienst mit einer Anzahl von Pods zu erstellen, die das zulässige Kontingent überschreitet, erstellt Cloud DNS keine Eintragssätze oder Einträge für den Dienst.

Kontingente

Cloud DNS verwendet Kontingente, um die Anzahl der Ressourcen zu begrenzen, die GKE für DNS-Einträge erstellen kann. Die Kontingente und Limits für Cloud DNS. können sich von den Einschränkungen von kube-dns für Ihr Projekt unterscheiden.

Bei Verwendung von Cloud DNS für GKE gelten für jede verwaltete Zone in Ihrem Projekt die folgenden Standardkontingente:

Kubernetes-DNS-Ressource Entsprechende Cloud DNS-Ressource Kontingent
Anzahl der DNS-Einträge Maximale Byte pro verwaltete Zone 2.000.000 (max. 50 MB für eine verwaltete Zone)
Anzahl der Pods pro monitorlosem Dienst (IPv4/IPv6) Anzahl der Einträge pro Ressourceneintragssatz GKE 1.24 bis 1.25: 1.000 (IPv4/IPv6)
GKE 1.26 und höher: 3.500/2.000 (IPv4/IPv6)
Anzahl der GKE-Cluster in einem Projekt Anzahl der Antwortrichtlinien pro Projekt 100
Anzahl der PTR-Einträge pro Cluster Anzahl der Regeln pro Antwortrichtlinie 100.000

Ressourcenlimits

Die Kubernetes-Ressourcen, die Sie pro Cluster erstellen, tragen zu Limits für Cloud DNS-Ressourcen bei, wie in der folgenden Tabelle beschrieben:

Limit Beitrag zum Limit
Ressourceneintragssätze pro verwalteter Zone Anzahl der Dienste plus Anzahl der monitorlosen Dienstendpunkte mit gültigen Hostnamen pro Cluster.
Einträge pro Ressourceneintragssatz Anzahl der Endpunkte pro monitorlosem Dienst. Dies hat keine Auswirkungen auf andere Diensttypen.
Anzahl der Regeln pro Antwortrichtlinie Für Clusterbereich: Anzahl der Dienste plus Anzahl der monitorlosen Dienstendpunkte mit gültigen Hostnamen pro Cluster. Für VPC-Bereich: Anzahl der Dienste plus Anzahl der monitorlosen Endpunkte mit Hostnamen aus allen Clustern in der VPC.

Weitere Informationen zum Erstellen von DNS-Einträgen für Kubernetes finden Sie unter DNS-basierte Service Discovery in Kubernetes.

Vorbereitung

Führen Sie die folgenden Schritte durch, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

Clusterbereichs-DNS aktivieren

Im Clusterbereichs-DNS können nur Knoten, die im GKE-Cluster ausgeführt werden, Dienstnamen auflösen. Dienstnamen stehen zwischen Clustern nicht in Konflikt. Dieses Verhalten ist mit "kube-dns" in GKE-Clustern identisch. Das bedeutet, dass Sie Cluster ohne Ausfallzeit oder Änderungen an Ihren Anwendungen von kube-dns zum Cloud DNS-Cluster migrieren können.

Das folgende Diagramm zeigt, wie Cloud DNS eine private DNS-Zone für einen GKE-Cluster erstellt. Nur Prozesse und Pods, die auf den Knoten im Cluster ausgeführt werden, können die DNS-Einträge des Clusters auflösen, da sich nur die Knoten im DNS-Bereich befinden.

Pods auf verschiedenen Knoten, die Dienste im GKE-Cluster auflösen.
Diagramm: Clusterbereich-DNS

DNS des Clusterbereichs in einem neuen Cluster aktivieren

GKE Autopilot-Cluster

Neue Autopilot-Cluster in den Versionen 1.25.9-gke.400, 1.26.4-gke.500 oder höher werden standardmäßig auf den Cloud DNS-Clusterbereich festgelegt.

GKE-Standardcluster

Sie können einen GKE-Standardcluster mit aktiviertem Cloud DNS-Clusterbereich über die gcloud CLI oder die Google Cloud Console erstellen:

gcloud

Erstellen Sie mit dem --cluster-dns-Flag einen Cluster:

gcloud container clusters create CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=cluster \
    --location=COMPUTE_LOCATION

Ersetzen Sie dabei Folgendes:

Das Flag --cluster-dns-scope=cluster ist im Befehl optional, da cluster der Standardwert ist.

Console

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

    Zur Seite „Google Kubernetes Engine“

  2. Klicken Sie auf Erstellen.

  3. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.

  4. Klicken Sie im Abschnitt DNS-Anbieter auf Cloud DNS.

  5. Wählen Sie Clusterbereich aus.

  6. Konfigurieren Sie den Cluster nach Bedarf.

  7. Klicken Sie auf Erstellen.

Clusterbereich-DNS in einem vorhandenen Cluster aktivieren

GKE Autopilot-Cluster

Sie können vorhandene GKE Autopilot-Cluster nicht von kube-dns zum Cloud DNS-Clusterbereich migrieren. Erstellen Sie die Autopilot-Cluster in Version 1.25.9-gke.400, 1.26.4-gke.500 oder höher neu, um den Cloud DNS-Clusterbereich zu aktivieren.

GKE-Standardcluster

Sie können einen bestehenden GKE-Standardcluster von kube-dns nach Cloud DNS-Clusterbereich migrieren. Verwenden Sie dazu die gcloud CLI oder die Google Cloud Console in einem GKE Standard-Cluster.

Wenn Sie einen vorhandenen Cluster migrieren, verwenden die Knoten im Cluster Cloud DNS erst dann als DNS-Anbieter, wenn Sie die Knoten neu erstellen.

Nachdem Sie Cloud DNS für einen Cluster aktiviert haben, gelten die Einstellungen nur, wenn Sie vorhandene Knotenpools aktualisieren oder dem Cluster neue Knotenpools hinzufügen. Beim Aktualisieren eines Knotenpools werden die Knoten neu erstellt.

Sie können auch Cluster mit ausgeführten Anwendungen migrieren, ohne die Clusterkommunikation zu unterbrechen. Aktivieren Sie dazu Cloud DNS als DNS-Anbieter in jedem Knotenpool separat. Eine Teilmenge der Knoten ist jederzeit betriebsbereit, da einige Knotenpools kube-dns und einige Knotenpools Cloud DNS verwenden.

In den folgenden Schritten aktivieren Sie Cloud DNS für einen Cluster und führen dann ein Upgrade Ihrer Knotenpools aus. Durch das Upgrade der Knotenpools werden die Knoten neu erstellt. Die Knoten verwenden dann Cloud DNS für die DNS-Auflösung anstelle von kube-dns.

gcloud

  1. Aktualisieren Sie den vorhandenen Cluster:

    gcloud container clusters update CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=cluster \
    --location=COMPUTE_LOCATION

    Ersetzen Sie dabei Folgendes:

    Die Antwort ähnelt dem folgenden Beispiel:

    All the node-pools in the cluster need to be re-created by the user to start using Cloud DNS for DNS lookups. It is highly recommended to complete this step
shortly after enabling Cloud DNS.
Do you want to continue (Y/n)?

    Nach der Bestätigung wird der Cloud DNS-Controller auf der GKE-Steuerungsebene ausgeführt. Ihre Pods verwenden jedoch Cloud DNS nicht für die DNS-Auflösung, bis Sie Ihren Knotenpool aktualisiert oder neue Knotenpools zum Cluster hinzugefügt haben.

  2. Aktualisieren Sie die Knotenpools im Cluster für die Verwendung von Cloud DNS:

    gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=POOL_NAME \
    --location=COMPUTE_LOCATION

    Ersetzen Sie dabei Folgendes:

    • CLUSTER_NAME ist der Name des Clusters.
    • POOL_NAME ist der Name des zu aktualisierenden Knotenpools.

    Wenn die Knotenpools und Steuerungsebene dieselbe Version ausführen, führen Sie zuerst ein Upgrade der Steuerungsebene aus, wie unter Manuelles Upgrade der Steuerungsebene beschrieben. Anschließend führen Sie das Knotenpool-Upgrade aus.

    Prüfen Sie die Antwort und wiederholen Sie diesen Befehl für jeden Knotenpool im Cluster. Wenn Ihr Cluster nur einen einzigen Knotenpool hat, lassen Sie das Flag --node-pool weg.

Console

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

    Zur Seite "Google Kubernetes Engine"

  2. Click the name of the cluster you want to modify.

  3. Klicken Sie unter Netzwerk im Feld DNS-Anbieter auf DNS-Anbieter bearbeiten.

  4. Klicken Sie auf Cloud DNS.

  5. Klicken Sie auf Clusterbereich.

  6. Klicken Sie auf Änderungen speichern.

Additiven VPC-Bereich für Cloud DNS aktivieren

In diesem Abschnitt werden Schritte zum Aktivieren oder Deaktivieren des additiven Cloud DNS-VPC-Bereichs als Add-on für den Cloud DNS-Clusterbereich beschrieben.

Additiven VPC-Bereich von Cloud DNS in einem neuen Cluster aktivieren

Sie können das VPC-Bereichs-DNS in einem neuen GKE-Cluster über die gcloud CLI oder die Google Cloud Console aktivieren.

Für Autopilot

gcloud container clusters create-auto CLUSTER_NAME \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

Ersetzen Sie dabei Folgendes:

  • CLUSTER_NAME ist der Name des Clusters.
  • UNIQUE_CLUSTER_DOMAIN: der Name einer Domain. Sie müssen dafür sorgen, dass dieser Name in der VPC nur einmal vorkommt, da GKE diesen Wert nicht prüft. Sie können diesen Wert nicht mehr ändern, nachdem er festgelegt wurde. Sie dürfen keine Domain verwenden, die auf ".local" endet. Andernfalls können DNS-Auflösungsfehler auftreten.

Für Standard

gcloud container clusters create CLUSTER_NAME \
    --cluster-dns-scope=cluster \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

Ersetzen Sie dabei Folgendes:

  • CLUSTER_NAME ist der Name des Clusters.
  • UNIQUE_CLUSTER_DOMAIN: der Name einer Domain. Sie müssen dafür sorgen, dass dieser Name in der VPC nur einmal vorkommt, da GKE diesen Wert nicht prüft. Sie können diesen Wert nicht mehr ändern, nachdem er festgelegt wurde. Sie dürfen keine Domain verwenden, die auf ".local" endet. Andernfalls können DNS-Auflösungsfehler auftreten.

Additiven VPC-Bereich für Cloud DNS in einem vorhandenen Cluster aktivieren

Um den additiven Cloud DNS-VPC-Bereich in einem vorhandenen Cluster zu aktivieren, aktivieren Sie zuerst Cloud DNS für einen Cluster und aktualisieren dann Ihre Knotenpools. Durch das Upgrade der Knotenpools werden die Knoten neu erstellt. Die Knoten verwenden dann Cloud DNS für die DNS-Auflösung anstelle von kube-dns.

Additiven VPC-Bereich für Cloud DNS in einem vorhandenen Cluster aktivieren:

gcloud container clusters update CLUSTER_NAME \
    --enable-additive-vpc-scope \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

Ersetzen Sie dabei Folgendes:

  • CLUSTER_NAME ist der Name des Clusters.
  • UNIQUE_CLUSTER_DOMAIN: der Name einer Domain. Sie müssen dafür sorgen, dass dieser Name in der VPC nur einmal vorkommt, da GKE diesen Wert nicht prüft. Sie können diesen Wert nicht mehr ändern, nachdem er festgelegt wurde. Sie dürfen keine Domain verwenden, die auf ".local" endet. Andernfalls können DNS-Auflösungsfehler auftreten.

VPC-Bereich-DNS aktivieren

Im VPC-Bereich-DNS können die DNS-Namen eines Clusters in der gesamten VPC aufgelöst werden. Jeder Client in der VPC kann Cluster-DNS-Einträge auflösen.

Das VPC-Bereich-DNS ermöglicht die folgenden Anwendungsfälle:

  • Monitorlose Diensterkennung für Nicht-GKE-Clients in derselben VPC.
  • Auflösung des GKE-Dienstes von lokalen oder Drittanbieter-Cloud-Clients. Weitere Informationen finden Sie unter Richtlinie für eingehende Server.
  • Dienstauflösung, bei der ein Client entscheiden kann, mit welchem Cluster er über die DNS-Domain des benutzerdefinierten Clusters kommunizieren möchte.

Im folgenden Diagramm verwenden zwei GKE-Cluster das DNS des VPC-Bereichs in derselben VPC. Beide Cluster haben anstelle der Standarddomain .cluster.local die benutzerdefinierte DNS-Domain .cluster1 und .cluster2. Eine VM kommuniziert mit dem monitorlosen Back-End-Dienst, indem backend.default.svc.cluster1 aufgelöst wird. Cloud DNS löst den monitorlosen Dienst in die einzelnen Pod-IP-Adressen im Dienst auf und die VM kommuniziert direkt mit den Pod-IP-Adressen.

Clients für monitorlose Dienste von außerhalb des GKE-Clusters auflösen.
Diagramm: VPC-Bereich-DNS

Diese Art der Auflösung können Sie auch von anderen Netzwerken ausführen, wenn eine Verbindung zur VPC über Cloud Interconnect oder Cloud VPN hergestellt wird. Mit DNS-Serverrichtlinien können Clients aus Netzwerken, die mit der VPC verbunden sind, Namen in Cloud DNS auflösen. Dies umfasst auch GKE-Dienste, wenn der Cluster VPC-Bereichs-DNS verwendet.

DNS-Bereichs-DNS in einem vorhandenen Cluster aktivieren

Die Migration wird nur in GKE Standard und nicht in GKE Autopilot unterstützt.

GKE Autopilot-Cluster

Sie können GKE Autopilot-Cluster nicht von kube-dns zum Cloud DNS-VPC-Bereich migrieren.

GKE-Standardcluster

Sie können einen vorhandenen GKE-Cluster von kube-dns zum Cloud DNS-VPC-Bereich mithilfe der gcloud CLI oder der Google Cloud Console migrieren.

Nachdem Sie Cloud DNS für einen Cluster aktiviert haben, gelten die Einstellungen nur, wenn Sie vorhandene Knotenpools aktualisieren oder dem Cluster neue Knotenpools hinzufügen. Wenn Sie einen Knotenpool upgraden, werden die Knoten neu erstellt.

In den folgenden Schritten aktivieren Sie Cloud DNS für einen Cluster und führen dann ein Upgrade Ihrer Knotenpools aus. Durch das Upgrade der Knotenpools werden die Knoten neu erstellt. Die Knoten verwenden dann Cloud DNS für die DNS-Auflösung anstelle von kube-dns.

gcloud

  1. Aktualisieren Sie den vorhandenen Cluster:

    gcloud container clusters update CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=vpc \
    --cluster-dns-domain=CUSTOM_DOMAIN \
    --location=COMPUTE_LOCATION

    Ersetzen Sie dabei Folgendes:

    • CLUSTER_NAME ist der Name des Clusters.
    • COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.
    • CUSTOM_DOMAIN: der Name einer Domain. Sie müssen dafür sorgen, dass dieser Name in der VPC nur einmal vorkommt, da GKE diesen Wert nicht prüft. Sie können diesen Wert nicht mehr ändern, nachdem er festgelegt wurde. Sie dürfen keine Domain verwenden, die auf ".local" endet. Andernfalls können DNS-Auflösungsfehler auftreten.

    Die Antwort ähnelt dem folgenden Beispiel:

    All the node-pools in the cluster need to be re-created by the user to start using Cloud DNS for DNS lookups. It is highly recommended to complete this step
shortly after enabling Cloud DNS.
Do you want to continue (Y/n)?

    Nach der Bestätigung wird der Cloud DNS-Controller auf der GKE-Steuerungsebene ausgeführt. Ihre Pods verwenden jedoch Cloud DNS nicht für die DNS-Auflösung, bis Sie Ihren Knotenpool aktualisiert oder neue Knotenpools zum Cluster hinzugefügt haben.

  2. Aktualisieren Sie die Knotenpools im Cluster für die Verwendung von Cloud DNS:

    gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=POOL_NAME

    Ersetzen Sie dabei Folgendes:

    • CLUSTER_NAME ist der Name des Clusters.
    • POOL_NAME ist der Name des zu aktualisierenden Knotenpools.

    Wenn die Knotenpools und Steuerungsebene dieselbe Version ausführen, führen Sie zuerst ein Upgrade der Steuerungsebene aus, wie unter Manuelles Upgrade der Steuerungsebene beschrieben. Anschließend führen Sie das Knotenpool-Upgrade aus.

    Prüfen Sie die Antwort und wiederholen Sie diesen Befehl für jeden Knotenpool im Cluster. Wenn Ihr Cluster nur einen einzigen Knotenpool hat, lassen Sie das Flag --node-pool weg.

Console

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

    Zur Seite "Google Kubernetes Engine"

  2. Click the name of the cluster you want to modify.

  3. Klicken Sie unter Netzwerk im Feld DNS-Anbieter auf DNS-Anbieter bearbeiten.

  4. Klicken Sie auf Cloud DNS.

  5. Klicken Sie auf VPC-Bereich.

  6. Klicken Sie auf Änderungen speichern.

Cloud DNS prüfen

Prüfen Sie, ob Cloud DNS für GKE für Ihren Cluster ordnungsgemäß funktioniert:

  1. Prüfen Sie, ob die Knoten Cloud DNS verwenden. Stellen Sie dazu eine Verbindung zu einem Pod auf einem Knoten her und führen Sie den Befehl cat /etc/resolv.conf aus:

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

    Ersetzen Sie POD_NAME durch den Namen des Pods.

    Je nach Clustermodus sieht die Ausgabe in etwa so aus:

    GKE Autopilot-Cluster

    nameserver 169.254.20.10

    Da NodeLocal DNSCache in GKE Autopilot standardmäßig aktiviert ist, verwendet der Pod NodeLocal DNSCache.

    Nur wenn der lokale Cache keinen Eintrag für den zu suchenden Namen hat, leitet NodeLocal DNSCache die Anfrage an Cloud DNS weiter.

    GKE-Standardcluster

    nameserver 169.254.169.254

    Der Pod verwendet 169.254.169.254 als nameserver. Dies ist die IP-Adresse des Metadatenservers, auf dem die Cloud DNS-Datenebene Anfragen an Port 53 überwacht. Die Knoten verwenden die kube-dns-Dienstadresse nicht mehr für die DNS-Auflösung und die gesamte DNS-Auflösung erfolgt auf dem lokalen Knoten.

    Wenn die Ausgabe eine IP-Adresse wie 10.x.y.10 ist, verwendet der Pod kube-dns. Im Abschnitt Fehlerbehebung erfahren Sie, warum Ihr Pod weiterhin kube-dns verwendet.

    Ist die Ausgabe 169.254.20.10, so bedeutet dies, dass Sie NodeLocal DNSCache in Ihrem Cluster aktiviert haben. In diesem Fall verwendet der Pod NodeLocal DNSCache.

  2. Stellen Sie eine Beispielanwendung in Ihrem Cluster bereit:

    kubectl run dns-test --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0

  3. Geben Sie die Beispielanwendung mit einem Dienst frei:

    kubectl expose pod dns-test --name dns-test-svc --port 8080

  4. Prüfen Sie, ob der Dienst erfolgreich bereitgestellt wurde:

    kubectl get svc dns-test-svc

    Die Ausgabe sieht in etwa so aus:

    NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
dns-test-svc   ClusterIP   10.47.255.11    <none>        8080/TCP   6m10s

    Der Wert von CLUSTER-IP ist die virtuelle IP-Adresse für Ihren Cluster. In diesem Beispiel lautet die virtuelle IP-Adresse 10.47.255.11.

  5. Prüfen Sie, ob der Dienstname als Eintrag in der privaten DNS-Zone für Ihren Cluster erstellt wurde:

    gcloud dns record-sets list \
    --zone=PRIVATE_DNS_ZONE \
    --name=dns-test-svc.default.svc.cluster.local.

    Ersetzen Sie PRIVATE_DNS_ZONE durch den Namen der verwalteten DNS-Zone.

    Die Ausgabe sieht in etwa so aus:

    NAME: dns-test-svc.default.svc.cluster.local.
TYPE: A
TTL: 30
DATA: 10.47.255.11

Cloud DNS für GKE deaktivieren

GKE Autopilot-Cluster

Sie können Cloud DNS nicht in einem GKE Autopilot-Cluster deaktivieren, der standardmäßig mit Cloud DNS erstellt wurde. Weitere Informationen zu GKE Autopilot-Clustern, die Cloud DNS standardmäßig verwenden, finden Sie unter Anforderungen.

GKE-Standardcluster

Sie können den Cloud DNS-Clusterbereich über die gcloud CLI oder die Google Cloud Console in einem GKE Standard-Cluster deaktivieren.

gcloud

Aktualisieren Sie den Cluster für die Verwendung von kube-dns:

gcloud container clusters update CLUSTER_NAME \
    --cluster-dns=default

Console

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

    Zur Seite "Google Kubernetes Engine"

  2. Click the name of the cluster you want to modify.

  3. Klicken Sie unter Netzwerk im Feld DNS-Anbieter auf DNS-Anbieter bearbeiten.

  4. Klicken Sie auf Kube-dns.

  5. Klicken Sie auf Änderungen speichern.

Additiven VPC-Bereich von Cloud DNS deaktivieren

Wenn Sie den additiven Cloud DNS-VPC-Bereich für den Cluster deaktivieren, werden nur die DNS-Einträge in den privaten Zonen gelöscht, die mit dem VPC-Netzwerk verbunden sind. Die Einträge in den privaten DNS-Zonen für den GKE-Cluster bleiben bestehen und werden von Cloud DNS für GKE verwaltet, bis der monitorlose Dienst aus dem Cluster gelöscht wird.

Führen Sie den folgenden Befehl aus, um den additiven VPC-Bereich von Cloud DNS zu deaktivieren:

gcloud container clusters update CLUSTER_NAME \
    --disable-additive-vpc-scope

Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters.

Dadurch bleibt der Cluster mit Cloud DNS-Clusterbereich aktiviert, um die DNS-Auflösung innerhalb des Clusters bereitzustellen.

Bereinigen

Wenn Sie mit den Übungen auf dieser Seite fertig sind, entfernen Sie mit den folgenden Schritten die Ressourcen, damit Sie unerwünschte Kosten für Ihr Konto vermeiden:

  1. Löschen Sie den Dienst:

    kubectl delete service dns-test-svc

  2. Löschen Sie den Pod:

    kubectl delete Pod dns-test

  3. Sie können auch den Cluster löschen.

Cloud DNS mit freigegebener VPC verwenden

Cloud DNS für GKE unterstützt eine freigegebene VPC sowohl für VPC- als auch für den Clusterbereich.

Der GKE-Controller erstellt eine verwaltete private Zone im selben Projekt wie der GKE-Cluster.

Das GKE-Dienstkonto für den GKE-Cluster erfordert keine Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) für DNS außerhalb seines eigenen Projekts, da sich die verwaltete Zone und der GKE-Cluster im selben Projekt befinden.

Mehr als ein Cluster pro Dienstprojekt

Ab den GKE-Versionen 1.22.3-gke.700, 1.21.6-gke.1500 können Sie Cluster in mehreren Dienstprojekten erstellen, die auf eine VPC im selben Hostprojekt verweisen.

Wenn Sie bereits Cluster mit freigegebener VPC und einem Cloud DNS-VPC-Bereich haben, müssen Sie diese manuell mit den folgenden Schritten migrieren:

  • Aktualisieren Sie Ihre vorhandenen Cluster, für die die freigegebene VPC aktiviert ist, auf GKE-Version 1.22.3-gke.700 oder höher bzw. 1.21.6-gke.1500 oder höher.
  • Migrieren Sie die Antwortrichtlinie vom Dienstprojekt zum Hostprojekt. Sie müssen diese Migration nur einmal pro freigegebenem VPC-Netzwerk durchführen.

Sie können Ihre Antwortrichtlinie mit der Google Cloud Console migrieren.

Führen Sie in Ihrem Dienstprojekt die folgenden Schritte aus:

  1. Rufen Sie die Seiten Cloud DNS-Zonen auf.

    Cloud DNS-Zonen aufrufen

  2. Klicken Sie auf den Tab Antwortrichtlinienzonen.

  3. Klicken Sie auf die Antwortrichtlinie für Ihr VPC-Netzwerk. Sie können die Antwortrichtlinie anhand der Beschreibung identifizieren, die Folgendem ähnelt: „Antwortrichtlinie für GKE-Cluster im Netzwerk NETZWERKNAME“.

  4. Klicken Sie auf den Tab Verwendet von.

  5. Klicken Sie neben dem Namen des Hostprojekts auf , um die Netzwerkbindung zu entfernen.

  6. Klicken Sie auf den Tab Antwortrichtlinienregeln.

  7. Wählen Sie alle Einträge in der Tabelle aus.

  8. Klicken Sie auf Antwortrichtlinienregeln entfernen.

  9. Klicken Sie auf Antwortrichtlinie löschen.

Nachdem Sie die Antwortrichtlinie gelöscht haben, erstellt der DNS-Controller die Antwortrichtlinie automatisch im Hostprojekt. Cluster aus anderen Dienstprojekten teilen diese Antwortrichtlinie.

Benutzerdefinierte Stub-Domains und vorgelagerte Nameserver unterstützen

Cloud DNS für GKE unterstützt benutzerdefinierte Stub-Domains und vorgelagerte Nameserver, die mit kube-dns-ConfigMap konfiguriert wurden. Diese Unterstützung ist nur für GKE-Standardcluster verfügbar.

Cloud DNS übersetzt die Werte stubDomains und upstreamNameservers in Cloud DNS-Weiterleitungszonen.

Bekannte Probleme

Terraform plant, den Autopilot-Cluster aufgrund der dns_config-Änderung neu zu erstellen

Wenn Sie terraform-provider-google oder terraform-provider-google-beta verwenden, kann ein Problem auftreten, bei dem Terraform versucht, einen Autopilot-Cluster neu zu erstellen. Dieser Fehler tritt auf, weil neu erstellte Autopilot-Cluster, auf denen Version 1.25.9-gke.400, 1.26.4-gke.500, 1.27.1-gke.400 oder höher ausgeführt wird, Cloud DNS anstelle von kube-dns als DNS-Anbieter verwenden.

Dieses Problem wurde in Version 4.80.0 des Terraform-Anbieters von Google Cloud behoben.

Wenn Sie die Version von terraform-provider-google oder terraform-provider-google-beta nicht aktualisieren können, können Sie der Ressource lifecycle.ignore_changes hinzufügen, damit google_container_cluster Änderungen an dns_config ignoriert:

  lifecycle {
    ignore_changes = [
      dns_config,
    ]
  }

Fehlerbehebung

Informationen zum Aktivieren des DNS-Loggings finden Sie unter Logging für private verwaltete Zonen aktivieren/deaktivieren.

Weitere Informationen zur Fehlerbehebung bei DNS-Problemen finden Sie unter DNS-Fehlerbehebung in GKE.

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.

Pods verwenden kube-dns, auch wenn Cloud DNS in einem vorhandenen Cluster aktiviert ist

Achten Sie darauf, dass Sie Ihre Knotenpools aktualisiert oder neu erstellt haben, nachdem Sie Cloud DNS im Cluster aktiviert haben. Bis dieser Schritt abgeschlossen ist, verwenden Pods weiterhin kube-dns.

Pod kann keine DNS-Lookups auflösen

  1. Prüfen Sie, ob der Pod Cloud DNS verwendet. Stellen Sie dazu eine Verbindung zu einem Pod her und führen Sie den Befehl cat /etc/resolv.conf aus:

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

    Ersetzen Sie POD_NAME durch den Namen des Pods.

    Die Ausgabe sieht in etwa so aus:

    nameserver 169.254.169.254

    Ist die Ausgabe eine IP-Adresse ähnlich wie 10.x.y.10 oder34.118.224.10 (nur in GKE Autopilot-Clustern mit Version 1.27 und höher), verwendet der Pod Kube-dns. Wenn die Ausgabe 169.254.20.10 ist, verwendet der Pod den NodeLocal DNSCache.

  2. Prüfen Sie, ob die verwaltete Zone vorhanden ist und den erforderlichen DNS-Eintrag enthält:

    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 "cluster1" with cluster suffix "cluster.local" in project "project-243723"
   dnsName: cluster.local.
   id: 5887499284756055830
   kind: dns#managedZone
   name: gke-cluster1-aa94c1f9-dns
   nameServers: ['ns-gcp-private.googledomains.com.']
   privateVisibilityConfig: {'kind': 'dns#managedZonePrivateVisibilityConfig'}
   visibility: private

    Der Wert von name in der Antwort zeigt, dass Google Cloud eine private Zone mit dem Namen gke-cluster1-aa94c1f9-dns erstellt hat.

  3. Überprüfen Sie, ob Cloud DNS Einträge für den Cluster enthält:

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

    Ersetzen Sie dabei Folgendes:

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

    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:

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

  4. Aktivieren Sie Cloud DNS-Logging, um Abfragen zu verfolgen. Jeder Logeintrag enthält Informationen zur Abfrage, einschließlich der DNS-Latenz.

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.

Vorhandener Cluster kann nicht aktualisiert oder Cluster mit aktiviertem additivem Cloud DNS-VPC-Bereich kann nicht 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.

Pod kann keine DNS-Lookups auflösen

  1. Prüfen Sie, ob der Pod Cloud DNS verwendet. Stellen Sie dazu eine Verbindung zu einem Pod her und führen Sie den Befehl cat /etc/resolv.conf aus:

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

    Ersetzen Sie POD_NAME durch den Namen des Pods.

    Die Ausgabe sieht in etwa so aus:

    nameserver 169.254.169.254

    Ist die Ausgabe eine IP-Adresse ähnlich wie 10.x.y.10 oder34.118.224.10 (nur in GKE Autopilot-Clustern mit Version 1.27 und höher), verwendet der Pod Kube-dns. Wenn die Ausgabe 169.254.20.10 ist, verwendet der Pod den NodeLocal DNSCache.

  2. Prüfen Sie, ob die verwaltete Zone vorhanden ist und den erforderlichen DNS-Eintrag enthält:

    gcloud dns managed-zones list --format list

    Die Ausgabe sieht in etwa so aus:

    gke-cluster-1-cbdc0678-dns  cluster.local.   Private zone for GKE cluster "cluster-1" with cluster suffix "cluster.local." in project "PROJECT_NAME" with scope "CLUSTER_SCOPE"  private
gke-cluster-1-cbdc-dns-vpc  CLUSTER_DOMAIN.  Private zone for GKE cluster "cluster-1" with cluster suffix "CLUSTER_DOMAIN." in project "PROJECT_NAME" with scope "VPC_SCOPE"     private

    Der Wert von name in der Antwort zeigt, dass Google Cloud eine private Zone mit dem Namen gke-cluster1-aa94c1f9-dns erstellt hat.

  3. Überprüfen Sie, ob Cloud DNS Einträge für Ihren Cluster in beiden ManagedZones enthält:

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

    Ersetzen Sie dabei Folgendes:

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

    Die Ausgabe sieht in etwa so aus:

    my-service.default.svc.cluster.local.                A     30     10.47.255.11

    Der Wert von name in der Antwort zeigt, dass Google Cloud eine private Zone mit dem Namen gke-cluster1-aa94c1f9-dns erstellt hat.

  4. Prüfen Sie bei umgekehrten DNS-Lookups, ob Cloud DNS Einträge für Ihren Cluster in ResponsePolicies enthält:

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

    Die Ausgabe sieht in etwa so aus:

      gke-NETWORK_HASH-rp        Response Policy for GKE clusters on network "VPC_NAME".
  gke-cluster-1-52c8f518-rp  Response Policy for GKE cluster "cluster-1" with cluster suffix "cluster.local." in project "khamed-gke-dev" with scope "CLUSTER_SCOPE".

    Der Wert von name in der Antwort zeigt, dass Google Cloud eine private Zone mit dem Namen gke-cluster1-aa94c1f9-rp erstellt hat.

  5. Prüfen Sie bei umgekehrten DNS-Lookups, ob Cloud DNS Einträge für Ihren Cluster in ResponsePolicies enthält:

      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.

    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.

Nächste Schritte