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 baut auf der Leistung von Flotten auf, damit Anthos-Nutzer auf einfache, konsistente und sichere Weise eine Verbindung zu Clustern von Flottenmitgliedern herstellen und Befehle ausführen können, unabhängig davon, ob sich die Cluster in Google Cloud, anderen öffentlichen Clouds oder lokal befinden, und vereinfacht die Automatisierung von DevOps-Prozessen in allen Clustern.

In diesem Leitfaden wird davon ausgegangen, dass Sie bereits mit einigen grundlegenden Flottenkonzepten 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. Drittanbieter-Identitätsanbieter mit Mitarbeiteridentitätsföderation und gruppenbasierte Authentifizierung über GKE Identity Service werden unterstützt. Wenn Sie mehr über den GKE Identity Service erfahren oder ihn als eigenständige Authentifizierungsoption eines Drittanbieters verwenden möchten, lesen Sie Einführung in den 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.
  • Stellen Sie eine Verbindung zu einem gewünschten Cluster her. Verwenden Sie dabei dieselbe Infrastruktur, die wir zum Anzeigen 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

Beim Standardablauf, der im vorherigen Abschnitt beschrieben wurde, wird die Anfrage eines Nutzers anhand seiner individuellen ID autorisiert. In vielen Fällen ist es jedoch hilfreich, wenn Sie Nutzer auf Grundlage ihrer Mitgliedschaft in Google Groups autorisieren 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. Nach einigen zusätzlichen Einrichtungsschritten mit dem GKE Identity Service können Sie das Connect-Gateway so konfigurieren, dass Informationen zur Mitgliedschaft in 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 nutzen möchten, wenden Sie sich bitte an Cloud Customer Care oder das Connect Gateway-Team.

Identitätssupport durch Drittanbieter

Connect Gateway unterstützt nicht nur die Arbeit mit Google Workspace-Nutzern und -Gruppen, sondern auch die Autorisierung mithilfe von Drittanbieteridentitäten wie Azure Active Directory und Okta. Mithilfe der Mitarbeiteridentitätsföderation können Sie einen externen Identitätsanbieter verwenden, um eine Gruppe von Nutzern – eine Gruppe von Nutzern wie Mitarbeitern, Partnern und Auftragnehmern – mithilfe der Identity and Access Management zu authentifizieren und zu autorisieren, damit die Nutzer auf Google Cloud-Dienste wie das Connect-Gateway zugreifen können. Nach einigen zusätzlichen Einrichtungsschritten mit dem GKE Identity Service können Sie das Connect-Gateway so konfigurieren, dass Nutzerinformationen zu Gruppenmitgliedschaften von Drittanbietern abgerufen werden.

Das Drittanbieteridentitätsfeature 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 zur Funktionsweise und Einrichtung dieser Funktion finden Sie unter Connect-Gateway mit Drittanbieteridentitäten einrichten.

Sie können die Drittanbieterauthentifizierung auch vollständig mit GKE Identity Service einrichten. Folgen Sie dazu der Anleitung in der 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