kube-dns für GKE

Standard

Wenn Sie Anwendungen in Standardclustern ausführen, ist kube-dns der standardmäßige DNS-Anbieter, mit dem Sie die Diensterkennung und ‑kommunikation aktivieren können. In diesem Dokument wird beschrieben, wie Sie DNS mit kube-dns verwalten, einschließlich der Architektur, Konfiguration und Best Practices für die Optimierung der DNS-Auflösung in Ihrer GKE-Umgebung.

Dieses Dokument richtet sich an Entwickler, Administratoren und Architekten, die für die Verwaltung von DNS in GKE verantwortlich sind. Weitere Informationen zu gängigen Rollen und Aufgaben in Google Cloudfinden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Machen Sie sich vor Beginn mit Kubernetes-Diensten und allgemeinen DNS-Konzepten vertraut.

Hinweis: Die hier beschriebenen kube-dns-Konfigurationen gelten für Standardcluster. Wenn Sie Autopilot-Cluster verwenden, gelten diese Methoden nicht, da Autopilot Cloud DNS als Standard-DNS-Anbieter verwendet.

kube-dns-Architektur verstehen

kube-dns wird in Ihrem GKE-Cluster ausgeführt, um die DNS-Auflösung zwischen Pods und Diensten zu ermöglichen.

Das folgende Diagramm zeigt, wie Ihre Pods mit dem kube-dns-Dienst interagieren:

Schlüsselkomponenten

kube-dns umfasst die folgenden Schlüsselkomponenten:

• kube-dns Pods:In diesen Pods wird die kube-dns-Serversoftware ausgeführt. Mehrere Replikate dieser Pods werden im Namespace kube-system ausgeführt und bieten Hochverfügbarkeit und Redundanz.
• kube-dns-Dienst:In der folgenden Tabelle werden die Skalierbarkeits- und Konfigurationslimits der Legacy- und CoreDNS-basierten Versionen von kube-dns verglichen:

  Funktion	Legacy (kube-dns 1.35 und früher)	kube-dns auf CoreDNS (1.36 und höher)
  Endpunkt-Awareness	Bis zu 1.000 Endpunkte pro Dienst. Wenn ein Dienst mehr als 1.000 Pods hat, kennt kube-dns die zusätzlichen Endpunkte nicht.	Alle Endpunkte sind bekannt. In dieser Version werden EndpointSlices verwendet, um die Richtigkeit zu gewährleisten und die Effizienz für große Dienste zu verbessern.
  Upstream-Nameserver	Auf 3 begrenzt	Unterstützt bis zu 15 Geräte
  Gleichzeitige ausgehende TCP-Verbindungen	Auf 200 begrenzt	Unterstützt bis zu 1.500

• kube-dns-autoscaler:Dieser Pod passt die Anzahl der kube-dns-Replikate an die Größe des Clusters an, einschließlich der Anzahl der Knoten und CPU-Kerne. Dieser Ansatz trägt dazu bei, dass kube-dns unterschiedliche DNS-Abfragelasten bewältigen kann.

Interne DNS-Auflösung

Wenn ein Pod einen DNS-Namen in der Clusterdomain auflösen muss, z. B. myservice.my-namespace.svc.cluster.local, läuft der folgende Prozess ab:

1. Pod-DNS-Konfiguration:Die kubelet auf jedem Knoten konfiguriert die /etc/resolv.conf-Datei des Pods. In dieser Datei wird der Nameserver des kube-dns-Dienstes ClusterIP verwendet.
2. DNS-Anfrage:Der Pod sendet eine DNS-Anfrage an den kube-dns-Dienst.

