Mithilfe dieses Dokuments können Sie entscheiden, ob Cloud DNS für GKE die richtige DNS-Lösung für Ihren Cluster ist. Sie können Cloud DNS als Alternative zu clustergehosteten DNS-Anbietern wie kube-dns für die Pod- und Dienst-DNS-Auflösung verwenden.
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-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-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 Cluster-gehostetem DNS die folgenden Vorteile:
- Geringerer Aufwand: Cluster-gehostete DNS-Server müssen nicht mehr verwaltet werden. 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: Abfragen werden lokal für jeden GKE-Knoten aufgelöst, 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, da dadurch eine zusätzliche Caching-Ebene auf dem Knoten bereitgestellt wird.
- Einbindung in Google Cloud Observability: ermöglicht 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:
Im Diagramm wählt das Service-Backend die ausgeführten Backend-Pods aus. Der clouddns-Controller erstellt einen DNS-Eintrag für das Service-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 verschiedene 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 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.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 die Standardeinstellung.- 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, wobei monitorlose Dienste im gesamten VPC-Netzwerk aufgelöst werden können | Gesamtes VPC-Netzwerk |
| Headless Service-Auflösung | 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 |
| Einrichtungskonfiguration | 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-bezogene 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 den Clusterbereich für die Bereitstellung des internen DNS-Traffics verwenden, 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, werden auf die Cloud DNS-Ressourcenlimits angerechnet, 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 Service Discovery und die Kompatibilität mit verschiedenen Clients und Systemen zu verbessern, können Sie zusätzlich zur allgemeinen Kubernetes-DNS-Spezifikation weitere Ergänzungen 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. Die folgenden Tabellen veranschaulichen die Mindestanzahl der erwarteten Datensatzgruppen, wobei „E“ die Anzahl der Endpunkte und „P“ die Anzahl der Ports darstellt.
Cloud DNS erstellt möglicherweise zusätzliche Einträge.
| 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 DNS-Einträge, die von Cloud DNS erstellt wurden
Cloud DNS erstellt möglicherweise zusätzliche DNS-Einträge, die über die Mindestanzahl von Eintragssätzen hinausgehen. Diese Einträge dienen verschiedenen Zwecken, darunter:
- SRV-Einträge: Für die Service Discovery 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, die sowohl IPv4 als auch IPv6 verwenden, 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 erstellt möglicherweise interne Einträge für die eigene Verwaltung und Optimierung. Diese Datensätze sind in der Regel nicht direkt für Nutzer relevant.
- LoadBalancer-Dienste: Für Dienste vom Typ
LoadBalancererstellt Cloud DNS Einträge, die mit der IP-Adresse des externen Load Balancers verknüpft 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 monitorlosen Diensteintrags 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 ist 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 kann Cloud DNS SRV-Einträge und im Fall von Dual-Stack-Netzwerken AAAA-Einträge erstellen. Wenn my-http-server ein Dienst vom Typ „LoadBalancer“ ist, werden zusätzliche Einträge für die Load-Balancer-IP-Adresse erstellt. Hinweis: Cloud DNS fügt nach 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 mit aktiviertem NodeLocal DNSCache fehl
In diesem Abschnitt wird ein bekanntes Problem für GKE-Cluster in Cloud DNS beschrieben, in denen NodeLocal DNSCache im Clusterbereich aktiviert ist.
Wenn NodeLocal DNSCache im Cluster aktiviert ist und Sie von kube-dns zu Cloud DNS migrieren, kann es im Cluster zu zeitweiligen Auflösungsfehlern kommen.
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 ist 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 Folgendes:
- (DPv1) beide Adressen (bind 169.254.20.10 x.x.x.10).
- (DPv2) Alle Pod-IP-Adressen (Bindung an 0.0.0.0).
- NodeLocal DNSCache funktioniert 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-dns(z. B.x.x.x.10) konfiguriert. Pods behalten dieseresolv.conf-Konfiguration bei, bis ihr Knoten neu erstellt wird. Wenn Cloud DNS mit NodeLocal DNSCache aktiviert ist, müssen Pods so konfiguriert sein, dass sie169.254.20.10als Nameserver verwenden. 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 lauschen nur an der 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
- Bei Pods ist die Datei
resolv.confso konfiguriert, dass die IP-Adresse von NodeLocal DNSCache (169.254.20.10) verwendet wird. - 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 kube-dns-IP-Adresse in der resolv.conf-Datei verwenden, bevor der Knotenpool neu erstellt wird, führt eine Zunahme des DNS-Anfrage-Traffics auch zu einer Zunahme des Traffics für die kube-dns-Pods. Dieser Anstieg kann zu zeitweiligen Fehlern bei DNS-Anfragen führen. Um Fehler zu minimieren, sollten Sie diese Migration während der Ausfallzeiten planen.