Multi-Cluster-Dienste konfigurieren

Auf dieser Seite wird gezeigt, wie Sie Multi-Cluster-Dienste (Multi-Cluster Services, MCS) aktivieren und anwenden. Weitere Informationen zur Funktionsweise von MCS und zu den damit verbundenen Vorteilen finden Sie unter Multi-Cluster-Dienste.

Das MCS-Feature von Google Kubernetes Engine (GKE) erweitert die Reichweite des Kubernetes-Dienstes über die Clustergrenze hinaus und ermöglicht es, Dienste in mehreren GKE-Clustern zu ermitteln und aufzurufen. Sie können damit eine Teilmenge der vorhandenen Dienste oder der neuen Dienste exportieren.

Wenn Sie einen Dienst mit MCS exportieren, ist dieser Dienst dann für alle Cluster in Ihrer Flotte verfügbar.

Auf dieser Seite wird beschrieben, wie Sie MCS mit einem einzelnen Projekt konfigurieren. Folgen Sie für die Einrichtung einer freigegebene VPC mit mehreren Projekten der Anleitung unter Multi-Cluster-Dienste mit freigegebener VPC einrichten.

Von MCS verwalteteGoogle Cloud -Ressourcen

MCS verwaltet die folgenden Komponenten von Google Cloud:

  • Cloud DNS: MCS konfiguriert Cloud DNS-Zonen und -Einträge für jeden exportierten Dienst in Ihren Flottenclustern. Dadurch können Sie eine Verbindung zu Diensten herstellen, die in anderen Clustern ausgeführt werden. Diese Zonen und Einträge werden anhand der Dienste erstellt, gelesen, aktualisiert und gelöscht, die Sie für einen clusterübergreifenden Export ausgewählt haben.

  • Firewallregeln: MCS konfiguriert Firewallregeln, mit denen Pods innerhalb von Flotten clusterübergreifend miteinander kommunizieren können. Firewallregeln werden anhand der Cluster erstellt, gelesen, aktualisiert und gelöscht, die Sie in Ihre Flotte aufnehmen. Diese Regeln entsprechen den Regeln, die GKE für die Kommunikation zwischen Pods in einem GKE-Cluster erstellt.

  • Cloud Service Mesh: MCS verwendet Cloud Service Mesh als Steuerungsebene, um Endpunkte und deren Status clusterübergreifend zu verfolgen.

Voraussetzungen

Für MCS gilt Folgendes:

  • MCS unterstützt nur den Export von Diensten aus VPC-nativen GKE-Clustern in Google Cloud. Weitere Informationen finden Sie unter VPC-nativen Cluster erstellen. Sie können keine VPC-nativen GKE-Standardcluster verwenden.

  • Konnektivität ist zwischen Clustern möglich, die im selben VPC-Netzwerk, in Peering- oder freigegebene VPC-Netzwerken ausgeführt werden. Wenn sich Cluster in separaten, nicht verbundenen Netzwerken befinden, werden Aufrufe an externe Dienste blockiert. Wir empfehlen, MCS in Projekten zu aktivieren, in denen sich die Cluster im selben VPC-Netzwerk befinden.

    Wenn Sie MCS in einer projektübergreifenden Flotte mit einer freigegebene VPC einrichten möchten, folgen Sie der Anleitung unter Multi-Cluster-Dienste mit freigegebener VPC einrichten.

  • Eine Flotte kann sich über mehrere Google Cloud -Projekte und VPC-Netzwerke erstrecken. Ein einzelner Multi-Cluster-Dienst muss jedoch aus einem einzelnen Projekt und einem einzelnen VPC-Netzwerk exportiert werden.

  • MCS wird von Netzwerkrichtlinien nicht unterstützt.

  • Bei Clustern muss das Add-on HttpLoadBalancing aktiviert sein. Prüfen Sie, ob das HttpLoadBalancing-Add-on aktiviert ist. Das HttpLoadBalancing-Add-on ist standardmäßig aktiviert und sollte nicht deaktiviert werden.

Preise

Multi-Cluster-Dienste sind Teil der GKE-Clusterverwaltungsgebühr und verursachen keine zusätzlichen Nutzungskosten. Sie müssen die Traffic Director API aktivieren. Für MCS fallen jedoch keine Gebühren für Cloud Service Mesh-Endpunkte an.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  1. Installieren Sie das Google Cloud SDK.

  2. Aktivieren Sie die Google Kubernetes Engine API:

    Google Kubernetes Engine API aktivieren

  3. Verbinden Sie Ihre VPC-Netzwerke mit VPC-Netzwerk-Peering, Cloud Interconnect oder Cloud VPN.

  4. Aktivieren Sie die Flotten-API (Hub) sowie die MCS, Resource Manager, Cloud Service Mesh und Cloud DNS APIs:

    gcloud services enable \
    multiclusterservicediscovery.googleapis.com \
    gkehub.googleapis.com \
    cloudresourcemanager.googleapis.com \
    trafficdirector.googleapis.com \
    dns.googleapis.com \
    --project=PROJECT_ID

    Ersetzen Sie PROJECT_ID durch die Projekt-ID des Projekts, in dem Sie Ihre Cluster für eine Flotte registrieren möchten.

