Multi-Cluster-Ingress

Multi-Cluster Ingress (MCI) ist ein in der Cloud gehosteter Multi-Cluster-Ingress-Controller für Anthos GKE-Cluster. 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 müssen Sie Multi-Cluster-Ingress einrichten und dann Ingress in mehreren Clustern bereitstellen.

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 mehrerer Clustern 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

Preise und Testversionen

Für Multi-Cluster-Ingress ist die Anthos on Google Cloud-Lizenzierung für alle Cluster erforderlich, die als MCI-Back-Ends teilnehmen. Jeder registrierte Cluster wird entsprechend seiner vCPU-Kapazität abgerechnet.

MCI kann auf „Pay-As-You-Go”-Basis oder mit einer Anthos-Abo-Lizenz verwendet werden. Die Standardpreise für den Compute Engine-Load-Balancer gelten für eingehenden Traffic und Weiterleitungsregeln, die über Ingress erstellt werden.

Wenn Sie ein neuer Anthos-Kunde sind, können Sie GKE in Google Cloud bis zu einem Nutzungswert von 900 $ oder für maximal 30 Tage kostenlos testen, je nachdem, was zuerst eintritt. Während des Testzeitraums werden Ihnen die anwendbaren Gebühren berechnet, die Ihnen bis zu einem Betrag von 900 $ direkt wieder gutgeschrieben werden. Rufen Sie im Cloud Marketplace die Anthos-Seite auf und klicken Sie auf Jetzt testen, um sich zu registrieren.

Funktionsweise von Multi-Cluster-Ingress

Multi-Cluster-Ingress basiert auf der Architektur des externen HTTP(S)-Load-Balancing. HTTP(S)-Load-Balancing ist ein global verteilter Load-Balancer mit Proxys, die weltweit an mehr als 100 Points of Presence (PoPs) von Google bereitgestellt werden. Diese Proxys befinden sich am Rand des Google-Netzwerks und werden in der Nähe der Clients positioniert. Die Load-Balancer-VIPs werden als Anycast-IP-Adressen angeboten. Anfragen von Clients werden per Cold-Potato-Routing zu Google-PoPs geleitet. Das bedeutet, dass der Internet-Traffic so schnell wie möglich zum nächstgelegenen PoP und zum Google-Backbone geleitet wird.

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 Anthos-Ingress-Controller Load-Balancer in mehreren Clustern bereit.

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

  • Anthos-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.

  • Environ: eine Domain, die Cluster und Infrastruktur gruppiert, Ressourcen verwaltet und eine konsistente Richtlinie für sie aufrechterhält. MCI steuert mit dem Environ-Konzept, wie Ingress auf verschiedene Cluster angewendet wird. Cluster, die Sie in einem Environ registrieren, werden für MCI sichtbar, sodass sie als Back-Ends verwendet werden können.

  • Mitgliedscluster: In einem Environ registrierte Cluster werden als Mitgliedscluster bezeichnet. Mitgliedscluster im Environ sind alle Back-Ends, die MCI 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-Bogen

Deployment-Workflow

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

  1. Registrieren Sie GKE-Cluster als Mitgliedscluster.

  2. Konfigurieren Sie einen GKE-Cluster als zentralen Konfigurationscluster. Dieser Cluster kann als dedizierte Steuerungsebene dienen oder andere Arbeitslasten ausführen.

  3. Stellen Sie Anwendungen in den GKE-Clustern bereit, in denen sie ausgeführt werden sollen.

  4. 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.

  5. 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 (MCS) ist eine benutzerdefinierte Ressource, die von Multi-Cluster-Ingress verwendet wird. Dies ist eine logische Darstellung eines Dienstes über mehrere Cluster hinweg. Ein MCS ähnelt dem Hauptservicetyp, unterscheidet sich aber auch erheblich von diesem. Ein MCS ist nur im Konfigurationscluster vorhanden und generiert abgeleitete Services in den Zielclustern. Ein MCS führt im Unterschied zu Services wie ClusterIP, LoadBalancer oder NodePort kein Routing durch. Er ermöglicht lediglich, dass der MCI auf eine einzelne verteilte Ressource verweist. Das nachstehende Beispiel zeigt einen einfachen MCS für die Anwendung foo:

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