3. Namensauflösung:

   • GKE-Version 1.36 oder höher:Die CoreDNS-basierte Implementierung verwendet EndpointSlices, damit kube-dns alle Pods in einem Dienst kennt. Dies verbessert die Richtigkeit und Effizienz für umfangreiche Dienste.
   • GKE-Version 1.35 oder früher:kube-dns löst Namen basierend auf der älteren Cloud Endpoints API auf, die auf 1.000 Endpunkte beschränkt ist. Wenn ein Dienst mehr als 1.000 unterstützende Pods hat, kennt kube-dns die zusätzlichen Endpunkte nicht.

4. Kommunikation:Der Pod verwendet dann die aufgelöste IP-Adresse, um mit dem Zieldienst zu kommunizieren.

Hinweis: VPC-übergreifende Einschränkung für Headless-Dienste:kube-dns kann keine IP-Adressen für Headless-Dienstendpunkte in der gesamten VPC oder in verschiedenen VPC-Netzwerken ermitteln. Wenn für Ihre Architektur eine VPC-übergreifende Erkennung für monitorlose Dienste erforderlich ist, verwenden Sie Cloud DNS für GKE als DNS-Anbieter anstelle von kube-dns.

Externe DNS-Auflösung

Wenn ein Pod einen externen DNS-Namen oder einen Namen außerhalb der Clusterdomain auflösen muss, fungiert kube-dns als rekursiver Resolver. Die Anfrage wird an vorgelagerte DNS-Server weitergeleitet, die in der Datei ConfigMap konfiguriert sind. Sie können auch benutzerdefinierte Resolver für bestimmte Domains konfigurieren, die auch als Stub-Domains bezeichnet werden. Mit dieser Konfiguration wird kube-dns angewiesen, Anfragen für diese Domains an bestimmte vorgelagerte DNS-Server weiterzuleiten.

Pod-DNS konfigurieren

In GKE konfiguriert der kubelet-Agent auf jedem Knoten die DNS-Einstellungen für die Pods, die auf diesem Knoten ausgeführt werden.

/etc/resolv.conf-Datei konfigurieren

Wenn GKE einen Pod erstellt, ändert der kubelet-Agent die /etc/resolv.conf-Datei des Pods. In dieser Datei wird der DNS-Server für die Namensauflösung konfiguriert und Suchdomains werden angegeben. Standardmäßig konfiguriert kubelet den Pod so, dass er den internen DNS-Dienst des Clusters, kube-dns, als Nameserver verwendet. Außerdem werden Suchdomains in die Datei eingefügt. Mit diesen Suchdomains können Sie in DNS-Abfragen nicht qualifizierte Namen verwenden. Wenn ein Pod beispielsweise myservice abfragt, versucht Kubernetes zuerst, myservice.default.svc.cluster.local aufzulösen, dann myservice.svc.cluster.local und dann andere Domains aus der Liste search.

Das folgende Beispiel zeigt eine Standardkonfiguration für /etc/resolv.conf:

nameserver 10.0.0.10
search default.svc.cluster.local svc.cluster.local cluster.local c.my-project-id.internal google.internal
options ndots:5

Diese Datei enthält die folgenden Einträge:

• nameserver: definiert den ClusterIP des kube-dns-Dienstes.
• search: Definiert die Suchdomains, die bei DNS-Lookups an nicht qualifizierte Namen angehängt werden.
• options ndots:5: Legt den Schwellenwert fest, ab dem GKE einen Namen als vollständig qualifiziert betrachtet. Ein Name gilt als voll qualifiziert, wenn er mindestens fünf Punkte enthält.

Hinweis: Der tatsächliche ClusterIP des kube-dns-Dienstes unterscheidet sich in den einzelnen Clustern. In Autopilot-Clustern wird kube-dns nicht verwendet. Stattdessen wird Cloud DNS als Standardanbieter für einen vollständig verwalteten DNS-Dienst verwendet.

Pods, die mit hostNetwork: true konfiguriert sind, übernehmen ihre DNS-Konfiguration vom Host und fragen kube-dns nicht direkt ab, es sei denn, sie verwenden ClusterFirstWithHostNet dnsPolicy.

kube-dns anpassen

