Diese Seite wurde von der Cloud Translation API übersetzt.

Cloud DNS für GKE verwenden

Autopilot Standard

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-Adressen, 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.
Einbindung in Google Cloud-Beobachtbarkeit für DNS-Monitoring und -Logging. Weitere Informationen finden Sie unter Logging für private verwaltete Zonen aktivieren/deaktivieren.

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 VPC-bezogene 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:

GKE-Version 1.28.3-gke.1430000 oder höher.
Google Cloud CLI-Version 503.0.0 oder höher.
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.
Sie können den additiven VPC-Bereich für GKE Autopilot-Cluster nur beim Erstellen des Clusters aktivieren. Das Aktivieren oder Deaktivieren des additiven VPC-Bereichs in vorhandenen GKE Autopilot-Clustern wird nicht unterstützt.
Das Erstellen von Clustern mit additivem VPC-Bereich in Dienstprojekten von freigegebenen VPC-Netzwerken wird nicht unterstützt.
Cloud DNS für GKE ist nicht für Assured Workloads mit einer IL4-Compliance-Richtlinie verfügbar. In solchen regulierten Umgebungen wird kube-dns erzwungen.
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.
Nachdem Sie Cloud DNS for GKE in einem Cluster aktiviert haben, wird kube-dns weiterhin im Cluster ausgeführt. Sie können kube-dns deaktivieren, indem Sie das Deployment von kube-dns und das Autoscaling auf null skalieren.
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.
Es gelten die Einschränkungen für CloudDNS-Ressourcen. Insbesondere kann jeweils nur eine Antwortrichtlinienzone an ein VPC-Netzwerk gebunden sein. Bei VPC- und additiven VPC-Bereichen schlägt die Clustererstellung fehl, wenn bereits eine Antwortrichtlinienzone vorhanden ist, die nicht der Namenskonvention des VPC-Netzwerk des Clusters entspricht.
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.
Dienst- und Portnamen sind auf 62 Zeichen begrenzt, obwohl DNS-Labels maximal 63 Zeichen lang sein dürfen. Das liegt daran, dass GKE DNS-Einträgen ein Unterstrichpräfix hinzufügt.

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.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Aktivieren Sie die Google Kubernetes Engine API.

Google Kubernetes Engine API aktivieren

Wenn Sie die Google Cloud CLI für diesen Task 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 dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

Aktivieren Sie die Cloud DNS API in Ihrem Projekt:

Cloud DNS API aktivieren

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:

CLUSTER_NAME ist der Name des Clusters.
COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.

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

Console

Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster erstellen auf.
Zur Seite „Kubernetes-Cluster erstellen“
Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.
Klicken Sie im Abschnitt DNS-Anbieter auf Cloud DNS.
Wählen Sie Clusterbereich aus.
Konfigurieren Sie den Cluster nach Bedarf.
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 Standard-Cluster von kube-dns nach Cloud DNS-Clusterbereich migrieren. Verwenden Sie dazu die gcloud CLI oder dieGoogle 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

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:
- CLUSTER_NAME ist der Name des Clusters.
- COMPUTE_LOCATION: der Compute Engine-Standort für Ihren Cluster.
Das Flag --cluster-dns-scope=cluster ist im Befehl optional, da cluster der Standardwert ist.

Das Ergebnis sieht etwa so aus:
```
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.
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
```
Hinweis: Verwenden Sie für Versionen der Google Cloud CLI vor 411.0.0 gcloud beta container statt gcloud container.

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.

Hinweis: Ein Upgrade auf dieselbe Version, in der der Knotenpool derzeit ausgeführt wird, hat keine Auswirkungen auf den Pod. Für solche Knotenpools verwenden die auf diesen Knoten ausgeführten Pods weiterhin kube-dns. Wenn Sie das kube-dns-Deployment und das Autoscaling auf null herunterskalieren, werden auf diesen Pods DNS-Fehler verursacht. Damit die Pods Cloud DNS verwenden können, müssen Sie den Knotenpool auf eine neue Version aktualisieren. Alternativ können Sie einen neuen Knotenpool in derselben Version erstellen.

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

Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

Zur Seite "Google Kubernetes Engine"
Click the name of the cluster you want to modify.
Klicken Sie unter Netzwerk im Feld DNS-Anbieter auf DNS-Anbieter bearbeiten.
Klicken Sie auf Cloud DNS.
Klicken Sie auf Clusterbereich.
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 -Konsole 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=clouddns \
    --cluster-dns-scope=cluster \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

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