Ebenso wie ein Service ist ein MCS ein Selektor für Pods, kann aber auch Labels und Cluster auswählen. Die vom MCS ausgewählten Cluster werden als Mitgliedscluster bezeichnet und sind alle im Environ registriert. Dieser MCS stellt mit dem Selektor app: foo einen abgeleiteten Service in allen Mitgliedsclustern bereit. Wenn in diesem Cluster app: foo-Pods vorhanden sind, werden die IP-Adressen dieser Pods als Back-Ends für das MCI hinzugefügt.

Der folgende mci-zone1-svc-j726y6p1lilewtu7 ist ein abgeleiteter Service, den der MCS in einem der Zielcluster generiert hat. 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 MCS 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 MCS 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-frontend
  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 von der MCS-Spezifikation an die abgeleitete Dienstspezifikation übertragen.
  • Der Anthos Ingress-Controller verwaltet seinen Lebenszyklus.

MultiClusterIngress-Ressource

Eine MultiClusterIngress-Ressource (MCI-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. Dies ist ein einfaches Beispiel für eine MCI-Ressource, die auf der Grundlage der HTTP-Host-Header Traffic zu den Back-Ends "foo" und "bar" leitet.

apiVersion: networking.gke.io/v1alpha1
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

Beachten Sie, dass dieses MCI Traffic zur VIP auf foo.example.com und bar.example.com abgleicht, indem es diesen Traffic an die MCS-Ressourcen (MultiClusterService) namens "foo" und "bar" sendet. Dieses MCI hat ein Standard-Back-End, das einen Abgleich für allen anderen Traffic durchführt und diesen Traffic an den MCS des Standard-Back-Ends sendet.

Host-Header-Abgleich

Ingress-Ressourcen in Clustern

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

Diagramm eines Ingress-Ressourcenmodells

Namespace-Gleichheit

Registrierte GKE-Cluster werden Mitglied eines Environ.

Eine Eigenschaft von Environs ist die sogenannte Namespace-Gleichheit. Dabei wird davon ausgegangen, dass Ressourcen mit identischen Namen und demselben Namespace in Clustern als Instanzen derselben Ressource betrachtet werden. In der Praxis bedeutet dies, dass Pods im ns1-Namespace mit den Labeln app: foo über verschiedene Cluster hinweg aus der Perspektive von Multi-Cluster-Ingress alle als Teil desselben Pools von Anwendungs-Back-Dnds betrachtet werden.

Dies wirkt sich auch darauf aus, wie verschiedene Entwicklungsteams in einer Gruppe von Clustern arbeiten. Unterschiedliche Teams können weiterhin dieselbe Clusterauswahl nutzen, indem sie Namespaces verwenden, um Arbeitslasten auch über Clustergrenzen hinweg zu segmentieren. Es ist jedoch wichtig, dass jedes Team seine jeweiligen Namespaces explizit oder implizit auf allen Clustern im Environ reserviert.

Im folgenden Beispiel hat das blaue Team Zugriff auf Deployments in allen blauen Namespaces innerhalb der Cluster. Blau gilt in jedem Cluster als derselbe Namespace. Der blaue Namespace ist auch im Konfigurationscluster für Multi-Cluster-Ingress vorhanden. MultiClusterService-Ressourcen, die dort vom blauen Team bereitgestellt werden, können nur Pods auswählen, die auch im blauen Namespace in anderen Clustern vorhanden sind. MCI- und MCS-Ressourcen haben keine Sicht und keinen Zugriff auf Namespaces in verschiedenen Clustern, sodass die Gewichtung und "Gleichheit" der Ressourcen in allen Clustern erhalten bleibt.

Diagramm zur Veranschaulichung der Namespace-Gleichheit

Die Namespace-Gleichheit wirkt sich wiederum auf das Design aus. Beachten Sie die folgenden Prinzipien für eine korrekte Verwendung:

  • 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 eines Environ 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.
  • Der Standard-Namespace oder generische Namespaces wie "prod" oder "dev" sollten nicht für das reguläre Deployment von Anwendungen verwendet werden. 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 MCI- und MCS-Ressourcen hostet und als zentraler Kontrollpunkt für Ingress in allen GKE-Zielclustern 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 Konfigurationscluster-API nicht verfügbar ist. Load-Balancer und der von diesen bereitgestellte Traffic sind von einem Ausfall des Konfigurationsclusters nicht betroffen. Änderungen an MCI und an MCS-Ressourcen werden jedoch erst dann vom Controller abgeglichen, wenn sie wieder verfügbar sind.

Im Folgenden einige Designprinzipien für die Verwendung und Verwaltung des Konfigurationsclusters:

  • Der Konfigurationscluster sollte hochverfügbar sein. Regionale Cluster werden gegenüber zonalen Clustern bevorzugt.
  • Der Konfigurationscluster muss kein dedizierter Cluster für Multi-Cluster-Ingress 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 Back-Ends für MCIs hostet. Wenn zusätzliche Sicherheitsmaßnahmen erforderlich sind, kann der Konfigurationscluster auch über die Clusterauswahl als MCI-Back-End ausgeschlossen werden.
  • Konfigurationscluster sollten sämtliche Namespaces haben, die von Back-Ends der Zielcluster verwendet werden. Ein MCS 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 MCI- und MCS-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 einem Environ kann als Konfigurationscluster ausgewählt werden. Sie können den Konfigurationscluster jederzeit aktualisieren. Achten Sie jedoch darauf, dass dies keine Unterbrechungen verursacht. Der Anthos-Ingress-Controller gleicht alle MCI- und MCS-Ressourcen im Konfigurationscluster ab. Soll ein anderer Cluster als Konfigurationscluster verwendet werden, müssen die MCI- und MCS-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 MCI- und MCS-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. Wenn Sie den Konfigurationscluster in Notfällen oder für geplante Ausfallzeiten ändern müssen, kann der Konfigurationscluster ohne Auswirkungen aktualisiert werden, da die MCI- und MCS-Ressourcen identisch sind.

Zentrales CI/CD-System, das MCI- und MCS-Ressourcen anwendet

Clusterauswahl

MCS-Ressourcen können explizit Cluster auswählen. Standardmäßig plant ein MCS abgeleitete Services für jeden Zielcluster. Bei der Clusterauswahl wird eine explizite Liste von Clustern für einen bestimmten MCS definiert, bei dem abgeleitete Services geplant und alle anderen Zielcluster ignoriert werden sollen. Weitere Informationen zum Konfigurieren der Clusterauswahl finden Sie unter Multi-Cluster-Ingress einrichten.

Es gibt viele Anwendungsfälle, in denen die Anwendung von Ingress-Regeln auf bestimmte Cluster nützlich ist:

  • Isolieren des Konfigurationsclusters, um zu verhindern, dass MCS-Ressourcen über sie ausgewählt werden
  • Steuern des Traffics zwischen Clustern für eine Blau/Grün-Anwendungsmigration
  • Routing zu Anwendungs-Back-Ends, die nur in einem Teil der Cluster vorhanden sind
  • Verwenden einer einzelnen L7-VIP für das Host-/Pfad-Routing zu Back-Ends, die sich in verschiedenen Clustern befinden

Die Clusterauswahl erfolgt im MCS über das Feld clusters. Cluster werden mit <region | zone>/<name> explizit referenziert. Mitgliedscluster im selben Environ und in derselben Region sollten eindeutige Namen haben, damit keine Namenskonflikte auftreten.

Im folgenden Beispiel hat der MCS foo ein Feld clusters, das auf europe-west1-c/gke-eu und asia-northeast1-a/gke-asia verweist. Daher können Pods mit den entsprechenden Labels in den Clustern "gke-asia" und "gke-eu" als Back-Ends für ein bestimmtes MCI aufgenommen werden. Dadurch wird der gke-us-Cluster aus Ingress ausgeschlossen, auch wenn er Pods mit dem Label app: foo enthält. Dies kann nützlich sein, um neue Cluster einzurichten oder zu migrieren und den Traffic unabhängig vom Pod-Deployment zu steuern.

apiVersion: networking.gke.io/v1beta1
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"

Das folgende Diagramm zeigt die drei Cluster "gke-eu", "gke-asia-1" und "gke-asia-2". "gke-asia-2" wird als Back-End ausgeschlossen, obwohl Pods mit übereinstimmenden Labels enthalten sind. Auf diese Weise kann der Cluster zu Wartungszwecken oder für andere Vorgänge vom Traffic-Empfang ausgeschlossen werden. Wenn das Feld "clusters" in einem MCS weggelassen wird, werden alle Mitgliedercluster implizit ausgewählt.

Diagramm, das ein ausgeschlossenes Back-End zeigt

Nächste Schritte