kube-dns bietet eine robuste Standard-DNS-Auflösung. Sie können das Verhalten an bestimmte Anforderungen anpassen, z. B. die Effizienz der Auflösung verbessern oder bevorzugte DNS-Resolver verwenden. Sowohl Stub-Domains als auch Upstream-Nameserver werden konfiguriert, indem die ConfigMap kube-dns im Namespace kube-system geändert wird.

ConfigMap kube-dns ändern

So ändern Sie die kube-dns-ConfigMap:

1. Öffnen Sie die ConfigMap zum Bearbeiten:

   kubectl edit configmap kube-dns -n kube-system
   

2. Fügen Sie im Abschnitt data die Felder stubDomains und upstreamNameservers wie folgt hinzu:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     labels:
       addonmanager.kubernetes.io/mode: EnsureExists
     name: kube-dns
     namespace: kube-system
   data:
     stubDomains: |
       {
         "example.com": [
           "8.8.8.8",
           "8.8.4.4"
         ],
         "internal": [ # Required if your upstream nameservers can't resolve GKE internal domains
           "169.254.169.254" # IP of the metadata server
         ]
       }
     upstreamNameservers: |
       [
         "8.8.8.8", # Google Public DNS
         "8.8.4.4" # Google Public DNS Backup
       ]
   

3. Speichern Sie die ConfigMap. kube-dns lädt die Konfiguration automatisch neu.

Stub-Domains

Mit Stub-Domains können Sie benutzerdefinierte DNS-Resolver für bestimmte Domains definieren. Wenn ein Pod einen Namen in dieser Stub-Domain abfragt, leitet kube-dns die Anfrage an den angegebenen Resolver weiter, anstatt den Standardauflösungsmechanismus zu verwenden.

Sie fügen einen stubDomains-Abschnitt in die kube-dns ConfigMap ein.

In diesem Abschnitt werden die Domain und die entsprechenden vorgelagerten Nameserver angegeben. kube-dns leitet dann Anfragen für Namen innerhalb dieser Domain an die angegebenen Server weiter. Sie können beispielsweise alle DNS-Abfragen für internal.mycompany.com an 192.168.0.10 weiterleiten und "internal.mycompany.com": ["192.168.0.10"] zu stubDomains hinzufügen.

Wenn Sie einen benutzerdefinierten Resolver für eine Stub-Domain festlegen, z. B. example.com, leitet kube-dns alle Anfragen zur Namensauflösung für diese Domain, einschließlich Subdomains wie *.example.com, an die angegebenen Server weiter.

Vorgelagerte Nameserver

Sie können kube-dns so konfigurieren, dass benutzerdefinierte vorgelagerte Nameserver zum Auflösen externer Domainnamen verwendet werden. Mit dieser Konfiguration wird kube-dns angewiesen, alle DNS-Anfragen mit Ausnahme der Anfragen für die interne Domain des Clusters (*.cluster.local) an die angegebenen Upstream-Server weiterzuleiten. Interne Domains wie metadata.internal und *.google.internal können möglicherweise nicht von Ihren benutzerdefinierten vorgelagerten Servern aufgelöst werden. Wenn Sie die Workload Identity-Föderation für GKE aktivieren oder Arbeitslasten haben, die von diesen Domains abhängen, fügen Sie eine Stubs-Domain für internal in ConfigMap hinzu. Verwenden Sie 169.254.169.254, die IP-Adresse des Metadatenservers, als Resolver für diese Stub-Domain.

Benutzerdefiniertes kube-dns-Deployment verwalten

In einem Standardcluster wird kube-dns als Deployment ausgeführt. Bei einer benutzerdefinierten kube-dns-Bereitstellung können Sie als Clusteradministrator die Bereitstellung steuern und an Ihre Anforderungen anpassen, anstatt die standardmäßige von GKE bereitgestellte Bereitstellung zu verwenden.

Gründe für ein benutzerdefiniertes Deployment