MCS in Ihrem Projekt aktivieren

MCS erfordert, dass teilnehmende GKE-Cluster in derselben Flotte registriert sind. Sobald das MCS-Feature für eine Flotte aktiviert ist, können alle Cluster Services zwischen Clustern in der Flotte exportieren.

MCS im GKE-Cluster aktivieren

  1. Aktivieren Sie das MCS-Feature für die Flotte Ihres Projekts:

    gcloud container fleet multi-cluster-services enable \
    --project PROJECT_ID

    Ersetzen Sie PROJECT_ID durch die Projekt-ID des Projekts, in dem Sie Ihre Cluster für eine Flotte registrieren möchten. Dies ist Ihr Flottenhostprojekt.

    Durch Aktivieren von Multi-Cluster-Diensten im Flotten-Hostprojekt wird das Dienstkonto service-PROJECT_NUMBER@gcp-sa-mcsd.iam.gserviceaccount.com erstellt bzw. sichergestellt, dass es existiert.

  2. Registrieren Sie die GKE-Cluster in einer Flotte. Wir empfehlen dringend, den Cluster bei aktivierter Workload Identity-Föderation für GKE zu registrieren. Wenn Sie die Workload Identity-Föderation für GKE nicht aktivieren, müssen Sie den Cluster zur Authentifizierung bei einem Google Cloud Dienstkonto registrieren und die zusätzlichen Schritte unter Dienstkonten authentifizieren ausführen.

    Führen Sie den folgenden Befehl aus, um Ihren Cluster bei der Identitätsföderation von Arbeitslasten für GKE zu registrieren:

    gcloud container fleet memberships register MEMBERSHIP_NAME \
   --gke-cluster CLUSTER_LOCATION/CLUSTER_NAME \
   --enable-workload-identity \
   --project PROJECT_ID

    Ersetzen Sie Folgendes:

    • MEMBERSHIP_NAME: Der Mitgliedschaftsname, den Sie auswählen, um den Cluster in der Flotte eindeutig darzustellen. Normalerweise ist der Name der Flotte für einen Cluster der Name des Clusters. Sie müssen jedoch möglicherweise einen neuen Namen angeben, wenn ein anderer Cluster mit dem ursprünglichen Namen bereits in der Flotte vorhanden ist.
    • CLUSTER_LOCATION: Die Zone oder Region, in der sich der Cluster befindet.
    • CLUSTER_NAME ist der Name des Clusters.

  3. Erteilen Sie die erforderlichen IAM-Berechtigungen (Identity and Access Management) für den MCS-Importeur:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/gke-mcs/sa/gke-mcs-importer" \
    --role "roles/compute.networkViewer"

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die Projekt-ID des Hostprojekts der Flotte.
    • PROJECT_NUMBER: Die Projektnummer des Flotten-Hostprojekts.

  4. Jeder Cluster der Flotte muss einen Namespace haben, um darin Dienste freizugeben. Erstellen Sie bei Bedarf einen Namespace mit dem folgenden Befehl:

    kubectl create ns NAMESPACE

    Ersetzen Sie NAMESPACE durch einen Namen für den Namespace.

  5. Prüfen Sie mit dem folgenden Befehl, ob MCS aktiviert sind:

    gcloud container fleet multi-cluster-services describe \
    --project PROJECT_ID

    Die Ausgabe sieht etwa so aus:

    createTime: '2021-08-10T13:05:23.512044937Z'
membershipStates:
  projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
    state:
      code: OK
      description: Firewall successfully updated
      updateTime: '2021-08-10T13:14:45.173444870Z'
name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
resourceState:
  state: ACTIVE
spec: {}

    Wenn der Wert von state nicht ACTIVE ist, lesen Sie den Abschnitt Fehlerbehebung.

Dienstkonten authentifizieren

Wenn Sie Ihre GKE-Cluster über ein Dienstkonto für eine Flotte registriert haben, müssen Sie zur Authentifizierung des Dienstkontos zusätzliche Schritte ausführen. MCS stellt eine Komponente namens gke-mcs-importer bereit. Diese Komponente erhält Endpunktaktualisierungen von Cloud Service Mesh. Im Rahmen der Aktivierung von MCS müssen Sie deshalb Ihrem Dienstkonto die Berechtigung zum Lesen von Informationen von Cloud Service Mesh erteilen.

Wenn Sie ein Dienstkonto verwenden, können Sie das Compute Engine-Standarddienstkonto oder Ihr eigenes Knotendienstkonto nutzen:

  • Wenn Sie ein Compute Engine-Standarddienstkonto verwenden, gehen Sie so vor:

    1. Aktivieren Sie die folgenden Bereiche:

      • https://www.googleapis.com/auth/compute.readonly
      • https://www.googleapis.com/auth/cloud-platform

      Weitere Informationen zum Aktivieren von Bereichen finden Sie unter Dienstkonto und Zugriffsbereiche für eine Instanz ändern.

    2. Weisen Sie dem Dienstkonto die Rolle roles/compute.networkViewer für das Projekt zu. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Einzelne Rolle zuweisen.

  • Wenn Sie ein eigenes Knotendienstkonto verwenden, weisen Sie Ihrem Dienstkonto die Rolle roles/compute.networkViewer für das Projekt zu. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Einzelne Rolle zuweisen.

