Multi-Cluster-Ingress

Autopilot Standard

Multi-Cluster-Ingress ist ein in der Cloud gehosteter Controller für GKE-Cluster (Google Kubernetes Engine). Dieser von Google gehostete Dienst unterstützt das cluster- und regionenübergreifende Deployment von freigegebenen Load-Balancing-Ressourcen. Zum Bereitstellen von Multi-Cluster-Ingress über mehrere Cluster hinweg folgen Sie der Anleitung unter Multi-Cluster-Ingress einrichten und lesen Sie dann Ingress in mehreren Clustern bereitstellen.

Einen detaillierten Vergleich zwischen dem Multi-Cluster-Ingress (MCI), Multi-Cluster-Gateway (MCG) und dem Load Balancer mit eigenständigen Netzwerk-Endpunktgruppen (LB und eigenständige NEGs) finden Sie unter Multi-Cluster-Load-Balancing-API für GKE auswählen.

Multi-Cluster-Netzwerke

Viele Faktoren sprechen für Multi-Cluster-Topologien, darunter die Nähe zum Anwender, Hochverfügbarkeit auf Cluster- und regionaler Ebene, Sicherheit und organisatorische Trennung, Clustermigration und Datenlokalität. Ferner bestehen meistens mehrere dieser Anforderungen gleichzeitig. Mit der steigenden Nachfrage nach mehreren Clustern zugleich steigt auch der Bedarf an offiziell als Produkt verfügbaren Multi-Cluster-Plattformen.

Multi-Cluster-Ingress ist auf die Load-Balancing-Anforderungen in Umgebungen mit mehreren Clustern und Regionen ausgelegt. Es dient als Controller für den externen HTTP(S)-Load-Balancer, der eingehenden Traffic aus dem Internet über einen oder mehrere Cluster bereitstellt.

Dank der Unterstützung für mehrere Cluster durch den Multi-Cluster-Ingress können viele Anwendungsfälle abgedeckt werden:

Eine einzelne, konsistente virtuelle IP-Adresse (VIP) für eine Anwendung, unabhängig davon, wo die Anwendung global bereitgestellt wird
Verfügbarkeit in mehreren Clustern und Regionen durch Systemdiagnose und Traffic-Failover
Entfernungsbasiertes Routing über öffentliche Anycast-VIPs für geringe Clientlatenz
Transparente Clustermigration für Upgrades oder Neuerstellungen von Clustern

Standardkontingente

Für Multi-Cluster-Ingress gelten die folgenden Standardkontingente:

Weitere Informationen zu Mitgliederlimits für Flotten finden Sie unter Flottenverwaltungskontingente. Dort erfahren Sie, wie viele Mitglieder in einer Flotte unterstützt werden.
100 MultiClusterIngress-Ressourcen und 100 MultiClusterService-Ressourcen pro Projekt. Sie können bis zu 100 MultiClusterIngress- und 100 MultiClusterService-Ressourcen für eine beliebige Anzahl an Backend-Clustern bis zur maximalen Clusteranzahl des Projekts in einem Konfigurationscluster erstellen.

Preise und Testversionen

Weitere Informationen zu den Preisen für Multi-Cluster-Ingress finden Sie unter Preise für Multi-Cluster-Ingress.

Funktionsweise von Multi-Cluster-Ingress

Multi-Cluster-Ingress basiert auf der Architektur des globalen externen Application Load Balancers. Der globale externe Application Load Balancer ist ein global verteilter Load-Balancer mit Proxys, die weltweit an über 100 Points of Presence (PoPs) von Google bereitgestellt werden. Diese Proxys, die als Google Front Ends (GFEs) bezeichnet werden, befinden sich am Rand des Google-Netzwerks in der Nähe der Clients. Multi-Cluster-Ingress erstellt externe Application Load Balancer in der Premium-Stufe. Diese Load-Balancer verwenden globale externe IP-Adressen, die mit anycast beworben werden. Anfragen werden von GFEs und dem Cluster verarbeitet, der dem Client am nächsten ist. Der Internet-Traffic wird zum nächstgelegenen Google-PoP weitergeleitet und verwendet den Google-Backbone, um zu einem GKE-Cluster zu gelangen. Diese Load-Balancing-Konfiguration führt zu einer geringeren Latenz vom Client zum GFE. Sie können auch die Latenz zwischen der Bereitstellung von GKE-Clustern und GFEs reduzieren. Führen Sie dazu die GKE-Cluster in Regionen aus, die Ihren Clients am nächsten sind.