Eine benutzerdefinierte kube-dns-Bereitstellung kann aus folgenden Gründen sinnvoll sein:

• Ressourcenzuweisung:Optimieren Sie CPU- und Arbeitsspeicherressourcen für kube-dns-Pods, um die Leistung in Clustern mit hohem DNS-Traffic zu optimieren.
• Image-Version:Verwenden Sie eine bestimmte Version des kube-dns-Images oder wechseln Sie zu einem alternativen DNS-Anbieter wie CoreDNS.
• Erweiterte Konfiguration:Hier können Sie Protokollierungsstufen, Sicherheitsrichtlinien und das DNS-Caching-Verhalten anpassen.

Autoscaling für benutzerdefinierte Deployments

Die integrierte kube-dns-autoscaler-Funktion funktioniert mit der Standardbereitstellung kube-dns. Wenn Sie eine benutzerdefinierte kube-dns-Bereitstellung erstellen, wird sie nicht vom integrierten Autoscaler verwaltet. Daher müssen Sie ein separates Autoscaling einrichten, das speziell für die Überwachung und Anpassung der Replikatanzahl Ihrer benutzerdefinierten Bereitstellung konfiguriert ist. Bei diesem Ansatz erstellen und stellen Sie Ihre eigene Autoscaler-Konfiguration in Ihrem Cluster bereit.

Wenn Sie eine benutzerdefinierte Bereitstellung verwalten, sind Sie für alle Komponenten verantwortlich, z. B. dafür, dass das Autoscaler-Image auf dem neuesten Stand ist. Die Verwendung veralteter Komponenten kann zu Leistungseinbußen oder DNS-Fehlern führen.

Eine ausführliche Anleitung zum Konfigurieren und Verwalten Ihres eigenen kube-dns-Deployments finden Sie unter Benutzerdefiniertes kube-dns-Deployment einrichten.

Fehlerbehebung

Informationen zur Fehlerbehebung bei kube-dns finden Sie auf den folgenden Seiten:

• Informationen zur Fehlerbehebung bei kube-dns in GKE finden Sie unter Fehlerbehebung bei kube-dns in GKE.
• Allgemeine Informationen zur Diagnose von Kubernetes DNS-Problemen finden Sie unter Debugging bei der DNS-Auflösung.

DNS-Auflösung optimieren

In diesem Abschnitt werden häufige Probleme und Best Practices für die Verwaltung von DNS in GKE beschrieben.

Limit für die dnsConfig Suchdomains eines Pods

In Kubernetes ist die Anzahl der DNS-Suchdomains auf 32 begrenzt. Wenn Sie versuchen, mehr als 32 Suchdomains in der dnsConfig eines Pods zu definieren, wird der Pod vom kube-apiserver nicht erstellt und es wird ein Fehler ähnlich dem folgenden angezeigt:

The Pod "dns-example" is invalid: spec.dnsConfig.searches: Invalid value: []string{"ns1.svc.cluster-domain.example", "my.dns.search.suffix1", "ns2.svc.cluster-domain.example", "my.dns.search.suffix2", "ns3.svc.cluster-domain.example", "my.dns.search.suffix3", "ns4.svc.cluster-domain.example", "my.dns.search.suffix4", "ns5.svc.cluster-domain.example", "my.dns.search.suffix5", "ns6.svc.cluster-domain.example", "my.dns.search.suffix6", "ns7.svc.cluster-domain.example", "my.dns.search.suffix7", "ns8.svc.cluster-domain.example", "my.dns.search.suffix8", "ns9.svc.cluster-domain.example", "my.dns.search.suffix9", "ns10.svc.cluster-domain.example", "my.dns.search.suffix10", "ns11.svc.cluster-domain.example", "my.dns.search.suffix11", "ns12.svc.cluster-domain.example", "my.dns.search.suffix12", "ns13.svc.cluster-domain.example", "my.dns.search.suffix13", "ns14.svc.cluster-domain.example", "my.dns.search.suffix14", "ns15.svc.cluster-domain.example", "my.dns.search.suffix15", "ns16.svc.cluster-domain.example", "my.dns.search.suffix16", "my.dns.search.suffix17"}: must not have more than 32 search paths.