MCS verwenden

In den folgenden Abschnitten wird gezeigt, wie Sie MCS anwenden. MCS verwendet die Kubernetes Multi-Cluster Services API.

Dienst für den Export registrieren

Führen Sie die folgenden Schritte aus, um einen Dienst für den Export in andere Cluster innerhalb Ihrer Flotte zu registrieren:

  1. Erstellen Sie ein ServiceExport-Objekt mit dem Namen export.yaml:

    # export.yaml
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
 namespace: NAMESPACE
 name: SERVICE_EXPORT_NAME

    Ersetzen Sie Folgendes:

    • NAMESPACE ist der Namespace des ServiceExport-Objekts. Dieser Namespace muss mit dem Namespace des Dienstes übereinstimmen, den Sie exportieren.
    • SERVICE_EXPORT_NAME ist der Name eines Dienstes in Ihrem Cluster, den Sie in andere Cluster in Ihrer Flotte exportieren möchten.

  2. Erstellen Sie mit dem folgenden Befehl die Ressource ServiceExport:

    kubectl apply -f export.yaml

Der erste Export Ihres Dienstes dauert ungefähr fünf Minuten, in denen er mit den Clustern synchronisiert wird, die in Ihrer Flotte registriert sind. Nachdem ein Dienst exportiert wurde, werden nachfolgende Synchronisierungen von Endpunkten sofort ausgeführt.

Sie können denselben Service aus mehreren Clustern exportieren, um einen einzelnen hochverfügbaren Multi-Cluster-Dienstendpunkt mit Traffic-Verteilung über Cluster hinweg zu erstellen. Stellen Sie vor dem Export von Services mit demselben Namen und Namespace sicher, dass sie auf diese Weise gruppiert werden sollen. Wir empfehlen, Services in die Namespaces default und kube-system nicht zu exportieren, da es sonst mit hoher Wahrscheinlichkeit unbeabsichtigte Namenskonflikte und die daraus resultierende unbeabsichtigte Gruppierung gibt. Wenn Sie mehr als fünf Services mit demselben Namen und Namespace exportieren, ist die Traffic-Verteilung auf importierte Services möglicherweise auf fünf exportierte Services beschränkt.

Clusterübergreifende Dienste nutzen

MCS unterstützt nur ClusterSetIP und monitorlose Dienste. Es sind nur DNS-A-Einträge verfügbar.

Nachdem Sie ein ServiceExport-Objekt erstellt haben, wird der folgende Domainname von einem beliebigen Pod in einem beliebigen Flotten-Cluster zu Ihrem exportierten Dienst aufgelöst:

 SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

Die Ausgabe enthält die folgenden Werte:

  • SERVICE_EXPORT_NAME und NAMESPACE: Die Werte, die Sie im Objekt ServiceExport definieren.

Für ClusterSetIP-Dienste wird die Domain nach ClusterSetIP aufgelöst. Sie finden diesen Wert im ServiceImport-Objekt in einem Cluster in dem Namespace, in dem das ServiceExport-Objekt erstellt wurde. Das ServiceImport-Objekt wird automatisch erstellt.

Beispiel:

kind: ServiceImport
apiVersion: net.gke.io/v1
metadata:
 namespace: EXPORTED-SERVICE-NAMESPACE
 name: SERVICE-EXPORT-TARGET
status:
 ports:
 - name: https
   port: 443
   protocol: TCP
   targetPort: 443
 ips: CLUSTER_SET_IP

MCS erstellt ein Endpoints-Objekt im Rahmen des Imports eines Service in einen Cluster. Durch Untersuchen dieses Objekts können Sie den Fortschritt eines Service-Imports überwachen. Suchen Sie zum Ermitteln des Namens des Endpoints-Objekts nach dem Wert der Annotation net.gke.io/derived-service in einem ServiceImport-Objekt, das dem importierten Service entspricht. Beispiel:

kind: ServiceImport
apiVersion: net.gke.io/v1
annotations: net.gke.io/derived-service: DERIVED_SERVICE_NAME
metadata:
 namespace: EXPORTED-SERVICE-NAMESPACE
 name: SERVICE-EXPORT-TARGET

Suchen Sie als Nächstes das Objekt Endpoints, um zu prüfen, ob MCS die Endpunkte bereits an den Importcluster weitergegeben hat. Das Endpoints-Objekt wird im selben Namespace erstellt wie das ServiceImport-Objekt unter dem Namen, der in der Annotation net.gke.io/derived-service gespeichert ist. Beispiel:

kubectl get endpoints DERIVED_SERVICE_NAME -n NAMESPACE

Ersetzen Sie Folgendes:

  • DERIVED_SERVICE_NAME ist der Wert der Annotation net.gke.io/derived-service im Objekt ServiceImport.
  • NAMESPACE ist der Namespace des ServiceExport-Objekts.

