Service Discovery

In diesem Dokument wird erläutert, wie Service Discovery in Google Kubernetes Engine (GKE) die Anwendungsverwaltung vereinfacht und wie Sie Service Discovery mithilfe von Cloud DNS-Bereichen, Multi-Cluster-Diensten (MCS) und Service Directory über einen einzelnen Cluster hinaus erweitern können.

Dieses Dokument richtet sich an GKE-Nutzer, Entwickler, Administratoren und Architekten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Bevor Sie dieses Dokument lesen, sollten Sie mit den folgenden Konzepten vertraut sein:

Übersicht

Die Diensterkennung ist ein Mechanismus, mit dem Dienste und Anwendungen dynamisch miteinander kommunizieren können, ohne IP-Adressen oder Endpunktkonfigurationen fest zu codieren. Die Dienstermittlung trägt dazu bei, dass Anwendungen immer Zugriff auf aktuelle Pod-IP-Adressen haben, auch wenn Pods neu geplant oder neue Pods hinzugefügt werden. GKE bietet mehrere Möglichkeiten zur Implementierung von Service Discovery, darunter kube-dns, benutzerdefinierte kube-dns-Bereitstellungen und Cloud DNS. Sie können die DNS-Leistung mit NodeLocal DNSCache weiter optimieren.

Vorteile von Service Discovery

Die Dienstermittlung bietet folgende Vorteile:

  • Vereinfachte Anwendungsverwaltung: Durch die Service Discovery müssen IP-Adressen nicht mehr in Ihren Anwendungskonfigurationen fest codiert werden. Anwendungen kommunizieren über logische Dienstnamen, die automatisch in die richtigen Pod-IP-Adressen aufgelöst werden. Dieser Ansatz vereinfacht die Konfiguration, insbesondere in dynamischen Umgebungen, in denen sich Pod-IP-Adressen aufgrund von Skalierung oder Neuplanung ändern können.
  • Vereinfachte Skalierung und Resilienz: Die Diensterkennung vereinfacht die Skalierung, da Dienstnutzer von Pod-IP-Adressen entkoppelt werden, die sich häufig ändern. Wenn Ihre Anwendung skaliert wird oder Pods ausfallen und ersetzt werden, aktualisiert Kubernetes automatisch, welche Pods für einen bestimmten Dienst Traffic empfangen können. Die Diensterkennung sorgt dafür, dass Anfragen an den stabilen Dienstnamen nur an fehlerfreie Pods weitergeleitet werden. So kann Ihre Anwendung ohne manuellen Eingriff oder Neukonfiguration des Clients skaliert werden oder sich von Fehlern erholen.
  • Hohe Verfügbarkeit: GKE verwendet Load-Balancing in Kombination mit Service Discovery, um die hohe Verfügbarkeit zu gewährleisten und die Reaktionsfähigkeit Ihrer Anwendungen zu verbessern, auch bei hoher Last.

Load-Balancing mit Dienstermittlung

GKE trägt zur hohen Verfügbarkeit Ihrer Anwendungen bei, indem verschiedene Load-Balancing-Ebenen mit der Diensterkennung kombiniert werden.

  • Interne Dienste: Für Dienste, auf die nur innerhalb des Clusters zugegriffen werden kann, fungiert die Datenebene von GKE (kube-proxy oder Cilium) als Load Balancer. Er verteilt den eingehenden Traffic gleichmäßig auf mehrere fehlerfreie Pods, um Überlastungen zu vermeiden und für eine hohe Verfügbarkeit zu sorgen.
  • Externe Dienste: Für Dienste, auf die von außerhalb des Clusters zugegriffen werden muss, stellt GKE Google Cloud Load Balancer bereit. Dazu gehören externe Google Cloud Load Balancer für den öffentlichen Internetzugriff und interne Google Cloud Load Balancer für den Zugriff in Ihrem VPC-Netzwerk. Diese Load-Balancer verteilen den Traffic auf die Knoten in Ihrem Cluster. Die Datenebene auf jedem Knoten leitet den Traffic dann weiter an die entsprechenden Pods.