Der kube-apiserver gibt diese Fehlermeldung als Reaktion auf einen Versuch zur Pod-Erstellung zurück. Entfernen Sie zusätzliche Suchpfade aus der Konfiguration, um dieses Problem zu beheben.

Upstream-Limit von nameservers für kube-dns

In älteren Versionen von kube-dns (Version 1.35 und früher) ist die Anzahl der upstreamNameservers auf drei begrenzt. Wenn Sie mehr als drei definieren, wird in Cloud Logging ein Fehler wie der folgende angezeigt:

Invalid configuration: upstreamNameserver cannot have more than three entries (value was &TypeMeta{Kind:,APIVersion:,}), ignoring update

In diesem Fall ignoriert kube-dns die upstreamNameservers-Konfiguration und verwendet weiterhin die vorherige gültige Konfiguration. Entfernen Sie die zusätzlichen upstreamNameservers aus dem kube-dns ConfigMap, um dieses Problem zu beheben.

kube-dns hochskalieren

In Standardclustern können Sie einen niedrigeren Wert für nodesPerReplica verwenden, damit mehr kube-dns-Pods erstellt werden, wenn Clusterknoten skaliert werden. Es wird dringend empfohlen, einen expliziten Wert für das Feld max festzulegen, damit die GKE-Steuerungsebenen-VM (Virtuelle Maschine) aufgrund der großen Anzahl von kube-dns-Pods, die die Kubernetes API überwachen, nicht überlastet ist.

Sie können den Wert des Felds max auf die Anzahl der Knoten im Cluster festlegen. Wenn der Cluster mehr als 500 Knoten hat, legen Sie den Wert des Felds max auf 500 fest.

Hinweis: Wenn Sie den Wert des Felds max auf 500 setzen, werden keine 500 Replikate erstellt. Stattdessen wird sichergestellt, dass kube-dns-Replikate nicht über den Wert des Felds max hinaus skaliert werden. In den meisten Fällen sollten Sie für das Feld max einen viel niedrigeren Wert als 500 festlegen.

Sie können die Anzahl der kube-dns-Replikate ändern, indem Sie die kube-dns-autoscaler ConfigMap bearbeiten.

kubectl edit configmap kube-dns-autoscaler --namespace=kube-system

Die Ausgabe sieht etwa so aus:

linear: '{"coresPerReplica":256, "nodesPerReplica":16,"preventSinglePointFailure":true}'

Die Anzahl der kube-dns-Replikate wird mit der folgenden Formel berechnet:

replicas = max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) )

Hinweis :Der Parameter coresPerReplica ist besonders nützlich für Cluster mit Knotenpools mit unterschiedlichen Maschinentypen und ‑größen. In solchen heterogenen Clustern spiegelt die Skalierung basierend auf der Anzahl der Knoten allein möglicherweise nicht die potenzielle DNS-Last wider. Durch die Konfiguration des Parameters coresPerReplica können Sie dafür sorgen, dass die Anzahl der kube-dns-Repliken mit der gesamten Rechenkapazität des Clusters skaliert wird. Dies führt zu einem genaueren und reaktionsfähigeren Skalierungsverhalten, das besser auf die Anforderungen der Arbeitslast abgestimmt ist.

Ändern Sie zum Hochskalieren den Wert des Felds nodesPerReplica in einen kleineren Wert und fügen Sie einen Wert für das Feld max ein.

linear: '{"coresPerReplica":256, "nodesPerReplica":8,"max": 15,"preventSinglePointFailure":true}'