Weitere Informationen zum Systemstatus der Endpunkte finden Sie im Cloud Service Mesh-Dashboard in der Google Cloud Console.

Bei monitorlosen Diensten wird die Domain in die Liste der IP-Adressen der Endpunkte in den Exportclustern aufgelöst. Jeder Backend-Pod mit einem Hostnamen kann auch unabhängig mit einem Domainnamen in folgendem Format adressiert werden:

 HOSTNAME.MEMBERSHIP_NAME.LOCATION.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

Die Ausgabe enthält die folgenden Werte:

  • SERVICE_EXPORT_NAME und NAMESPACE: Die Werte, die Sie im Objekt ServiceExport definieren.
  • MEMBERSHIP_NAME ist die eindeutige Kennzeichnung in der Flotte für den Cluster, in dem sich der Pod befindet.
  • LOCATION: Standort der Mitgliedschaft. Mitgliedschaften sind entweder global oder ihr Standort ist eine der Regionen oder Zonen, in denen sich der Pod befindet, z. B. us-central1.
  • HOSTNAME: Der Hostname des Pods.

Sie können einen Backend-Pod auch mit einem Hostnamen adressieren, der aus einem mit einer globalen Mitgliedschaft registrierten Cluster exportiert wurde. Verwenden Sie dazu einen Domainnamen des folgenden Formats:

HOSTNAME.MEMBERSHIP_NAME.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

MCS deaktivieren

Um MCS zu deaktivieren, führen Sie die im Folgenden aufgeführten Schritte aus.

  1. Löschen Sie für jeden Cluster in Ihrer Flotte alle ServiceExport-Objekte, die Sie erstellt haben:

    kubectl delete serviceexport SERVICE_EXPORT_NAME \
    -n NAMESPACE

    Ersetzen Sie Folgendes:

    • SERVICE_EXPORT_NAME ist der Name Ihres ServiceExport-Objekts.
    • NAMESPACE ist der Namespace des ServiceExport-Objekts.

  2. Prüfen Sie, ob ServiceExport innerhalb von 30 Minuten aus der Liste verschwindet.

  3. Heben Sie die Registrierung Ihrer Cluster für die Flotte auf, wenn sie nicht für einen anderen Zweck registriert werden müssen.

  4. Deaktivieren Sie die Funktion multiclusterservicediscovery.

    gcloud container fleet multi-cluster-services disable \
    --project PROJECT_ID

    Ersetzen Sie dabei PROJECT_ID durch die Projekt-ID des Projekts, in dem Sie die Cluster registriert haben.

  5. Deaktivieren Sie die API für MCS:

    gcloud services disable multiclusterservicediscovery.googleapis.com \
    --project PROJECT_ID

    Ersetzen Sie dabei PROJECT_ID durch die Projekt-ID des Projekts, in dem Sie die Cluster registriert haben.

Beschränkungen

Anzahl der Cluster, Pods und Dienstports

Die im Folgenden aufgeführten Beschränkungen werden nicht erzwungen. In einigen Fällen können diese Beschränkungen je nach Auslastung in Ihren Clustern oder Projekten und der Endpunkt-Churn-Rate überschritten werden. Wenn diese Limits überschritten werden, können Leistungsprobleme auftreten.

In Kubernetes wird ein Service eindeutig durch seinen Namen und den Namespace identifiziert, zu dem er gehört. Dieses Namens- und Namespace-Paar wird als Name mit Namespace bezeichnet.

  • Cluster exportieren: Ein einzelner Dienst mit einem Namespace-Namen, kann sicher von bis zu 5 Clustern gleichzeitig exportiert werden. Über dieses Limit hinaus kann es sein, dass sich nur eine Teilmenge der Endpunkte in die genutzten Cluster importieren lässt. Sie können verschiedene Dienste aus verschiedenen Teilmengen von Clustern exportieren.

  • Anzahl der Pods für einen einzelnen Dienst: Am sichersten ist es, wenn die Anzahl von 250 Pods für einen einzelnen Dienst nicht überschritten wird. Bei relativ statischen Arbeitslasten und einer kleinen Anzahl an Multi-Cluster-Diensten kann diese Anzahl für tausende von Endpunkten pro Dienst erheblich überschritten werden. Wie bei Single-Cluster-Diensten werden alle Endpunkte von kube-proxy auf jedem Knoten überwacht. Wird dieses Limit überschritten, sind unter Umständen größere Knoten erforderlich, insbesondere wenn Sie mehrere Cluster gleichzeitig exportieren möchten.

  • Anzahl gleichzeitig exportierter Multi-Cluster-Dienste: Es wird empfohlen, nicht mehr als 250 eindeutige Service-Ports gleichzeitig zu exportieren.

    Ein eindeutiger Service-Port wird durch einen Namespace-Namen und eine Portnummer identifiziert, d. h. durch ein Tupel (Name, Namespace, Portnummer). Das heißt:

    • Dienste mit demselben Namespace-Namen und Port, die aus mehreren Clustern exportiert wurden, zählen als ein einzelner eindeutiger Service-Port.

    • Zwei Dienste mit demselben Namen und Port, aber unterschiedlichen Namespaces, z. B. (name, ns1, port-80) und (name, ns2, port-80), sind zwei unterschiedliche Dienstports, die auf das Limit von 250 eindeutigen Dienstports angerechnet werden.

    • Ein exportierter Dienst, der die Ports 80 und 443 verfügbar macht, wird mit zwei Ports auf das Limit von 250 eindeutigen Dienstports angerechnet, unabhängig von der Anzahl der Cluster in der Flotte, die diesen Dienst gleichzeitig exportieren.

    Jeder Multi-Cluster-Dienst wird auf das Kontingent für Backend-Dienste angerechnet und jede Zone jedes Exportclusters erstellt eine Netzwerk-Endpunktgruppe (NEG). Durch die Erhöhung dieser Kontingente ändert sich das angegebene Limit für die Gesamtzahl der eindeutigen Serviceports nicht.