Sowohl in internen als auch in externen Szenarien wird die Liste der verfügbaren Pods für jeden Dienst durch die Diensterkennung kontinuierlich aktualisiert. Durch diese kontinuierliche Aktualisierung wird sichergestellt, dass sowohl die Datenebene (für interne Dienste) als auch die Google Cloud Load-Balancer (für externe Dienste) Traffic nur an fehlerfreie Instanzen weiterleiten.

Anwendungsfälle für die Diensterkennung

Im Folgenden sind einige gängige Anwendungsfälle für die Dienstermittlung aufgeführt:

  • Mikrodienstarchitektur: In einer Mikrodienstarchitektur bestehen Anwendungen oft aus vielen kleineren, unabhängigen Diensten, die miteinander interagieren müssen. Durch die Diensterkennung können diese Anwendungen einander finden und Informationen austauschen, auch wenn der Cluster skaliert wird.
  • Bereitstellungen ohne Ausfallzeiten ermöglichen und Ausfallsicherheit verbessern: Die Dienstermittlung ermöglicht Updates ohne Ausfallzeiten für Anwendungen, einschließlich kontrollierter Rollouts und Canary-Bereitstellungen. Es automatisiert die Erkennung neuer Dienstversionen und leitet den Traffic zu diesen weiter. So werden Ausfallzeiten während der Bereitstellung reduziert und ein reibungsloser Übergang für Nutzer gewährleistet. Die Diensterkennung erhöht auch die Stabilität. Wenn ein Pod in GKE ausfällt, wird ein neuer bereitgestellt. Die Dienstermittlung registriert den neuen Pod und leitet den Traffic an ihn weiter. So wird die Ausfallzeit der Anwendung minimiert.

Funktionsweise der Diensterkennung

In GKE bestehen Anwendungen oft aus mehreren Pods, die sich gegenseitig finden und miteinander kommunizieren müssen. Die Diensterkennung bietet diese Möglichkeit über das Domain Name System (DNS). Ähnlich wie Sie DNS verwenden, um Websites im Internet zu finden, verwenden Pods in einem GKE-Cluster DNS, um Dienste anhand ihrer Dienstnamen zu finden und eine Verbindung zu ihnen herzustellen. Mit diesem Ansatz können Pods effektiv interagieren, unabhängig davon, wo sie im Cluster ausgeführt werden. Außerdem können Anwendungen über konsistente Dienstnamen anstelle von instabilen IP-Adressen kommunizieren.

DNS-Auflösung durch Pods

Pods in einem GKE-Cluster lösen DNS-Namen für Dienste und andere Pods mithilfe einer Kombination aus automatisch generierten DNS-Einträgen und ihrer lokalen DNS-Konfiguration auf.

DNS-Namen für Dienste

Wenn Sie einen Kubernetes-Dienst erstellen, weist GKE ihm automatisch einen DNS-Namen zu. Dieser Name folgt einem vorhersehbaren Format, das jeder Pod im Cluster für den Zugriff auf den Dienst verwenden kann:

<service-name>.<namespace>.svc.cluster.local

Die Standardclusterdomain ist cluster.local. Sie können die Domain jedoch anpassen, wenn Sie den Cluster erstellen. Ein Dienst mit dem Namen my-web-app im Standard-Namespace hätte beispielsweise den DNS-Namen my-web-app.default.svc.cluster.local.

Die Rolle von /etc/resolv.conf

Zum Auflösen dieser DNS-Namen greifen Pods auf ihre /etc/resolv.conf-Datei zurück. In dieser Konfigurationsdatei wird dem Pod mitgeteilt, an welchen Nameserver seine DNS-Abfragen gesendet werden sollen. Die IP-Adresse des in dieser Datei aufgeführten Nameservers hängt von den spezifischen DNS-Funktionen ab, die in Ihrem GKE-Cluster aktiviert sind. In der folgenden Tabelle wird die Nameserver-IP aufgeführt, die ein Pod basierend auf Ihrer Konfiguration verwendet:

Cloud DNS für GKE NodeLocal DNSCache `/etc/resolv.conf`-Nameserverwert
Aktiviert Aktiviert `169.254.20.10`
Aktiviert Deaktiviert `169.254.169.254`
Deaktiviert Aktiviert IP-Adresse des Dienstes „kube-dns“
Deaktiviert Deaktiviert IP-Adresse des Dienstes „kube-dns“

Diese Konfiguration sorgt dafür, dass DNS-Abfragen vom Pod an die richtige Komponente weitergeleitet werden:

  • NodeLocal DNSCache: Ermöglicht schnelle, lokale Suchvorgänge auf dem Knoten.
  • Metadatenserver-IP (169.254.169.254): Wird verwendet, wenn Cloud DNS für GKE ohne NodeLocal DNSCache aktiviert ist. DNS-Abfragen werden an diese IP-Adresse weitergeleitet, die Cloud DNS verwendet, um DNS-Anfragen abzufangen und zu verarbeiten.
  • kube-dns Dienst-IP-Adresse: Wird für die Standardauflösung im Cluster verwendet, wenn Cloud DNS für GKE deaktiviert ist.

DNS-Architektur in GKE

GKE bietet eine flexible Architektur für die Diensterkennung, hauptsächlich über DNS. Die folgenden Komponenten arbeiten zusammen, um DNS-Anfragen in Ihrem Cluster aufzulösen:

  • kube-dns: Der Standard-DNS-Anbieter im Cluster für GKE-Standardcluster. Er wird als verwaltetes Deployment von Pods im Namespace kube-system ausgeführt und überwacht die Kubernetes API auf neue Dienste, um die erforderlichen DNS-Einträge zu erstellen.
  • Cloud DNS: Google Clouds vollständig verwalteter DNS-Dienst. Er bietet eine hochgradig skalierbare und zuverlässige Alternative zu kube-dns und ist der Standard-DNS-Anbieter für GKE Autopilot-Cluster.
  • NodeLocal DNSCache: Ein GKE-Add-on, das die Leistung von DNS-Lookups verbessert. Es wird ein DNS-Cache auf jedem Knoten in Ihrem Cluster ausgeführt, der entweder mit kube-dns oder Cloud DNS zusammenarbeitet, um DNS-Abfragen lokal zu beantworten. Dadurch werden die Latenz und die Last auf den zentralen DNS-Anbieter des Clusters reduziert. Für GKE Autopilot-Cluster ist NodeLocal DNSCache standardmäßig aktiviert und kann nicht überschrieben werden.
  • Benutzerdefinierte kube-dns-Bereitstellung: Eine Bereitstellung, mit der Sie Ihre eigene Instanz von kube-dns bereitstellen und verwalten können. So haben Sie mehr Kontrolle über die Konfiguration und Ressourcen von kube-dns.

DNS-Anbieter auswählen

In der folgenden Tabelle sind die in GKE verfügbaren DNS-Anbieter zusammengefasst, einschließlich ihrer Funktionen und der Gründe für die Auswahl der einzelnen Anbieter:

Anbieter Features Wann sollte ich
`kube-dns` Clusterinterne DNS-Auflösung für Dienste und Pods. Alle Cluster mit Standardanforderungen an das Netzwerk. Die neue Version von `kube-dns` eignet sich sowohl für kleine als auch für große Cluster.
Cloud DNS Erweiterte DNS-Funktionen (private Zonen, Traffic Steering, globales Load-Balancing) und Integration mit anderen Google Cloud -Diensten. Services extern freigeben, Multi-Cluster-Umgebungen oder Cluster mit hohen DNS-Abfrageraten (QPS).
Benutzerdefiniertes `kube-dns`-Deployment Zusätzliche Kontrolle über die Konfiguration, die Ressourcenzuweisung und die Möglichkeit, alternative DNS-Anbieter zu verwenden. Große Cluster oder spezielle DNS-Anforderungen, die eine aggressivere Skalierung oder eine detaillierte Steuerung der Ressourcenzuweisung erfordern.