Ersetzen Sie 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 \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN \
    --location=COMPUTE_LOCATION

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.
COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.

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.

gcloud

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

Hinweis: Ein Upgrade auf dieselbe Version, in der der Knotenpool derzeit ausgeführt wird, hat keine Auswirkungen auf den Pod. Für solche Knotenpools verwenden die auf diesen Knoten ausgeführten Pods weiterhin kube-dns. Wenn Sie das kube-dns-Deployment und das Autoscaling auf null skalieren, werden auf diesen Pods DNS-Fehler verursacht. Damit die Pods Cloud DNS verwenden können, müssen Sie den Knotenpool auf eine neue Version aktualisieren. Alternativ können Sie einen neuen Knotenpool in derselben Version erstellen.

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

Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

Zur Seite "Google Kubernetes Engine"
Click the name of the cluster you want to modify.
Klicken Sie unter Netzwerk im Feld DNS-Anbieter auf DNS-Anbieter bearbeiten.
Klicken Sie auf Cloud DNS.
Klicken Sie auf VPC-Bereich.
Klicken Sie auf Änderungen speichern.

Cloud DNS prüfen

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

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.

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

Geben Sie die Beispielanwendung mit einem Dienst frei:

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

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.

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

Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

Zur Seite "Google Kubernetes Engine"
Click the name of the cluster you want to modify.
Klicken Sie unter Netzwerk im Feld DNS-Anbieter auf DNS-Anbieter bearbeiten.
Klicken Sie auf Kube-dns.
Klicken Sie auf Änderungen speichern.

Nachdem Sie Cloud DNS für Standardcluster deaktiviert haben, müssen Sie alle Knotenpools aktualisieren, die mit Ihren Clustern verknüpft sind. Alternativ können Sie einen neuen Knotenpool erstellen und Ihre Arbeitslast dort planen. Wenn Sie Ihre Knotenpools nicht aktualisieren, verweist der DNS-Namespace weiterhin auf Cloud DNS und nicht auf kube-dns.

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:

Löschen Sie den Dienst:
```
kubectl delete service dns-test-svc
```
Löschen Sie den Pod:
```
kubectl delete Pod dns-test
```
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 -Konsole migrieren.

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

Rufen Sie die Seiten Cloud DNS-Zonen auf.

Cloud DNS-Zonen aufrufen
Klicken Sie auf den Tab Antwortrichtlinienzonen.
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“.
Klicken Sie auf den Tab Verwendet von.
Klicken Sie neben dem Namen des Hostprojekts auf , um die Netzwerkbindung zu entfernen.
Klicken Sie auf den Tab Antwortrichtlinienregeln.
Wählen Sie alle Einträge in der Tabelle aus.
Klicken Sie auf Antwortrichtlinienregeln entfernen.
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.

Spezifikationserweiterungen

Zur Verbesserung der Diensterkennung und Kompatibilität mit verschiedenen Clients und Systemen gibt es Ergänzungen zur allgemeinen Kubernetes-DNS-Spezifikation.

Benannte Ports

In diesem Abschnitt wird erläutert, wie sich benannte Ports auf die DNS-Einträge auswirken, die von Cloud DNS für Ihren Kubernetes-Cluster erstellt werden. In Kubernetes ist eine Mindestanzahl erforderlicher DNS-Einträge definiert. Cloud DNS kann zusätzliche Einträge für den eigenen Betrieb und zur Unterstützung verschiedener Kubernetes-Funktionen erstellen. In den folgenden Tabellen sehen Sie die Mindestanzahl der erwarteten Datensatzgruppen, wobei „E“ die Anzahl der Endpunkte und „P“ die Anzahl der Ports darstellt. In Cloud DNS werden möglicherweise zusätzliche Einträge erstellt.

IP-Stacktyp	Diensttyp	Datensätze
Einzelstapel	ClusterIP	$$2+P$$
Einzelstapel	Headless	$$2+P+2E$$
Dual Stack	ClusterIP	$$3+P$$
Dual Stack	Headless	$$3+P+3E$$
Weitere Informationen zu Single-Stack- und Dual-Stack-Diensten finden Sie unter Single-Stack- und Dual-Stack-Dienste.

Zusätzliche DNS-Einträge, die von Cloud DNS erstellt wurden