Diensttypen

MCS unterstützt nur ClusterSetIP und monitorlose Dienste. NodePort- und LoadBalancer-Dienste werden nicht unterstützt und können zu einem unerwarteten Verhalten führen.

IPmasq-Agent mit MCS verwenden

MCS funktioniert wie erwartet, wenn Sie einen Standard- oder anderen nicht maskierten Pod-IP-Bereich verwenden.

Wenn Sie einen benutzerdefinierten Pod-IP-Bereich oder eine benutzerdefinierte IPmasq-Agent-ConfigMap verwenden, kann der MCS-Traffic maskiert werden. MCS funktioniert dann nicht, da die Firewallregeln nur Traffic von Pod-IPs zulassen.

Zur Vermeidung dieses Problems sollten Sie entweder den Standard-Pod-IP-Bereich verwenden oder alle Pod-IP-Bereiche im Feld nonMasqueradeCIDRs der IPmasq-Agent-ConfigMap angeben. Wenn Sie Autopilot oder einen nicht standardmäßigen Pod-IP-Bereich verwenden und nicht alle Pod-IP-Bereiche in der ConfigMap angeben können, verwenden Sie die NAT-Richtlinie für ausgehenden Traffic zur Konfiguration einer IP-Maskierung.

Portnummern innerhalb eines MCS-Dienstes wiederverwenden

Sie können dieselbe Portnummer nicht innerhalb eines MCS-Dienstes wiederverwenden, auch wenn die Protokolle unterschiedlich sind.

Dies gilt sowohl innerhalb eines Kubernetes-Dienstes als auch für alle Kubernetes-Dienste eines MCS-Dienstes.

MCS mit Clustern in mehreren Projekten

Sie können einen Dienst nicht exportieren, wenn dieser Dienst bereits von anderen Clustern in einem anderen Projekt in der Flotte mit demselben Namen und Namespace exportiert wird. Sie können in anderen Clustern in der Flotte in anderen Projekten auf den Dienst zugreifen, aber diese Cluster können nicht denselben Dienst in denselben Namespace exportieren.

Fehlerbehebung

Die folgenden Abschnitte enthalten Tipps zur Fehlerbehebung für MCS.

MCS-Funktionsstatus ansehen

Wenn Sie den Status der Feature-Ressource aufrufen, können Sie überprüfen, ob MCS erfolgreich konfiguriert wurde. Mit dem folgenden Befehl können Sie den Status aufrufen:

gcloud container fleet multi-cluster-services describe

Die Ausgabe sieht etwa so aus:

createTime: '2021-08-10T13:05:23.512044937Z'
membershipStates:
 projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
   state:
     code: OK
     description: Firewall successfully updated
     updateTime: '2021-08-10T13:14:45.173444870Z'
name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
resourceState:
 state: ACTIVE
spec: {}

Sie enthält unter anderem den allgemeinen Featurestatus unter resourceState und den Status der einzelnen Mitgliedschaften unter membershipStates.

Wenn Sie das MCS-Feature gemäß der Anleitung unter MCS im GKE-Cluster aktivieren aktiviert haben, der Wert von resourceState.state aber nicht ACTIVE ist, wenden Sie sich an den Support.

Der Status jeder Mitgliedschaft besteht aus dem Pfad und dem Feld state. Letzteres enthält code und description, die bei der Fehlerbehebung hilfreich sind.

Codes in den Mitgliedschaftsstatus

Ein Code, der durch das Feld state.code dargestellt wird, gibt den allgemeinen Status des Mitglieds in Bezug auf MCS an. Es gibt vier mögliche Werte:

  • OK: Die Mitgliedschaft wurde MCS hinzugefügt und kann verwendet werden.

  • WARNING: MCS wird gerade mit den Mitgliedschaftseinstellungen abgeglichen. Das Beschreibungsfeld kann weitere Informationen darüber enthalten, was diesen Code ausgelöst hat.

  • FAILED: Diese Mitgliedschaft wurde MCS nicht hinzugefügt. Andere Mitgliedschaften in der Flotte mit dem Code OK sind von dieser FAILED-Mitgliedschaft nicht betroffen. Das Beschreibungsfeld kann weitere Informationen darüber enthalten, was diesen Code ausgelöst hat.

  • ERROR: In dieser Mitgliedschaft fehlen Ressourcen. Andere Mitgliedschaften in der Flotte mit dem Code OK sind von dieser ERROR-Mitgliedschaft nicht betroffen. Das Beschreibungsfeld kann weitere Informationen darüber enthalten, was diesen Code ausgelöst hat.