Beim Beenden von HTTP- und HTTPS-Verbindungen am Netzwerkrand kann der Google-Load-Balancer entscheiden, wohin Traffic geleitet werden soll. Dazu bestimmt er die Back-End-Verfügbarkeit, bevor der Traffic in ein Rechenzentrum oder in eine Region gelangt. So wird der Traffic über den effizientesten Pfad vom Client zum Back-End geleitet, wobei auch der Zustand und die Kapazität des Back-Ends berücksichtigt werden.

Multi-Cluster-Ingress ist ein Ingress-Controller, der den externen HTTP(S)-Load-Balancer mithilfe von Netzwerk-Endpunktgruppen (NEGs) programmiert. Wenn Sie eine MultiClusterIngress-Ressource erstellen, stellt GKE Load-Balancer-Ressourcen in Compute Engine bereit und konfiguriert die entsprechenden Pods in den Clustern als Back-Ends. Die NEGs ermöglichen ein dynamisches Tracking der Pod-Endpunkte. Dies gewährleistet, dass dem Google-Load-Balancer immer die richtigen fehlerfreien Back-Ends zur Verfügung stehen.

Grafik: Multi-Cluster-Ingress-Trafficfluss

Wenn Sie Anwendungen in Clustern in GKE bereitstellen, sorgt Multi-Cluster-Ingress dafür, dass der Load-Balancer mit Ereignissen im Cluster synchron ist:

Ein Deployment wird mit den richtigen übereinstimmenden Labels erstellt.
Der Prozess eines Pods wird beendet und die Systemdiagnose schlägt fehl.
Ein Cluster wird aus dem Pool der Back-Ends entfernt.

Multi-Cluster-Ingress aktualisiert den Load-Balancer und hält ihn konsistent mit der Umgebung und dem gewünschten Zustand der Kubernetes-Ressourcen.

Multi-Cluster-Ingress-Architektur

Multi-Cluster-Ingress verwendet einen zentralen Kubernetes API-Server, um Ingress über mehrere Cluster hinweg bereitzustellen. Dieser zentralisierte API-Server wird als Konfigurationscluster bezeichnet. Jeder GKE-Cluster kann als Konfigurationscluster festgelegt werden. Der Konfigurationscluster verwendet zwei benutzerdefinierte Ressourcentypen: MultiClusterIngress und MultiClusterService. Durch das Deployment dieser Ressourcen im Konfigurationscluster stellt der Multi-Cluster-Ingress-Controller Load-Balancer in mehreren Clustern bereit.

Die folgenden Konzepte und Komponenten bilden Multi-Cluster-Ingress:

Multi-Ingress-Controller: eine global verteilte Steuerungsebene, die als Dienst außerhalb Ihrer Cluster ausgeführt wird. Dadurch sind der Lebenszyklus und die Vorgänge des Controllers unabhängig von GKE-Clustern.
Konfigurationscluster: ein ausgewählter GKE-Cluster, der in Google Cloud ausgeführt wird und in dem die Ressourcen MultiClusterIngress und MultiClusterService bereitgestellt werden. Diese Multi-Cluster-Ressourcen werden hier zentral gesteuert. Die Multi-Cluster-Ressourcen befinden sich innerhalb einer einzigen logischen API und sind auch über diese zugänglich, um die Konsistenz der Ressourcen in allen Clustern zu wahren. Der Ingress-Controller überwacht den Konfigurationscluster und gleicht die Load-Balancing-Infrastruktur entsprechend ab.
Mit einer Flotte können Sie GKE-Cluster logisch gruppieren und normalisieren, um die Verwaltung der Infrastruktur zu vereinfachen und die Verwendung von Multi-Cluster-Features wie Multi-Cluster-Ingress zu ermöglichen. Weitere Informationen zu den Vorteilen von Flotten und deren Erstellung finden Sie in der Dokumentation zur Flottenverwaltung. Ein Cluster kann nur Mitglied einer einzelnen Flotte sein.
Mitgliedscluster: In einer Flotte registrierte Cluster werden als Mitgliedscluster bezeichnet. Mitgliedscluster in der Flotte umfassen den gesamten Umfang der Back-Ends, die Multi-Cluster-Ingress kennt. Die Ansicht zur Clusterverwaltung in Google Kubernetes Engine ist eine sichere Konsole zum Prüfen des Status aller registrierten Cluster.