Service Discovery außerhalb eines einzelnen Clusters

Mit den folgenden Methoden können Sie die Service Discovery über einen einzelnen GKE-Cluster hinaus erweitern:

Cloud DNS-Bereich

Cluster, die Cloud DNS für Cluster-DNS verwenden, können in einem von drei verfügbaren Bereichen betrieben werden:

  • Clusterbereich: Dies ist das Standardverhalten für Cloud DNS. In diesem Modus funktioniert Cloud DNS wie kube-dns und bietet die DNS-Auflösung ausschließlich für Ressourcen innerhalb des Clusters. DNS-Einträge können nur innerhalb des Clusters aufgelöst werden und entsprechen dem Standardschema für Kubernetes-Dienste: <svc>.<ns>.svc.cluster.local.
  • Additiver VPC-Bereich: Dieses optionale Feature erweitert den Clusterbereich, indem monitorlose Dienste von anderen Ressourcen im selben VPC-Netzwerk aufgelöst werden können, z. B. von Compute Engine-VMs oder lokalen Clients, die über Cloud VPN oder Cloud Interconnect verbunden sind.
  • VPC-Bereich: Bei dieser Konfiguration können DNS-Einträge für Clusterdienste im gesamten VPC-Netzwerk aufgelöst werden. Das bedeutet, dass jeder Client, der sich in derselben VPC befindet oder über Cloud VPN oder Cloud Interconnect mit ihr verbunden ist, Dienstnamen direkt auflösen kann.

Weitere Informationen zum VPC-Bereichs-DNS finden Sie unter Cloud DNS für GKE verwenden.

Multi-Cluster-Dienste

Multi-Cluster-Services (MCS) ermöglichen Service Discovery und Traffic-Management in mehreren GKE-Clustern. Mit MCS können Sie Anwendungen erstellen, die Cluster umfassen und gleichzeitig eine einheitliche Dienstumgebung bieten.

MCS nutzt die DNS-basierte Diensterkennung, um Dienste clusterübergreifend zu verbinden. Wenn Sie eine MCS-Instanz erstellen, werden DNS-Einträge im Format <svc>.<ns>.svc.clusterset.local generiert. Diese Einträge werden in die IP-Adressen der Endpunkte des Dienstes in jedem beteiligten Cluster aufgelöst.

Wenn ein Client in einem Cluster auf einen MCS zugreift, werden Anfragen an den nächstgelegenen verfügbaren Endpunkt in einem der beteiligten Cluster weitergeleitet. Diese Traffic-Verteilung wird von kube-proxy (oder Cilium in GKE Dataplane V2) auf jedem Knoten verwaltet. So wird eine effiziente Kommunikation und ein effizientes Load-Balancing in Clustern ermöglicht.

Service Directory für GKE

Service Directory für GKE bietet eine einheitliche Registry für die Dienstermittlung in Ihren Kubernetes- und Nicht-Kubernetes-Deployments. Service Directory kann sowohl GKE- als auch Nicht-GKE-Dienste in einer einzigen Registry registrieren.

Service Directory ist besonders in folgenden Fällen nützlich:

  • Sie benötigen eine einzige Registry für Kubernetes- und Nicht-Kubernetes-Anwendungen zur gegenseitigen Discovery.
  • Sie benötigen ein verwaltetes Service Discovery-Tool.
  • Die Möglichkeit, Metadaten zu Ihrem Dienst zu speichern, auf die andere Clients zugreifen können.
  • Die Möglichkeit, Zugriffsberechtigungen auf Dienstebene festzulegen. Service Directory-Dienste können über DNS, HTTP und gRPC aufgelöst werden. Service Directory ist in Cloud DNS eingebunden und kann Cloud DNS-Einträge ergänzen, die Diensten in Service Directory entsprechen.