Mit dieser Konfiguration wird ein kube-dns-Pod pro acht Knoten im Cluster erstellt. Ein Cluster mit 24 Knoten hat drei Replikate und ein Cluster mit 40 Knoten hat fünf Replikate. Wenn der Cluster über 120 Knoten hat, steigt die Anzahl der kube-dns-Replikate nicht über 15 an. Dies ist der Wert des Felds max.

Legen Sie eine Mindestanzahl von Replikat für das Feld kube-dns fest, um eine grundlegende DNS-Verfügbarkeit in Ihrem Cluster zu gewährleisten.

Die Ausgabe für kube-dns-autoscaler ConfigMap mit dem konfigurierten Feld min sieht etwa so aus:

linear: '{"coresPerReplica":256, "nodesPerReplica":8,"max": 15,"min": 5,"preventSinglePointFailure":true}'

DNS-Lookup-Zeiten verbessern

Hohe Latenz bei DNS-Lookups oder DNS-Auflösungsfehler mit dem Standardanbieter kube-dns können verschiedene Ursachen haben. Bei Anwendungen können diese Probleme als getaddrinfo EAI_AGAIN-Fehler auftreten, die auf einen vorübergehenden Fehler bei der Namensauflösung hinweisen. Mögliche Ursachen:

• Häufige DNS-Lookups innerhalb Ihrer Arbeitslast.
• Hohe Pod-Dichte pro Knoten.
• Die Ausführung von kube-dns auf Spot-VMs oder VMs auf Abruf, was zu unerwarteten Knotenlöschungen führen kann.
• Verbindungslimits:Bei Legacy-Versionen von kube-dns (GKE-Version 1.35 und früher) sind maximal 200 gleichzeitige TCP-Verbindungen möglich. kube-dns in CoreDNS (GKE-Version 1.36 und höher) entfernt diese festen Limits für eingehende Verbindungen und bietet eine deutlich höhere Kapazität für ausgehende Verbindungen.

So verbessern Sie die DNS-Lookup-Zeiten:

• Vermeiden Sie die Ausführung kritischer Systemkomponenten wie kube-dns auf Spot-VMs oder VMs auf Abruf. Erstellen Sie mindestens einen Knotenpool mit Standard-VMs, der keine Spot-VMs oder VMs auf Abruf enthält. Verwenden Sie Markierungen und Toleranzen, um dafür zu sorgen, dass kritische Arbeitslasten auf diesen zuverlässigen Knoten geplant werden.
• NodeLocal DNSCache aktivieren. NodeLocal DNSCache speichert DNS-Antworten direkt auf jedem Knoten im Cache. Dadurch werden die Latenz und die Last für den kube-dns-Dienst reduziert. Wenn Sie NodeLocal DNSCache aktivieren und Netzwerkrichtlinien mit Standardablehnungsregeln verwenden, fügen Sie eine Richtlinie hinzu, die es Arbeitslasten erlaubt, DNS-Abfragen an die node-local-dns-Pods zu senden.
• Skalieren Sie kube-dns hoch.
• Achten Sie darauf, dass Ihre Anwendung dns.resolve*-basierte Funktionen anstelle von dns.lookup-basierten Funktionen verwendet, da dns.lookup synchron ist.
• Verwenden Sie voll qualifizierte Domainnamen (FQDNs), z. B. https://google.com./ anstelle von https://google.com/.

Während GKE-Clusterupgrades können Fehler bei der DNS-Auflösung auftreten, da Komponenten der Steuerungsebene, einschließlich kube-dns, gleichzeitig aktualisiert werden. Diese Fehler betreffen in der Regel nur einen kleinen Prozentsatz der Knoten. Testen Sie Cluster-Upgrades gründlich in einer Nicht-Produktionsumgebung, bevor Sie sie auf Produktionscluster anwenden.

Dienstsichtbarkeit sicherstellen

kube-dns erstellt nur DNS-Einträge für Services, die Endpunkte haben. Wenn ein Dienst keine Endpunkte hat, erstellt kube-dns keine DNS-Einträge für diesen Dienst.