Grafik: Multi-Cluster-Ingress

Deployment-Workflow

Die folgenden Schritte veranschaulichen einen groben Workflow zur Verwendung von Multi-Cluster-Ingress über mehrere Cluster hinweg.

Registrieren Sie GKE-Cluster in einer Flotte im ausgewählten Projekt.
Konfigurieren Sie einen GKE-Cluster als zentralen Konfigurationscluster. Dieser Cluster kann als dedizierte Steuerungsebene dienen oder andere Arbeitslasten ausführen.
Stellen Sie Anwendungen in den GKE-Clustern bereit, in denen sie ausgeführt werden sollen.
Stellen Sie eine oder mehrere MultiClusterService-Ressourcen im Konfigurationscluster mit Label- und Clusterübereinstimmungen bereit, um Cluster, Namespaces und Pods auszuwählen, die als Back-Ends für einen bestimmten Dienst gelten. Dadurch werden in Compute Engine NEGs erstellt, die Dienstendpunkte registrieren und verwalten.
Stellen Sie im Konfigurationscluster eine MultiClusterIngress-Ressource bereit, die auf eine oder mehrere MultiClusterService-Ressourcen als Back-Ends für den Load-Balancer verweist. Dadurch werden die externen Load-Balancer-Ressourcen in Compute Engine bereitgestellt und die Endpunkte über eine einzelne Load-Balancer-VIP in den Clustern verfügbar gemacht.

Ingress-Konzepte

Multi-Cluster-Ingress verwendet einen zentralen Kubernetes API-Server, um Ingress über mehrere Cluster hinweg bereitzustellen. In den folgenden Abschnitten werden das Ressourcenmodell für Multi-Cluster-Ingress, die Bereitstellung von Ingress und die Konzepte zur Verwaltung dieser hochverfügbaren Netzwerksteuerungsebene beschrieben.

MultiClusterService-Ressourcen

Ein MultiClusterService ist eine benutzerdefinierte Ressource, die von Multi-Cluster-Ingress verwendet wird, um gemeinsame Services für Cluster darzustellen. Eine MultiClusterService-Ressource wählt Pods aus, ähnlich wie die Service-Ressource, aber ein MultiClusterService kann auch Labels und Cluster auswählen. Die von MultiClusterService ausgewählten Cluster werden als Mitgliedscluster bezeichnet. Alle bei der Flotte registrierten Cluster sind Mitgliedscluster.

Ein MultiClusterService ist nur im Konfigurationscluster vorhanden und führt kein Routing wie ein ClusterIP-, LoadBalancer- oder NodePort-Service aus. Stattdessen kann der Multi-Cluster-Ingress-Controller auf eine einzelne verteilte Ressource verweisen.

Das folgende Beispielmanifest beschreibt einen MultiClusterService für eine Anwendung namens foo:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80

Dieses Manifest stellt einen Service in allen Mitgliedsclustern mit dem Selektor app: foo bereit. Wenn in diesem Cluster app: foo-Pods vorhanden sind, werden die IP-Adressen dieser Pods als Back-Ends für den MultiClusterIngress hinzugefügt.

