Dieses Dokument soll Ihnen helfen, zu entscheiden, ob Cloud DNS für GKE die richtige DNS-Lösung für Ihren Cluster ist. Sie können Cloud DNS verwenden, um die DNS-Auflösung für Pods und Dienste als Alternative zu Cluster-gehosteten DNS-Anbietern wie kube-dns zu verarbeiten.
Für Autopilot-Cluster ist Cloud DNS bereits der Standard-DNS-Anbieter. Bei Standardclustern können Sie von kube-dns zu Cloud DNS wechseln.
Dieses Dokument richtet sich an GKE-Nutzer, einschließlich Entwickler, Administratoren und Architekten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben in Google Cloudfinden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.
In diesem Dokument wird davon ausgegangen, dass Sie mit den folgenden Konzepten vertraut sind:
Funktionsweise von Cloud DNS für GKE
Wenn Sie Cloud DNS als DNS-Anbieter für GKE verwenden, bietet Cloud DNS Pod- und Dienst-DNS-Auflösung, ohne dass ein 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, die folgenden Vorteile:
- Geringerer Aufwand: Die Verwaltung von im Cluster gehosteten DNS-Servern ist nicht mehr erforderlich. Cloud DNS erfordert keine manuelle Skalierung, Überwachung oder Verwaltung von DNS-Instanzen, da es sich dabei um einen vollständig verwalteten Dienst handelt.
- Hohe Skalierbarkeit und Leistung: Löst Abfragen lokal für jeden GKE-Knoten auf, um eine DNS-Auflösung mit niedriger Latenz und hoher Skalierbarkeit zu ermöglichen. Für eine optimale Leistung, insbesondere in großen Clustern, sollten Sie NodeLocal DNSCache aktivieren. Dadurch wird eine zusätzliche Caching-Ebene auf dem Knoten bereitgestellt.
- Einbindung in Google Cloud Observability: Ermöglicht DNS-Monitoring und -Logging. Weitere Informationen finden Sie unter Logging für private verwaltete Zonen aktivieren und 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:
Im Diagramm wählt das Backend des Dienstes die laufenden Backend-Pods aus. Der clouddns-Controller erstellt einen DNS-Eintrag für das Dienst-Backend.
Das Pod-Frontend sendet eine DNS-Anfrage, um die IP-Adresse des Dienstes mit dem Namen „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.
Cloud DNS löst den Dienstnamen je nach Typ des Kubernetes-Dienstes in unterschiedliche IP-Adressen auf. Bei ClusterIP-Diensten löst Cloud DNS den Dienstnamen in die virtuelle IP-Adresse auf. Bei monitorlosen Diensten wird der Dienstname in die Liste der Endpunkt-IP-Adressen aufgelöst.
Nachdem das Pod-Frontend die IP-Adresse aufgelöst hat, kann der Pod Traffic an das 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.localenden. 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. Dieser Modus ist der Standardmodus.- Additiver VPC-Bereich von 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 oder Cloud Interconnect verbunden sind. Dieser Modus ist ein zusätzlicher Modus, der neben dem Clusterbereich aktiviert wird. Sie können diesen Modus in Ihrem Cluster aktivieren oder deaktivieren, ohne die DNS-Betriebszeit oder die Funktionen des Clusterbereichs zu beeinträchtigen.
- 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 | Nur Cluster, mit monitorlosen Diensten, die im gesamten VPC-Netzwerk aufgelöst werden können | Gesamtes VPC-Netzwerk |
| Auflösung von monitorlosen Diensten | Im Cluster auflösbar | Auflösbar innerhalb des Clusters mit der Domain „cluster.local“ und in der VPC mithilfe des Clustersuffixes | Auflösbar innerhalb des Clusters und in der gesamten VPC mithilfe des Clustersuffixes |
| Eindeutige Domain erforderlich | Nein. Verwendet die Standarddomain „*.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 oder 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
Für Cluster, die Clusterbereich verwenden, um internen DNS-Traffic zu verarbeiten, 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 ..
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 oder IPv6) | Anzahl der Einträge pro Ressourceneintragssatz | GKE 1.24 bis 1.25: 1.000 (IPv4 oder IPv6) GKE 1.26 und höher: 3.500 für IPv4; 2.000 für 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.
Mehr als ein Cluster pro Dienstprojekt
Ab den GKE-Versionen 1.22.3-gke.700 und 1.21.6-gke.1500 können Sie Cluster in mehreren Dienstprojekten erstellen, die auf eine VPC im selben Hostprojekt verweisen.
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
Um die Diensterkennung und Kompatibilität mit verschiedenen Clients und Systemen zu verbessern, können Sie Ergänzungen zur allgemeinen Kubernetes-DNS-Spezifikation verwenden.
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. Kubernetes definiert eine Mindestanzahl erforderlicher DNS-Einträge. Cloud DNS kann jedoch 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 |
|---|---|---|
| Single-Stack | ClusterIP | $$2+P$$ |
| Headless | $$2+P+2E$$ |
|
| Dual Stack | ClusterIP | $$3+P$$ |
| Headless | $$3+P+3E$$ |
|
| Weitere Informationen zu Single-Stack- und Dual-Stack-Diensten finden Sie unter Single-Stack- und Dual-Stack-Dienste. | ||
Zusätzliche von Cloud DNS erstellte DNS-Einträge
Cloud DNS erstellt möglicherweise zusätzliche DNS-Einträge über die Mindestanzahl von Eintragssätzen hinaus. Diese Datensätze dienen verschiedenen Zwecken, darunter:
- SRV-Einträge: Für die Dienstermittlung werden in Cloud DNS häufig SRV-Einträge erstellt. Diese Einträge enthalten Informationen zum Port und Protokoll des Dienstes.
- AAAA-Einträge (für Dual-Stack): In Dual-Stack-Konfigurationen, in denen sowohl IPv4 als auch IPv6 verwendet werden, erstellt Cloud DNS für jeden Endpunkt sowohl A-Einträge (für IPv4) als auch AAAA-Einträge (für IPv6).
- Interne Einträge: Cloud DNS kann interne Einträge für die eigene Verwaltung und Optimierung erstellen. Diese Datensätze sind für Nutzer in der Regel nicht direkt relevant.
- LoadBalancer-Dienste: Für Dienste vom Typ
LoadBalancererstellt Cloud DNS Einträge, die der IP-Adresse des externen Load Balancers zugeordnet sind. - Monitorlose Dienste: Monitorlose Dienste haben eine eigene DNS-Konfiguration. Jeder Pod erhält einen eigenen DNS-Eintrag, über den Clients direkt eine Verbindung zu den Pods herstellen können. Aus diesem Grund wird die Portnummer bei der Berechnung des Datensatzes für den monitorlosen Dienst nicht multipliziert.
Beispiel: Angenommen, es gibt einen Dienst namens 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 |
|---|---|---|
| Single-Stack | ClusterIP | $$2+2$$ |
| Headless | $$2+2+2*3$$ |
|
| Dual Stack | ClusterIP | $$3+2$$ |
| Headless | $$3+2+3*3$$ |
Zusätzlich zu diesen Mindesteinträgen erstellt Cloud DNS möglicherweise SRV-Einträge und bei Dual-Stack-Netzwerken AAAA-Einträge. Wenn my-http-server ein Dienst vom Typ „LoadBalancer“ ist, werden zusätzliche Datensätze für die Load-Balancer-IP 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
In diesem Abschnitt werden häufige Probleme beschrieben, die bei der Verwendung von Cloud DNS mit GKE auftreten können, sowie mögliche Problemumgehungen.
Terraform versucht, den Autopilot-Cluster aufgrund einer 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 oder 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 die Einstellung 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 fehl, wenn NodeLocal DNSCache aktiviert ist
In diesem Abschnitt wird ein bekanntes Problem für GKE-Cluster beschrieben, die sich in Cloud DNS befinden und für die NodeLocal DNSCache im Clusterbereich aktiviert ist.
Wenn NodeLocal DNSCache im Cluster aktiviert ist und Sie von kube-dns zu Cloud DNS migrieren, können im 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 lauscht: der NodeLocal DNSCache-Adresse und der kube-dns-Adresse.
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 GKE Dataplane V2 im Cluster aktiviert ist und der Cluster kube-dns verwendet, wird NodeLocal DNSCache in einem isolierten Netzwerk ausgeführt und so konfiguriert, dass er 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 der Cluster auf Cloud DNS aktualisiert wurde, wird die NodeLocal DNSCache-Konfiguration geändert. Führen Sie den folgenden Befehl aus, um die NodeLocal DNSCache-Konfiguration 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
bind 169.254.20.10
Im folgenden Workflow werden die Einträge in der Datei resolv.conf vor und nach der Migration und der Neuerstellung von Knoten erläutert:
Vor der Migration
- Für die Pods ist die Datei
resolv.conffür die IP-Adressekube-dnskonfiguriert (z. B.x.x.x.10). - NodeLocal DNSCache-Pods fangen DNS-Anfragen von Pods ab und überwachen die folgenden Ports:
- (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 minimal belastet.
Nach der Migration
- Nachdem die Steuerungsebene für die Verwendung von Cloud DNS aktualisiert wurde, ist in den Pods weiterhin die Datei
resolv.confmit der IP-Adressekube-dnskonfiguriert (z. B.x.x.x.10). Pods behalten dieseresolv.conf-Konfiguration bei, bis ihr Knoten neu erstellt wird. Wenn Cloud DNS mit NodeLocal DNSCache aktiviert ist, müssen Pods für die Verwendung von169.254.20.10als Nameserver konfiguriert werden. Diese Änderung gilt jedoch nur für Pods auf Knoten, die nach der Migration zu Cloud DNS erstellt oder neu erstellt wurden. - NodeLocal DNSCache-Pods überwachen nur die NodeLocal DNSCache-Adresse (bind 169.254.20.10). Anfragen werden nicht an NodeLocal DNSCache-Pods gesendet.
- Alle Anfragen von Pods werden direkt an
kube-dns-Pods gesendet. Bei dieser Einrichtung wird viel Traffic auf den Pods generiert.
Nach dem Neuerstellen von Knoten oder dem Upgrade von Knotenpools
- Für Pods ist die Datei
resolv.conffür die Verwendung der NodeLocal DNSCache-IP-Adresse (169.254.20.10) konfiguriert. - NodeLocal DNSCache-Pods überwachen nur die NodeLocal DNSCache-Adresse (bind 169.254.20.10) und empfangen DNS-Anfragen von Pods an dieser IP-Adresse.
Wenn Knotenpools die IP-Adresse kube-dns in der Datei resolv.conf verwenden, bevor der Knotenpool neu erstellt wird, führt eine Zunahme des DNS-Abfrage-Traffics auch zu einer Zunahme des Traffics für die kube-dns-Pods. Diese Zunahme kann zu zeitweiligen Fehlern bei DNS-Anfragen führen. Um Fehler zu minimieren, müssen Sie diese Migration während Ausfallzeiten planen.