Verbindung zu registrierten Clustern mit dem Connect-Gateway

Flotten in Google Cloud sind logische Gruppen von Kubernetes-Clustern und anderen Ressourcen, die zusammen verwaltet und durch die Registrierung von Clustern in Google Cloud erstellt werden können. Das Connect-Gateway basiert auf den leistungsstarken Flotten, mit denen Anthos-Nutzer eine Verbindung zu Befehlen für Flottenmitgliedscluster einfach, konsistent und sicher herstellen und diese ausführen können, unabhängig davon, ob sich diese Cluster in Google Cloud oder anderen öffentlichen Clouds befinden oder auch lokal. Das Connect-Gateway vereinfacht die Automatisierung der DevOps-Prozesse über alle Cluster hinweg.

In diesem Leitfaden wird davon ausgegangen, dass Sie mit einigen grundlegenden Konzepten von Flotten und mit der Registrierung von Clustern bei einer Flotte vertraut sind. Ist dies nicht der Fall, finden Sie weitere Informationen in der Übersicht zur Flottenverwaltung, in der Übersicht zur Flottenerstellung und in den dort verlinkten Leitfäden. Sie sollten außerdem mit den Tools und Konzepten von Kubernetes vertraut sein, einschließlich kubectl, client-go (wenn Sie das Gateway für Automatisierungszwecke verwenden möchten), rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) und Kubernetes-Kernressourcen.

Standardmäßig verwendet das Connect-Gateway Ihre Google-ID zur Authentifizierung bei Clustern. Darüber hinaus unterstützt das Connect-Gateway die Workforce Identity-Föderation und die gruppenbasierte Authentifizierung über GKE Identity Service. Wenn Sie mehr über GKE Identity Service erfahren oder es als eigenständige Drittanbieter-Authentifizierungsoption verwenden möchten, finden Sie weitere Informationen unter GKE Identity Service.

Vorteile des Connect-Gateways

Für die Verwaltung von Arbeitslasten gibt es viele Herausforderungen, wenn Ihre Cluster in mehreren Cloud- und Hybridumgebungen ausgeführt werden. Cluster können in verschiedenen Virtual Private Clouds (VPCs) ausgeführt werden und nutzen verschiedene Identitätsanbieter. Die Verbindung, die Authentifizierung und die Autorisierung werden dadurch komplizierter. Manchmal ist es schwierig, herauszufinden, welche Cluster in diesen Umgebungen vorhanden sind.

Das Connect-Gateway bietet folgende Vorteile:

  • Finden Sie durch eine einfache Abfrage heraus, welche Cluster in Google Cloud, in einer anderen öffentlichen Cloud oder lokal vorhanden und für Ihre Flotte registriert sind.
  • Verbindung zu einem gewünschten Cluster mit derselben Infrastruktur herstellen, die wir auch für die Anzeige registrierter GKE-Cluster in der Google Cloud Console verwenden.
  • Authentifizierung: Verwenden Sie dazu dieselben Identitäten wie für Google Cloud-Dienste.
  • Autorisierung: Sorgen Sie für eine konsistente Autorisierung aller in einer Flotte registrierten Cluster.

Das Gateway authentifiziert Ihre Google Cloud-Identität und stellt die Verbindung zum API-Server des Clusters über den Connect-Dienst bereit.

Sie können über das Gateway direkt mit Clustern interagieren, indem Sie Befehlszeilentools verwenden, die kubeconfig akzeptieren, z. B. kubectl. Sie können das Gateway auch einfach mit Ihren Build-Pipelines und anderen DevOps-Automatisierung nutzen. Ein Beispiel hierfür finden Sie in unserer Anleitung In Cloud Build integrieren.

Sie können den Connect-Dienst auch verwenden, um eine Verbindung zu registrierten Clustern außerhalb von Google Cloud mit Ihrer Google Cloud-Identität in der Google Cloud Console herzustellen. Folgen Sie dazu der Anleitung unter Über die Google Cloud Console bei einem Cluster anmelden.

Funktionsweise