Der folgende Service mci-zone1-svc-j726y6p1lilewtu7 ist ein abgeleiteter Service, der in einem der Zielcluster generiert wird. Der Service erstellt eine NEG. Diese verfolgt die Pod-Endpunkte für alle Pods, die der angegebenen Labelauswahl in diesem Cluster entsprechen. In jedem Zielcluster ist für jeden MultiClusterService ein abgeleiteter Service und eine abgeleitete NEG vorhanden, sofern keine Clusterauswahl verwendet wurde. Wenn in einem Zielcluster keine übereinstimmenden Pods vorhanden sind, sind der Service und die NEG leer. Die abgeleiteten Services werden vollständig vom MultiClusterService und nicht direkt von den Nutzern verwaltet.

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"8080":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"8080":"k8s1-a6b112b6-default-mci-zone1-svc-j726y6p1lilewt-808-e86163b5"},"zones":["us-central1-a"]}'
    networking.gke.io/multiclusterservice-parent: '{"Namespace":"default","Name":"zone1"}'
  name: mci-zone1-svc-j726y6p1lilewtu7
  namespace: blue
spec:
  selector:
    app: foo
  ports:
  - name: web
    protocol: TCP
    port: 80
    targetPort: 80

Hier einige Hinweise zum abgeleiteten Service:

Die zugehörige Funktion ist eine logische Gruppierung von Endpunkten als Back-Ends für Multi-Cluster-Ingress.
Er verwaltet den Lebenszyklus der NEG für einen bestimmten Cluster und eine bestimmte Anwendung.
Er wird als monitorloser Service erstellt. Nur die Felder Selector und Ports werden vom MultiClusterService an den abgeleiteten Service übertragen.
Der Ingress-Controller verwaltet seinen Lebenszyklus.

MultiClusterIngress-Ressource

Eine MultiClusterIngress-Ressource verhält sich in vielerlei Hinsicht genauso wie die Ingress-Kernressource. Beide haben die gleiche Spezifikation für die Definition von Hosts, Pfaden, Protokollbeendigungen und Back-Ends.

Das folgende Manifest beschreibt ein MultiClusterIngress, das Traffic an die Back-Ends foo und bar leitet, je nach HTTP-Host-Header:

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: foobar-ingress
  namespace: blue
spec:
  template:
    spec:
      backend:
        serviceName: default-backend
        servicePort: 80
      rules:
      - host: foo.example.com
        backend:
          serviceName: foo
          servicePort: 80
      - host: bar.example.com
        backend:
          serviceName: bar
          servicePort: 80

Diese MultiClusterIngress-Ressource ordnet Traffic der virtuellen IP-Adresse unter foo.example.com und bar.example.com zu. Dazu wird dieser Traffic an die MultiClusterService-Ressourcen foo und bar gesendet. Dieser MultiClusterIngress hat ein Standard-Backend, das einen Abgleich für allen anderen Traffic durchführt und diesen Traffic an den MultiClusterService des Standard-Backends sendet.

Das folgende Diagramm zeigt, wie Traffic von einem Ingress zu einem Cluster fließt:

Im Diagramm gibt es zwei Cluster: gke-us und gke-eu. Der Traffic fließt von foo.example.com zu den Pods mit dem Label app:foo in beiden Clustern. In bar.example.com fließt der Traffic zu den Pods mit dem Label app:bar in beiden Clustern.

Ingress-Ressourcen in Clustern

Der Konfigurationscluster ist der einzige Cluster mit den Ressourcen MultiClusterIngress und MultiClusterService. Für jeden Zielcluster mit Pods, die mit der MultiClusterService-Labelauswahl übereinstimmen, wird auch ein entsprechender abgeleiteter Service geplant. Wird ein Cluster von einem MultiClusterService nicht explizit ausgewählt, wird in diesem Cluster auch kein entsprechender abgeleiteter Service erstellt.

Namespace-Gleichheit

Namespace-Gleichheit ist eine Eigenschaft von Kubernetes-Clustern, bei der sich ein Namespace über mehrere Cluster erstreckt und als derselbe Namespace betrachtet wird.

Im folgenden Diagramm ist der Namespace blue in den GKE-Clustern gke-cfg, gke-eu und gke-us vorhanden. Namespace-Gleichheit betrachtet den Namespace blue in allen Clustern als identisch. Das bedeutet, dass ein bestimmter Nutzer in jedem Cluster die gleichen Berechtigungen für Ressourcen im Namespace blue hat. Namespace-Gleichheit bedeutet auch, dass Service-Ressourcen mit demselben Namen in mehreren Clustern in Namespace blue als derselbe Service betrachtet werden.