Beschreibungen in den Mitgliedschaftsstatus

Informationen zum Status der Mitgliedschaft in MCS finden Sie im Feld state.description. Dieses Feld enthält Informationen zur Projekt- und Hubkonfiguration sowie zum Zustand der Flotte und der Mitgliedschaften. Informationen zu einzelnen Diensten und ihrer Konfiguration finden Sie im Feld Status.Conditions des Objekts ServiceExport (siehe Abschnitt ServiceExport untersuchen).

Das Feld state.description enthält die folgenden Informationen:

  • Firewall successfully created: Diese Meldung gibt an, dass die Firewallregel des Mitglieds erfolgreich erstellt und aktualisiert wurde. Der Code der Mitgliedschaft lautet OK.

  • Firewall creation pending: Diese Meldung gibt an, dass das Erstellen oder Aktualisieren der Firewallregel des Mitglieds aussteht. Der Code der Mitgliedschaft lautet WARNING. Diese Mitgliedschaft kann Probleme beim Aktualisieren und Verbinden mit neuen Multi-Cluster-Diensten und Mitgliedschaften verursachen, wenn die Firewallregel noch ausstehend ist.

  • GKE Cluster missing: Diese Meldung gibt an, dass der registrierte GKE-Cluster nicht verfügbar ist und/oder gelöscht wurde. Der Code der Mitgliedschaft lautet ERROR. Diese Mitgliedschaft muss manuell von der Flotte abgemeldet werden, nachdem ein GKE-Cluster gelöscht wurde.

  • Project that member lives in is missing required permissions and/or has not enabled all required APIs - additional setup steps are required: Diese Meldung gibt an, dass interne StatusForbidden-Fehler (403) vorliegen und der Code der Mitgliedschaft FAILED lautet. Dieser Fehler tritt in folgenden Szenarien auf:

    • Sie haben die erforderlichen APIs im Projekt des Mitglieds nicht aktiviert.

      Wenn sich der Cluster des Mitglieds in einem anderen Projekt als die Flotte befindet, lesen Sie den Abschnitt Projektübergreifende Einrichtung, um sicherzustellen, dass Sie alle erforderlichen Schritte abgeschlossen haben. Wenn Sie alle Schritte durchgeführt haben, stellen Sie sicher, dass die folgenden APIs im Registrierungsprojekt mit den folgenden Befehlen aktiviert sind:

      gcloud services enable multiclusterservicediscovery.googleapis.com --project PROJECT_ID
gcloud services enable dns.googleapis.com --project PROJECT_ID
gcloud services enable trafficdirector.googleapis.com --project PROJECT_ID
gcloud services enable cloudresourcemanager.googleapis.com --project PROJECT_ID

      Ersetzen Sie dabei PROJECT_ID durch die Projekt-ID des Projekts, in dem Sie die Cluster registriert haben.

    • Für die Dienstkonten mcsd und gkehub sind zusätzliche Berechtigungen im Projekt des Mitglieds erforderlich.

      Die Dienstkonten mcsd und gkehub sollten im Flottenhostprojekt automatisch mit allen erforderlichen Berechtigungen erstellt worden sein. Prüfen Sie mit den folgenden Befehlen, ob die Dienstkonten vorhanden sind:

      gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-mcsd
gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-gkehub

      Ersetzen Sie PROJECT_ID durch die Projekt-ID des Flottenhostprojekts.

    Es sollten dann die vollständigen Namen der Dienstkonten mcsd und gkehub angezeigt werden.

  • Multiple VPCs detected in the hub - VPC must be peered with other VPCs for successful connectivity: Diese Meldung wird angezeigt, wenn Cluster, die in verschiedenen VPCs gehostet werden, für dieselbe Flotte registriert sind. Der Status der Mitgliedschaft lautet OK. Das VPC-Netzwerk eines Clusters wird durch sein NetworkConfig-Netzwerk definiert. Multi-Cluster-Dienste benötigen ein flaches Netzwerk. Diese VPCs müssen für Multi-Cluster-Dienste aktiv per Peering verbunden werden, damit eine Verbindung zu ihnen hergestellt werden kann. Weitere Informationen finden Sie unter Peering von zwei Netzwerken.

  • Member does not exist in the same project as hub - additional setup steps are required, errors may occur if not completed.: Diese Meldung weist darauf hin, dass für projektübergreifende Cluster weitere Einrichtungsschritte erforderlich sind. Der Status der Mitgliedschaft lautet OK. Projektübergreifende Mitgliedschaften werden als Mitgliedscluster definiert, der sich nicht im selben Projekt wie die Flotte befinden. Weitere Informationen finden Sie unter Projektübergreifende Einrichtung.

  • Non-GKE clusters are currently not supported: Diese Meldung weist darauf hin, dass MCS nur GKE-Cluster unterstützt. Nicht-GKE-Cluster können nicht zu MCS hinzugefügt werden. Der Status der Mitgliedschaft lautet FAILED.