Im Folgenden wird der Ablauf dargestellt, den ein typischer Nutzer oder Dienst (z. B. eine CI-/CD-Pipeline) nach der Konfiguration verwendet, um das Connect-Gateway zu nutzen. Eine detaillierte Anleitung für Nutzer finden Sie in unserem Leitfaden zur Verwendung.

  1. Der Nutzer oder Dienst erkennt Cluster, indem er die Ressourcen einer Mitgliedschaft für die Flotte mithilfe der Google Cloud CLI auflistet.

    gcloud container fleet memberships list

  2. Der Nutzer oder Dienst ruft die Connect-Gateway-spezifische kubeconfig ab, die erforderlich ist, um den ausgewählten Cluster über die Google Cloud CLI zu erreichen.

    gcloud container fleet memberships get-credentials membership-name

    Wenn Sie bereits mit der Verwendung der gcloud CLI mit GKE vertraut sind, entspricht dies in etwa der Ausführung von gcloud container clusters get-credentials mit Ihrem Google Cloud-Konto. Damit können Sie (sofern autorisiert) auf jeden Cluster zugreifen, der in der Flotte Ihres Projekts registriert und verbunden ist.

  3. Der Nutzer oder Dienst führt seine Befehle wie gewohnt mit kubectl oder client-go aus und verwendet dabei die heruntergeladene kubeconfig-Datei.

    1. Der Nutzer/Dienst wird durch das Connect-Gateway authentifiziert und die Autorisierung wird überprüft, um sicherzustellen, dass er zur Verwendung des Gateways berechtigt ist.
    2. Die Anfrage wird über den Connect-Dienst und den Connect Agent an den entsprechenden Kubernetes API-Server weitergeleitet.
    3. Der Kubernetes API-Server autorisiert die Anfrage, die erfordert, dass der Connect-Agent berechtigt ist, die Identität des Nutzers oder Dienstes zu übernehmen, und dass der Nutzer oder Dienst berechtigt ist, die gewünschte Anfrage auszuführen.

Support für Google-Gruppen

Im beschriebenen Standardablauf aus dem vorherigen Abschnitt wird die Anfrage des Nutzers anhand seiner individuellen ID autorisiert. In vielen Fällen ist es jedoch sinnvoll, Nutzer anhand der Zugehörigkeit zu Google Groups autorisieren zu können. Bei einer Autorisierung, die auf der Gruppenmitgliedschaft basiert, müssen Sie nicht für jedes Konto eine separate Autorisierung einrichten. Dies erleichtert die Verwaltung und Überprüfung von Richtlinien. Sie können beispielsweise problemlos den Clusterzugriff für ein Team freigeben, sodass Sie einzelne Nutzer nicht manuell zu Clustern hinzufügen oder daraus entfernen müssen, wenn diese dem Team beitreten oder es verlassen möchten. Durch einige zusätzliche Einrichtungsschritte mit dem GKE Identity Service können Sie das Connect-Gateway so konfigurieren, dass die Mitgliedschaftsinformationen für Google Groups für den Nutzer abgerufen werden.

Weitere Informationen zu dieser Funktion und zur Einrichtung finden Sie unter Connect-Gateway mit Google Groups einrichten.

Wenn Sie dieses Feature mit angehängten Clustern oder anderen GKE-Clusterumgebungen verwenden möchten, wenden Sie sich an Cloud Customer Care oder das Connect-Gateway-Team.

Unterstützung von externen Identitäten

Das Connect-Gateway unterstützt nicht nur die Arbeit mit Google Workspace-Nutzern und -Gruppen, sondern unterstützt auch die Autorisierung mithilfe von Drittanbieteridentitäten wie Azure Active Directory und Okta. MitWorkforce Identity-Föderation haben Sie die Möglichkeit, einen externen Identitätsanbieter zu verwenden, um eine Gruppe von Nutzern, z. B. Mitarbeiter, Partner und Auftragnehmer, mithilfe der Identitäts- und Zugriffsverwaltung zu authentifizieren und zu autorisieren, damit die Nutzer auf Google Cloud-Dienste wie Connect Gateway zugreifen können. Durch einige zusätzliche Einrichtungsschritte mit dem GKE Identity Service können Sie das Connect-Gateway so konfigurieren, dass Nutzerinformationen zu Gruppenmitgliedschaften von Drittanbietern abgerufen werden.

Das Feature für Drittanbieteridentitäten des Connect-Gateways wird für GKE on VMware und GKE on Bare Metal ab Anthos 1.13 unterstützt. Für angehängte Cluster ist dieses Feature ab GKE Enterprise 1.16 verfügbar.

Weitere Informationen zu dieser Funktion und zur Einrichtung finden Sie unter Connect-Gateway mit Drittanbieter-Identitäten einrichten.

Sie können die Authentifizierung eines Drittanbieters auch vollständig mit GKE Identity Service einrichten. Folgen Sie dazu der Anleitung in der zugehörigen Dokumentation.

Latenz

Die Gesamtlatenz einer Anfrage über das Gateway kann in zwei Teile unterteilt werden: die RTT (Round Trip Time) vom Connect-Gateway-Dienst zum Connect-Agent und die Ausführungszeit der Anfrage innerhalb des Clusters. Die zusätzliche RTT-Wert beträgt p95<500ms und p99<1s. Beachten Sie, dass die meisten kubectl-Befehle eine Reihe verschiedener Anfragen ausführen, die jeweils einen Roundtrip erfordern, bevor eine Antwort an den Nutzer gerendert wird.

Nächste Schritte