Cloud DNS kann zusätzliche DNS-Einträge über die Mindestanzahl von Eintragssätzen hinaus erstellen. Diese Einträge dienen verschiedenen Zwecken, darunter: SRV-Einträge: Für die Dienstermittlung erstellt Cloud DNS häufig SRV-Einträge. Diese Einträge enthalten Informationen zum Port und Protokoll des Dienstes. AAAA-Einträge (für Dual-Stack): In Dual-Stack-Konfigurationen (IPv4 und IPv6) erstellt Cloud DNS sowohl A-Einträge (für IPv4) als auch AAAA-Einträge (für IPv6) für jeden Endpunkt. Interne Einträge: Cloud DNS kann interne Einträge für die eigene Verwaltung und Optimierung erstellen. Diese Datensätze sind in der Regel nicht direkt für Nutzer relevant. LoadBalancer-Dienste: Für Dienste vom Typ „LoadBalancer“ erstellt Cloud DNS Einträge, die mit der externen IP-Adresse des Load-Balancers verknüpft sind. Monitorlose Dienste: Monitorlose Dienste haben eine eigene DNS-Konfiguration. Jeder Pod erhält einen eigenen DNS-Eintrag, sodass Clients direkt eine Verbindung zu den Pods herstellen können. Aus diesem Grund wird die Portnummer bei der Berechnung des monitorlosen Dienstdatensatzes nicht multipliziert.

Beispiel: Ein Dienst mit dem Namen my-http-server im Namespace backend. Dieser Dienst macht zwei Ports, 80 und 8080, für ein Deployment mit drei Pods verfügbar. Daher gilt: E = 3 und P = 2.

IP-Stacktyp	Diensttyp	Datensätze
Einzelstapel	ClusterIP	$$2+2$$
Einzelstapel	Headless	$$2+2+2*3$$
Dual Stack	ClusterIP	$$3+2$$
Dual Stack	Headless	$$3+2+3*3$$

Zusätzlich zu diesen Mindesteinträgen kann Cloud DNS SRV-Einträge und im Fall von Dual-Stack AAAA-Einträge erstellen. Wenn my-http-server ein Dienst vom Typ „LoadBalancer“ ist, werden zusätzliche Datensätze für die Load-Balancer-IP-Adresse erstellt. Hinweis: Cloud DNS fügt bei Bedarf zusätzliche DNS-Einträge hinzu. Welche Einträge genau erstellt werden, hängt von Faktoren wie dem Diensttyp und der Konfiguration ab.

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 Cloudbehoben.

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,
    ]
  }

DNS-Auflösung schlägt nach der Migration von kube-dns zu Cloud DNS mit aktiviertem NodeLocal DNSCache fehl

In diesem Abschnitt wird ein bekanntes Problem in GKE-Clustern in Cloud DNS mit NodeLocal DNSCache im Clusterbereich beschrieben.

Nach der Migration von kube-DNS zu Cloud DNS mit aktiviertem NodeLocal DNSCache im Cluster können in Ihrem Cluster zeitweise Auflösungsfehler auftreten.

Wenn Sie kube-dns verwenden und NodeLocal DNSCache im Cluster aktiviert ist, wird NodeLocal DNSCache so konfiguriert, dass er auf beiden Adressen (NodeLocal DNSCache-Adresse und kube-dns-Adresse) lauscht.

Führen Sie den folgenden Befehl aus, um den Status von NodeLocal DNSCache zu prüfen:

kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind

Die Ausgabe sieht etwa so aus:

    bind 169.254.20.10 x.x.x.10
    bind 169.254.20.10 x.x.x.10

Wenn Dataplane V2 im Cluster aktiviert ist, während kube-dns verwendet wird, wird NodeLocal DNSCache in einem isolierten Netzwerk ausgeführt und so konfiguriert, dass es auf allen Pod-IP-Adressen (0.0.0.0) lauscht. Die Ausgabe sieht etwa so aus:

    bind 0.0.0.0
    bind 0.0.0.0

Nachdem Sie den Cluster auf Cloud DNS aktualisiert haben, wird die NodeLocal DNSCache-Konfiguration geändert. Prüfen Sie NodeLocal DNSCache:

kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind

Die Ausgabe sieht etwa so aus:

    bind 169.254.20.10
    bind 169.254.20.10

Im folgenden Workflow werden die Einträge in der Datei „resolv.conf“ während der Migration und der Neuerstellung von Knoten erläutert:

Vor der Migration