ServiceExport wird untersucht

Wenn Sie den Status eines einzelnen Dienstes und mögliche Fehler aufrufen möchten, prüfen Sie das Feld Status.Conditions in der Ressource ServiceExport für diesen Dienst:

kubectl describe serviceexports PROJECT_ID -n NAMESPACE

Die Ausgabe sieht etwa so aus:

Name:         SERVICE_NAME
Namespace:    NAMESPACE
Labels:       <none>
Annotations:  <none>
API Version:  net.gke.io/v1
Kind:         ServiceExport
Metadata:
  Creation Timestamp:  2024-09-06T15:57:40Z
  Finalizers:
    serviceexport.net.gke.io
  Generation:        2
  Resource Version:  856599
  UID:               8ac44d88-4c08-4b3d-8524-976efc455e4e
Status:
  Conditions:
    Last Transition Time:  2024-09-06T16:01:53Z
    Status:                True
    Type:                  Initialized
    Last Transition Time:  2024-09-06T16:02:48Z
    Status:                True
    Type:                  Exported
Events:                    <none>

Wenn der MCS-Controller eine ServiceExport-Ressource erkennt, fügt er dem Feld Status.Conditions die folgenden Bedingungen hinzu:

  • Initialized: „True“, wenn der MCS-Controller den durch die ServiceExport dargestellten Dienst erkannt und versucht hat, ihn abzugleichen.

  • Exported: „True“, wenn der durch ServiceExportdargestellte Dienst erfolgreich validiert wurde.

Jede Bedingung enthält die obligatorischen Felder Type, Status und LastTransitionTime. Während der MCS-Controller den Dienst abgleicht und validiert, ändert sich das Feld Status für die entsprechende Bedingung von False zu True.

Fehler

Wenn bei der Validierung ein Fehler auftritt, legt der Controller das Feld Status der Bedingung Exported auf False fest und fügt ein Feld Reason und ein Feld Message mit weiteren Informationen zum Fehler hinzu. Das Feld Reason kann einen der folgenden Werte haben:

  • NoMatchingService: Im angegebenen Cluster wurde kein Dienst gefunden, der dem Namen und Namespace des ServiceExport entspricht.
    Prüfen Sie, ob der Kubernetes-Dienst, den Sie exportieren möchten, im selben Cluster vorhanden ist. Prüfen Sie, ob Name und Namespace der beiden Ressourcen (Service und ServiceExport) genau übereinstimmen.

  • Conflict: Es ist bereits ein exportierter Dienst mit demselben Namen und Namespace vorhanden, der entweder nicht mit dem von diesem ServiceExport exportierten Dienst übereinstimmt oder aus einem anderen Netzwerk oder Projekt exportiert wird, was nicht zulässig ist (siehe Einschränkungen).
    Sehen Sie sich das Feld Message an, um die Details zu erfahren, und lesen Sie bei Bedarf den Abschnitt Einschränkungen. Achten Sie darauf, dass der Name und der Namespace von Service und ServiceExport übereinstimmen und alle Ressourcen im selben Netzwerk und/oder Projekt erstellt werden.

  • ReadinessProbeError: Für einen Container in einem Pod, der den Dienst unterstützt, ist ein readinessProbe konfiguriert. Kubernetes ReadinessProbes werden in Google cloud HealthChecks übersetzt und müssen denselben Einschränkungen entsprechen.

    So werden die Felder für die Bereitschaftsprüfung den Parametern für die Systemdiagnose zugeordnet:

    • PeriodSeconds entspricht CheckInterval
    • TimeoutSeconds entspricht Timeout
    • SuccessThreshold entspricht HealthyThreshold
    • FailureThreshold entspricht UnhealthyThreshold

    Um ReadinessProbes an die Einschränkungen von HealthCheck anzupassen, werden in MCS die folgenden Maßnahmen ergriffen:

    • PeriodSeconds und TimeoutSeconds sind auf 300 Sekunden begrenzt. Werte, die dieses Limit überschreiten, lösen einen Fehler aus.
    • SuccessThreshold und FailureThreshold sind auf 10 Sekunden begrenzt. Werte, die dieses Limit überschreiten, lösen einen Fehler aus.
    • Wenn TimeoutSeconds größer als PeriodSeconds ist, wird ein Fehler gemeldet und die Ressourcenerstellung (möglicherweise aller Ressourcen) schlägt fehl.

    Der Grund für solche Einschränkungen ist, Skalierbarkeitsprobleme, sich überschneidende nachfolgende Tests, langsame Systemdiagnosen/Bereitschaftsprüfungen usw. zu vermeiden. Passen Sie die Parameter von readinessProbe entsprechend den oben genannten Validierungen an. Es ist wichtig, solche Fehler für jeden Dienst der Flotte zu beheben. Weitere Informationen finden Sie unter Bekannte Probleme.

  • ServiceError: Beim Abrufen des entsprechenden Dienstes ist ein Fehler aufgetreten.
    Dieser Fehler hängt normalerweise mit einem Problem mit der Google Cloud-Infrastruktur zusammen. Wenn das Problem weiterhin besteht, wenden Sie sich bitte an den Google Cloud-Support.

  • PodsError: Fehler beim Abrufen des Backend-Pods oder der Backend-Pods
    Dieser Fehler hängt in der Regel mit einem Problem mit der Google Cloud-Infrastruktur zusammen. Wenn das Problem weiterhin besteht, wenden Sie sich bitte an den Google Cloud-Support.

  • EndpointsError: Fehler beim Aggregieren von Endpoints für einen Headless Service 
    Dieser Fehler hängt in der Regel mit einem Problem mit der Google Cloud-Infrastruktur zusammen. Wenn das Problem weiterhin besteht, wenden Sie sich bitte an den Google Cloud-Support.