Abweichungen bei der DNS-Gültigkeitsdauer (TTL) verwalten

Wenn kube-dns eine DNS-Antwort von einem vorgelagerten DNS-Resolver mit einer großen oder unbegrenzten TTL empfängt, behält es diesen TTL-Wert bei. Dieses Verhalten kann zu einer Diskrepanz zwischen dem Cache-Eintrag und der tatsächlichen IP-Adresse führen.

In GKE wird dieses Problem in bestimmten Steuerungsebenenversionen behoben, z. B. in 1.21.14-gke.9100 und höher oder 1.22.15-gke.2100 und höher. In diesen Versionen wird ein maximaler TTL-Wert von 30 Sekunden für jede DNS-Antwort mit einer höheren TTL festgelegt. Dieses Verhalten ähnelt NodeLocal DNSCache.

kube-dns-Messwerte ansehen

Sie können Messwerte zu DNS-Abfragen direkt von den kube-dns-Pods abrufen. Wie Sie diese Messwerte abrufen, hängt von Ihrer GKE-Version ab.

GKE-Version 1.36 und höher

Wenn auf Ihrem Cluster GKE-Version 1.36 oder höher (kube-dns auf CoreDNS) ausgeführt wird, können Sie die DNS-Leistung mit vordefinierten Dashboards in Cloud Monitoring überwachen oder Messwerte manuell aus den Pods abrufen.

Messwerte in der Google Cloud Console ansehen

1. Rufen Sie in der Google Cloud Console die Seite Dashboards auf.
2. Wählen Sie das Dashboard GKE DNS Observability – Cluster View aus.

Alternativ können Sie diese Messwerte direkt in der Google Cloud Console abfragen. Rufen Sie dazu Monitoring > Metrics Explorer auf und suchen Sie nach den entsprechenden Messwertnamen.

Messwerte manuell abrufen

So rufen Sie Messwerte manuell aus dem Pod ab:

1. Suchen Sie die kube-dns-Pods.

   kubectl get pods -n kube-system --selector=k8s-app=kube-dns
   

2. Leiten Sie Port 9153 an einen der Pods weiter.

   kubectl port-forward pod/POD_NAME -n kube-system 9153:9153
   

   Ersetzen Sie POD_NAME durch den Namen eines der kube-dns-Pods aus der vorherigen Ausgabe.

3. Auf die Messwerte zugreifen

   curl http://127.0.0.1:9153/metrics
   

GKE-Version 1.35 und früher

In dieser Version von kube-dns werden Pods mit mehreren Containern verwendet. So rufen Sie Messwerte ab:

1. Suchen Sie im Namespace kube-system nach den kube-dns-Pods.

   kubectl get pods -n kube-system --selector=k8s-app=kube-dns
   

2. Portweiterleitung zu den Ports 10055 (für den kube-dns-Container) und 10054 (für den dnsmasq-Container):

   #For the kube-dns container
   kubectl port-forward pod/POD_NAME -n kube-system 10055:10055
   #For the dnsmasq container
   kubectl port-forward pod/POD_NAME -n kube-system 10054:10054
   

   Ersetzen Sie POD_NAME durch den Namen eines der kube-dns-Pods aus der vorherigen Ausgabe. Führen Sie diese Portweiterleitungsbefehle in separaten Terminalsitzungen aus.

3. Auf die Messwerte zugreifen

   #Metrics from the kube-dns container
   curl http://127.0.0.1:10055/metrics
   
   #Metrics from the dnsmasq container
   curl http://127.0.0.1:10054/metrics
   

Nächste Schritte

• Übersicht über Cluster-DNS in GKE
• Eine Übersicht zur Verwendung von DNS in Kubernetes-Clustern finden Sie unter DNS für Dienste und Pods.
• Informationen zum Einrichten von NodeLocal DNSCache
• Informationen zum Einrichten eines benutzerdefinierten kube-dns-Deployments