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 Clouderstellt werden können. Das Connect-Gateway baut auf der Leistungsfähigkeit von Flotten auf und ermöglicht es GKE-Nutzern, sich mit Flottenmitgliedsclustern zu verbinden und Befehle auf einfache, konsistente und sichere Weise auszuführen. Dies gilt unabhängig davon, ob sich die Cluster in Google Cloud, anderen öffentlichen Clouds oder lokal befinden. Außerdem wird es dadurch einfacher, DevOps-Prozesse für alle Ihre Cluster zu automatisieren.

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. Weitere Informationen zu GKE Identity Service oder zur Verwendung dessen als eigenständige Drittanbieter-Authentifizierungsoption finden Sie unter Einführung in 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 -Konsole herzustellen. Folgen Sie dazu der Anleitung unter Mit Clustern über die Google Cloud Console arbeiten.

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. Bei GKE-Clustern stellt das Gateway eine direkte Verbindung zum GKE-Cluster her.
    2. Bei Nicht-GKE-Kubernetes-Clustern wird die Anfrage über den Connect-Dienst und den Connect Agent an den entsprechenden Kubernetes API-Server weitergeleitet.
    3. Bei Nicht-GKE-Kubernetes-Clustern autorisiert der Kubernetes API-Server die Anfrage. Dazu muss der Connect-Agent berechtigt sein, die Identität des Nutzers oder Dienstes zu übernehmen, und der Nutzer oder Dienst muss berechtigt sein, 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-Umgebungen 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 Autorisierung mit Google Workspace-Nutzern und ‑Gruppen, sondern auch mit Drittanbieteridentitäten wie Azure Active Directory und Okta. Mit der Mitarbeiteridentitätsföderation können Sie einen externen Identitätsanbieter verwenden, um eine Gruppe von Nutzern, z. B. Mitarbeiter, Partner und Auftragnehmer, mithilfe von Identity and Access Management zu authentifizieren und zu autorisieren, damit die Nutzer aufGoogle Cloud -Dienste wie das 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.

Bei angehängten GKE-Clustern ist dieses Feature für alle unterstützten Kubernetes-Clusterversionen verfügbar.

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

Alternativ können Sie die Authentifizierung von Drittanbietern vollständig mit GKE Identity Service einrichten. Folgen Sie dazu der Anleitung in seiner 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