Weitere Informationen finden Sie unter Service Directory für GKE konfigurieren.

DNS-Leistung optimieren und Best Practices

Damit die Dienstermittlung zuverlässig und effizient funktioniert, insbesondere in Clustern mit großem Umfang oder hohem Traffic, sollten Sie die folgenden Best Practices und Optimierungsstrategien berücksichtigen.

Leistung mit NodeLocal DNSCache optimieren

Bei Clustern mit einer hohen Pod-Dichte oder Anwendungen, die eine große Anzahl von DNS-Abfragen generieren, können Sie die DNS-Lookup-Geschwindigkeit verbessern, indem Sie NodeLocal DNSCache aktivieren. NodeLocal DNSCache ist ein GKE-Add-on, das auf jedem Knoten in Ihrem Cluster einen DNS-Cache ausführt. Wenn ein Pod eine DNS-Anfrage stellt, wird die Anfrage an den Cache auf demselben Knoten gesendet. Dadurch werden Latenz und Netzwerkverkehr reduziert.

Weitere Informationen zum Aktivieren und Konfigurieren dieses Features finden Sie unter NodeLocal DNSCache einrichten.

DNS-Anbieter skalieren

Wenn Sie kube-dns verwenden und es zu zeitweiligen Zeitüberschreitungen kommt, insbesondere bei hohem Traffic, müssen Sie möglicherweise die Anzahl der kube-dns-Replikate skalieren. Der kube-dns-autoscaler passt die Anzahl der Replikate an die Anzahl der Knoten und Kerne im Cluster an. Seine Parameter können so angepasst werden, dass mehr Replikate schneller bereitgestellt werden.

Eine ausführliche Anleitung finden Sie unter kube-dns skalieren.

Allgemeine Best Practices

  • Geeigneten DNS-Anbieter auswählen: Wählen Sie Ihren DNS-Anbieter basierend auf den Anforderungen Ihres Clusters aus. Cloud DNS wird für Arbeitslasten mit hohem QPS, Multi-Cluster-Umgebungen und bei Bedarf an einer Integration in Ihr gesamtes VPC-Netzwerk empfohlen. Die neue Version von kube-dns eignet sich für eine Vielzahl von Clustern, von klein bis groß, die Standardanforderungen an die Service Discovery im Cluster haben.
  • Spot-VMs oder VMs auf Abruf für kube-dns vermeiden: Sorgen Sie für die Stabilität des DNS-Dienstes Ihres Clusters, indem Sie kritische Systemkomponenten wie kube-dns nicht auf Spot-VMs oder VMs auf Abruf ausführen. Unerwartete Knotenbeendigungen können zu Problemen bei der DNS-Auflösung führen.
  • Klare und aussagekräftige Dienstnamen verwenden: Verwenden Sie konsistente und aussagekräftige Namenskonventionen für Ihre Dienste, damit Anwendungs-Konfigurationen leichter zu lesen und zu verwalten sind.
  • Mit Namespaces organisieren: Verwenden Sie Kubernetes-Namespaces, um zugehörige Dienste zu gruppieren. So lassen sich Konflikte bei der Benennung vermeiden und die Organisation von Clusterressourcen wird verbessert.
  • DNS überwachen und validieren: Überwachen Sie regelmäßig DNS-Messwerte und ‑Logs, um potenzielle Probleme zu erkennen, bevor sie sich auf Ihre Anwendungen auswirken. Testen Sie regelmäßig die DNS-Auflösung in Ihren Pods, um sicherzustellen, dass die Diensterkennung wie erwartet funktioniert.

Nächste Schritte