Das Gateway behandelt den Service als einzelnen Pool von Endpunkten in den drei Clustern. Da Routen und MultiClusterIngress-Ressourcen nur an Services innerhalb desselben Namespace weiterleiten können, bietet dies eine konsistente Mehrmandantenfähigkeit für die clusterübergreifende Konfiguration der Flotte. Flotten bieten ein hohes Maß an Portabilität, da Ressourcen ohne Änderungen an der Konfiguration in Clustern bereitgestellt oder verschoben werden können. Die Bereitstellung im selben Fleet-Namespace bietet Konsistenz über alle Cluster hinweg.

Beachten Sie folgende Designprinzipien für die Namespace-Gleichheit:

Namespaces für unterschiedliche Zwecke sollten in Clustern nicht denselben Namen haben.
Namespaces sollten entweder explizit per Namespace-Zuweisung oder implizit über Out-of-Band-Richtlinien für Teams und Cluster innerhalb einer Flotte reserviert werden.
Namespaces für denselben Zweck in Clustern sollten denselben Namen haben.
Die Nutzerberechtigungen für Namespaces in Clustern sollten streng kontrolliert werden, um nicht autorisierten Zugriff zu verhindern.
Für die normale Anwendungsbereitstellung sollten Sie nie den Standard-Namespace oder generische Namespaces wie "prod" oder "dev" verwenden. Dies könnte leicht dazu führen, dass Nutzer versehentlich Ressourcen im Standard-Namespace bereitstellen und gegen die Segmentierungsprinzipien für Namespaces verstoßen.
Derselbe Namespace sollte in allen Clustern erstellt werden, in denen ein bestimmtes Team oder eine Gruppe von Nutzern Ressourcen bereitstellen muss.

Clusterdesign konfigurieren

Der Konfigurationscluster von Multi-Cluster-Ingress ist ein einzelner GKE-Cluster, der die MultiClusterIngress- und MultiClusterService-Ressourcen hostet und als zentraler Kontrollpunkt für Ingress in der gesamten Flotte der GKE-Zielcluster fungiert. Sie wählen den Konfigurationscluster aus, wenn Sie Multi-Cluster-Ingress aktivieren. Sie können einen beliebigen GKE-Cluster als Konfigurationscluster auswählen und den Konfigurationscluster jederzeit ändern.

Verfügbarkeit des Konfigurationsclusters

Da der Konfigurationscluster ein einzelner Zugriffspunkt ist, können Multi-Cluster-Ingress-Ressourcen nicht erstellt oder aktualisiert werden, wenn die Config Cluster API nicht verfügbar ist. Load-Balancer und von diesen bereitgestellter Traffic sind von einem Ausfall des Konfigurationsclusters nicht betroffen. Änderungen an MultiClusterIngress- und MultiClusterService-Ressourcen werden jedoch erst dann vom Controller abgeglichen, wenn sie wieder verfügbar sind.

Beachten Sie folgende Designprinzipien für Konfigurationscluster:

Der Konfigurationscluster sollte hochverfügbar sein. Regionale Cluster werden gegenüber zonalen Clustern bevorzugt.
Zum Aktivieren von Multi-Cluster-Ingress muss der Konfigurationscluster kein dedizierter Cluster sein. Der Konfigurationscluster kann administrative und sogar Anwendungsarbeitslasten hosten. Es sollte jedoch darauf geachtet werden, dass gehostete Anwendungen die Verfügbarkeit des Konfigurationscluster-API-Servers nicht beeinträchtigen. Der Konfigurationscluster kann ein Zielcluster sein, der Backends für MultiClusterService-Ressourcen hostet. Wenn zusätzliche Sicherheitsmaßnahmen erforderlich sind, kann der Konfigurationscluster auch über die Clusterauswahl als Backend ausgeschlossen werden.
Konfigurationscluster sollten sämtliche Namespaces haben, die von Back-Ends der Zielcluster verwendet werden. Eine MultiClusterService-Ressource kann in verschiedenen Clustern nur auf Pods im selben Namespace verweisen, sodass der Namespace im Konfigurationscluster vorhanden sein muss.
Nutzer, die Ingress in mehreren Clustern bereitstellen, benötigen Zugriff auf den Konfigurationscluster, um MultiClusterIngress- und MultiClusterService-Ressourcen bereitstellen zu können. Nutzer sollten jedoch nur Zugriff auf Namespaces erhalten, für die sie eine Berechtigung haben.