Das Feld Message enthält zusätzlichen Kontext zum Fehler.

Häufige Berechtigungsprobleme

  • Erforderliche APIs sind im Projekt nicht aktiviert.

    Achten Sie darauf, dass Sie die erforderlichen APIs wie im Abschnitt Vorbereitung beschrieben aktiviert haben.

    Folgen Sie für eine flottenübergreifende Flotte dem entsprechenden Abschnitt Erforderliche APIs aktivieren in Multi-Cluster-Dienste mit freigegebener VPC einrichten.

  • Das Dienstkonto mcsd oder gkehub hat nicht die erforderlichen Berechtigungen.

    Bei einer Einrichtung mit einem einzelnen Projekt werden alle erforderlichen Berechtigungen automatisch Dienstkonten gewährt, die von GKE Hub und MCS automatisch erstellt werden.

    Für eine projektübergreifende Flotte müssen Sie zusätzliche IAM-Bindungen erstellen. Folgen Sie dem entsprechenden Abschnitt IAM-Bindungen erstellen unter Multi-Cluster-Dienste mit freigegebener VPC einrichten.

Bekannte Probleme

MCS-Dienste mit mehreren Ports

Es gibt ein bekanntes Problem bei Multi-Cluster-Services mit mehreren (TCP/UDP)-Ports in GKE Dataplane V2, bei denen einige Endpunkte in der Datenebene nicht programmiert sind. Dieses Problem betrifft GKE-Versionen vor 1.26.3-gke.400.

Verwenden Sie als Problemumgehung in GKE Dataplane V2 mehrere MCS mit einem einzelnen Port anstelle eines MCS mit mehreren Ports.

Portnummer, die innerhalb eines MCS-Dienstes wiederverwendet wird

Sie können dieselbe Portnummer innerhalb eines MCS-Dienstes nicht wiederverwenden, auch wenn die Protokolle unterschiedlich sind.

Dies gilt sowohl innerhalb eines Kubernetes-Dienstes als auch für alle Kubernetes-Dienste eines MCS-Dienstes.

MCS mit freigegebener VPC

Bei der aktuellen Implementierung von MCS werden Metadaten zwischen Flotten geteilt, wenn Sie mehr als eine Flotte in derselben freigegebenen VPC bereitstellen. Wenn ein Service in einer Flotte erstellt wird, werden Dienstmetadaten in alle anderen Flotten exportiert oder importiert, die Teil derselben freigegebenen VPC und für den Nutzer sichtbar sind.

Systemdiagnose verwendet den Standardport anstelle von containerPort

Wenn Sie einen Dienst mit einem targetPort-Feld bereitstellen, das auf einen benannten Port in einem Deployment verweist, konfiguriert MCS den Standardport für die Systemdiagnose anstelle des angegebenen containerPort.

Verwenden Sie zur Vermeidung dieses Problems numerische Werte im Service-Feld ports.targetPort und im Deployment-Feld readinessProbe.httpGet.port anstelle von benannten Werten.

Ungültige Bereitschaftsprüfung für einen einzelnen Dienst führt zu Problemen bei anderen Diensten

Es gibt einen bekannten potenziellen readinessProbe-Konfigurationsfehler, der unter ServiceExports untersuchen beschrieben wird. Bei der aktuellen Implementierung von MCS kann dieser Fehler, wenn er für einen einzelnen exportierten Dienst auftritt, verhindern, dass einige oder alle anderen Dienste in der Flotte synchronisiert werden.

Es ist wichtig, die Konfigurationen für jeden Dienst auf dem neuesten Stand zu halten. Wenn ein MCS-Dienst nicht aktualisiert wird, prüfen Sie, ob für keinen der ServiceExports in einem der Cluster in einem der Namespaces ReadinessProbeError als Grund für den Status „Condition Exported“ (Bedingung Exported) mit dem Wert „False“ angegeben ist. Informationen zum Prüfen der Bedingungen finden Sie unter ServiceExports untersuchen.

Nächste Schritte