Für Pods ist „resolv.conf“ für die kube-dns-IP (d.h. x.x.x.10) konfiguriert.
Node-local-cache-Pods fangen DNS-Anfragen von Pods ab und überwachen Folgendes:
- (DPv1) – beide Adressen (bind 169.254.20.10 x.x.x.10).
- (DPv2) – alle Pod-IP-Adressen (bind 0.0.0.0).
NodeLocal DNSCache fungiert als Cache und die kube-dns-Pods werden nur wenig belastet.

Nach der Migration

Nachdem die Steuerungsebene aktualisiert wurde, um Cloud DNS zu verwenden, ist für die Pods weiterhin „resolv.conf“ für die kube-dns-IP (d.h. x.x.x.10) konfiguriert. Diese Konfiguration bleibt bestehen, da GKE das Neuerstellen von Knoten erfordert, um 169.254.20.10 zu verwenden. Für die Cloud DNS-Einrichtung ist 169.254.20.10 erforderlich.
Node-local-cache-Pods überwachen nur die NodeLocal DNSCache-Adresse (bind 169.254.20.10). Die Anfrage wird nicht an Pods mit lokalem Knotencache gesendet.
Alle Anfragen von Pods werden direkt an kube-dns-Pods gesendet. Bei dieser Konfiguration wird viel Traffic auf den Pods generiert.

Nach dem Neuerstellen von Knoten oder dem Upgrade von Knotenpools

Für Pods ist resolv.conf auf die NodeLocal DNSCache-IP-Adresse (169.254.20.10) konfiguriert.
Node-local-cache-Pods überwachen nur die NodeLocal DNSCache-Adresse (bind 169.254.20.10) und empfangen DNS-Anfragen von Pods über diese IP-Adresse.

Wenn Knotenpools vor dem Neuerstellen des Knotenpools die kube-dns-IP unter „resolv.conf“ verwenden, führt eine Zunahme des DNS-Abfrageverkehrs auch zu einer Zunahme des Traffics für die kube-dns-Pods, was zu zeitweiligen Fehlern bei DNS-Anfragen führt. Um Fehler zu minimieren, müssen Sie diese Migration während der Ausfallzeiten planen.

Fehlerbehebung

Informationen zur Fehlerbehebung bei Cloud DNS finden Sie auf den folgenden Seiten:

Informationen zu Cloud DNS in GKE finden Sie unter Fehlerbehebung bei Cloud DNS in GKE.
Spezifische Informationen zur Fehlerbehebung bei Cloud DNS finden Sie unter Fehlerbehebung bei Cloud DNS.
Allgemeine Informationen zur Diagnose von Kubernetes DNS-Problemen finden Sie unter Debugging bei der DNS-Auflösung.

Nächste Schritte

Deployment von verwaltetem DNS in GKE
Eine Übersicht zur Verwendung von DNS in Kubernetes-Clustern finden Sie unter DNS für Dienste und Pods
Bereiche und Hierarchien in Cloud DNS
Logging für private verwaltete Zonen aktivieren und deaktivieren.

Cloud DNS für GKE verwenden Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Funktionsweise von Cloud DNS für GKE

Architektur

DNS-Bereiche

Cloud DNS-Ressourcen

Verwaltete Zonen und Weiterleitungszonen

Preise

Voraussetzungen

Limits und Einschränkungen

Kontingente

Ressourcenlimits

Hinweise

Clusterbereichs-DNS aktivieren

DNS des Clusterbereichs in einem neuen Cluster aktivieren

gcloud

Console

Clusterbereich-DNS in einem vorhandenen Cluster aktivieren

gcloud

Console

Additiven VPC-Bereich für Cloud DNS aktivieren

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

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

VPC-Bereich-DNS aktivieren

DNS-Bereichs-DNS in einem vorhandenen Cluster aktivieren

gcloud

Console

Cloud DNS prüfen

Cloud DNS für GKE deaktivieren

gcloud

Console

Additiven VPC-Bereich von Cloud DNS deaktivieren

Bereinigen

Cloud DNS mit freigegebener VPC verwenden

Mehr als ein Cluster pro Dienstprojekt

Benutzerdefinierte Stub-Domains und vorgelagerte Nameserver unterstützen

Spezifikationserweiterungen

Benannte Ports

Zusätzliche DNS-Einträge, die von Cloud DNS erstellt wurden

Bekannte Probleme

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

DNS-Auflösung schlägt nach der Migration von kube-dns zu Cloud DNS mit aktiviertem NodeLocal DNSCache fehl

Vor der Migration

Nach der Migration

Nach dem Neuerstellen von Knoten oder dem Upgrade von Knotenpools

Fehlerbehebung

Nächste Schritte

Cloud DNS für GKE verwenden

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