Konfigurationscluster auswählen und migrieren

Sie müssen den Konfigurationscluster auswählen, wenn Sie Multi-Cluster-Ingress aktivieren. Jeder Mitgliedscluster in einer Flotte kann als Konfigurationscluster ausgewählt werden. Sie können den Konfigurationscluster jederzeit aktualisieren. Achten Sie jedoch darauf, dass dies keine Unterbrechungen verursacht. Der Ingress-Controller gleicht alle Ressourcen im Konfigurationscluster ab. Soll ein anderer Cluster als Konfigurationscluster verwendet werden, müssen die MultiClusterIngress- und MultiClusterService-Ressourcen in beiden Clustern identisch sein. Sind die Ressourcen nicht identisch, können die Compute Engine-Load-Balancer nach der Aktualisierung des Konfigurationsclusters aktualisiert oder gelöscht werden.

Im folgenden Diagramm wird dargestellt, wie ein zentralisiertes CI/CD-System MultiClusterIngress- und MultiClusterService-Ressourcen für den Konfigurationscluster (gke-us) und einen Sicherungscluster (gke-eu) jederzeit auf den GKE-API-Server anwendet, sodass die Ressourcen in den beiden Clustern identisch sind. Sie können den Konfigurationscluster in Notfällen oder für geplante Ausfallzeiten jederzeit ohne Auswirkungen ändern, da die MultiClusterIngress- und MultiClusterService-Ressourcen identisch sind.

Clusterauswahl

MultiClusterService-Ressourcen können clusterübergreifend ausgewählt werden. Standardmäßig plant der Controller einen abgeleiteten Service auf jedem Zielcluster. Wenn Sie nicht für jeden Zielcluster einen abgeleiteten Service benötigen, können Sie eine Liste der Cluster mit dem Feld spec.clusters im Manifest MultiClusterService definieren.

Sie können eine Liste der Cluster definieren, wenn Folgendes erforderlich ist:

Isolieren des Konfigurationsclusters, um zu verhindern, dass MultiClusterService-Ressourcen im Konfigurationscluster ausgewählt werden.
Steuern des Traffic zwischen Clustern für die Anwendungsmigration.
Weiterleitung an Anwendungs-Back-Ends, die nur in einem Teil der Cluster vorhanden sind.
Verwenden einer einzelnen virtuellen HTTP(S)-IP-Adresse für das Routing zu Back-Ends, die sich in verschiedenen Clustern befinden.

Mitgliedscluster in derselben Flotte und in derselben Region müssen eindeutige Namen haben, damit keine Namenskonflikte auftreten.

Informationen zum Konfigurieren der Clusterauswahl finden Sie unter Multi-Cluster-Ingress einrichten.

Das folgende Manifest beschreibt einen MultiClusterService mit einem clusters-Feld, das auf europe-west1-c/gke-eu und asia-northeast1-a/gke-asia verweist:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80
  clusters:
  - link: "europe-west1-c/gke-eu"
  - link: "asia-northeast1-a/gke-asia-1"

Dieses Manifest gibt an, dass Pods mit zueinander passenden Labels in den Clustern gke-asia und gke-eu als Back-Ends für den MultiClusterIngress hinzugefügt werden können. Alle anderen Cluster werden ausgeschlossen, auch wenn sie Pods mit dem app: foo-Label haben.

Das folgende Diagramm zeigt ein Beispiel für eine MultiClusterService-Konfiguration mit dem vorherigen Manifest:

Im Diagramm gibt es drei Cluster: gke-eu, gke-asia-1 und gke-asia-2. Der Cluster gke-asia-2 ist nicht als Backend enthalten, obwohl Pods mit übereinstimmenden Labels vorhanden sind, da der Cluster nicht in der Liste spec.clusters des Manifests enthalten ist. Der Cluster empfängt keinen Traffic für Wartungen oder andere Vorgänge.