Cluster über die Google Cloud Console verwalten

In diesem Dokument wird erläutert, wie Sie Cluster, die mit Google Distributed Cloud-Software für VMware erstellt wurden, für die Verwaltung in der Google Cloud Console verfügbar machen. Dazu gehört die grundlegende Verwaltung, z. B. die Möglichkeit, sich bei Clustern anzumelden und deren Arbeitslasten anzuzeigen, sowie die Aktivierung der Verwaltung des Clusterlebenszyklus, sodass Sie Cluster upgraden, aktualisieren und löschen können.

Flottenmitglieder und die Console

Alle Google Distributed Cloud-Cluster müssen Mitglieder einer Flotte sein – eine einheitliche Möglichkeit, mehrere Cluster und deren Arbeitslasten anzuzeigen und zu verwalten. Jede Flotte von Clustern ist einem Flotten-Hostprojekt zugeordnet.

In Google Distributed Cloud wird ein Administratorcluster zum Zeitpunkt der Erstellung bei einer Flotte registriert. Dazu wird Ihr Flotten-Hostprojekt im Abschnitt gkeConnect der Clusterkonfigurationsdatei angegeben. Google Distributed Cloud verwendet diese Informationen, um Ihren Cluster im angegebenen Flottenprojekt zu registrieren. Wenn die Registrierung fehlgeschlagen ist, kannst du die Registrierung mit gkectl update credentials register noch einmal versuchen.

Beachten Sie, dass Sie bei einem erneuten Versuch der Registrierung den Connect-Register-Dienstkontoschlüssel nicht aktualisieren müssen. Mit anderen Worten, Sie können weiterhin Ihr ursprüngliches Connect-Register-Dienstkonto verwenden. Weitere Informationen zu dem Befehl finden Sie unter Dienstkontoschlüssel rotieren.

In Google Distributed Cloud wird ein Nutzercluster zum Zeitpunkt der Erstellung bei einer Flotte registriert:

Wenn Sie einen Nutzercluster mit gkectl erstellen, geben Sie das Hostprojekt Ihrer Flotte im Abschnitt gkeConnect der Clusterkonfigurationsdatei an. Anhand dieser Informationen registriert Google Distributed Cloud Ihren Cluster beim angegebenes Flottenprojekt.
Wenn Sie einen Nutzercluster mit einem Standardtool (Console, Google Cloud CLI oder Terraform) erstellen, wird der Cluster automatisch zu einem Flottenmitglied im von Ihnen angegebenen Projekt.

Flottenmitglieder außerhalb von Google Cloud, z. B. Google Distributed Cloud, werden in der Console in Ihrem Flotten-Hostprojekt zusammen mit anderen Flottenclustern wie GKE in Google Cloud angezeigt. Wie Sie Google Distributed Cloud über die Console verwalten können, hängt von folgenden Faktoren ab:

Wenn Sie die Authentifizierung eingerichtet haben, können Sie sich bei Ihren Clustern anmelden und deren Arbeitslasten und andere Details aufrufen.
Wenn Sie die Verwaltung des Clusterlebenszyklus für den Cluster aktiviert haben, können Sie Nutzercluster auch mit der Console upgraden, aktualisieren oder löschen. Wenn diese Funktion nicht aktiviert ist, können Sie nur den Clusterlebenszyklus mit gkectl auf Ihrer Administratorworkstation verwalten.

Registrierte Cluster ansehen

Alle Ihre Flottencluster werden auf der Seite Google Kubernetes Engine-Cluster – Übersicht angezeigt. Dadurch erhalten Sie einen Überblick über Ihre gesamte Flotte und können für Google Distributed Cloud sehen, welche Cluster von der GKE On-Prem API verwaltet werden.

So rufen Sie Ihre Flottencluster auf:

Rufen Sie in der Console die Seite Google Kubernetes Engine-Cluster auf.

Zu GKE-Clustern
Wählen Sie das Google Cloud-Projekt aus.
- Wenn vm Google Distributed Cloud in der Spalte Typ angezeigt wird, wird der Cluster von der GKE On-Prem API verwaltet.
- Wenn in der Spalte Typ Extern angezeigt wird, wird der Cluster nicht von der GKE On-Prem API verwaltet.

Wenn sie weitere Details zu einem Cluster sehen möchten, müssen sich Nutzer anmelden und beim Cluster authentifizieren. Gehen Sie dazu so vor:

Authentifizierungsmethode einrichten
Nutzern bestimmte Rollen für Identity and Access Management gewähren

Authentifizierung einrichten

Wie bereits beschrieben, werden alle Flottencluster in den GKE- und GKE Enterprise-Clusterlisten in der Console angezeigt. Um jedoch weitere Details wie Knoten und Arbeitslasten anzusehen (und den Clusterlebenszyklus auszuführen, wenn die Funktion aktiviert ist), müssen sich die Nutzer anmelden und beim Cluster authentifizieren. Dazu müssen Ihre registrierten Cluster mit einer der folgenden Authentifizierungsmethoden eingerichtet werden:

Google-Identität: Bei dieser Option können sich Nutzer mit ihrer Google Cloud-Identität anmelden. Dies ist die E-Mail-Adresse, die mit Ihrem Google Cloud-Konto verknüpft ist. Verwenden Sie diese Option, wenn Nutzer bereits Zugriff auf Google Cloud mit einer Google-Identität haben. Wenn Sie den Cluster in in der Console erstellt haben, können Sie sich über Ihre Google-Identität anmelden, aber Sie müssen die Authentifizierung für andere Nutzer konfigurieren.

Die einfachste Authentifizierungsmethode ist die Anmeldung mit einer Google-Identität in der Console, insbesondere wenn Sie Google Distributed Cloud mit einer minimalen Installation testen. Daher haben wir dies detaillierter unten unter Google-Identitätsauthentifizierung einrichten beschrieben.
OpenID Connect (OIDC): Mit dieser Option können sich Nutzer über die Console mit ihrer Identität über einen OIDC-Identitätsanbieter eines Drittanbieters wie Okta oder Microsoft AD FS bei Clustern anmelden. Sie können diese Option verwenden, wenn Ihre Nutzer bereits Nutzernamen, Passwörter und Sicherheitsgruppenmitgliedschaften von Ihrem Anbieter haben. In den folgenden Anleitungen erfahren Sie, wie Sie die OIDC-Authentifizierung von Drittanbietern für Ihre Cluster einrichten:
- Cluster für GKE Identity Service mit OIDC konfigurieren: In dieser Anleitung wird beschrieben, wie Sie die OIDC-Authentifizierung auf Clusterbasis einrichten.
- GKE Identity Service für eine Flotte einrichten: Mit dieser Option können Sie OIDC auf Flottenebene einrichten.
Inhabertoken: Wenn die oben von Google bereitgestellten Lösungen für Ihre Organisation nicht geeignet sind, können Sie die Authentifizierung mit einem Kubernetes-Dienstkonto einrichten und sich mit dessen Inhabertoken anmelden. Weitere Informationen finden Sie unter Mit einem Inhabertoken einrichten.

Erforderliche Rollen zuweisen

Der Zugriff auf die Console wird durch Identity and Access Management (IAM) gesteuert. Diese IAM-Rollen sind erforderlich, unabhängig davon, welche Authentifizierungsmethode Sie auswählen. Zum Verwalten des Clusterlebenszyklus in der Console müssen Sie einige IAM-Rollen zuweisen.

Damit Nutzer auf die Console zugreifen können, müssen Sie mindestens die folgenden Rollen zuweisen:
- roles/container.viewer Mit dieser Rolle können Nutzer die GKE-Clusterseite und andere Containerressourcen in der Console aufrufen. Ausführliche Informationen zu den in dieser Rolle enthaltenen Berechtigungen und zum Zuweisen einer Rolle mit Lese-/Schreibberechtigungen finden Sie in der IAM-Dokumentation unter Kubernetes Engine-Rollen.
- roles/gkehub.viewer Mit dieser Rolle können Nutzer die Cluster außerhalb von Google Cloud in der Console aufrufen. Ausführliche Informationen zu den in dieser Rolle enthaltenen Berechtigungen und zum Zuweisen einer Rolle mit Lese-/Schreibberechtigungen finden Sie in der IAM-Dokumentation unter GKE-Hub-Rollen.
Damit Nutzer den Clusterlebenszyklus in der Console verwalten können, Gewähren Sie die IAM-Rolle roles/gkeonprem.admin. Die Die Rolle roles/gkeonprem.admin gewährt Nutzern Administratorzugriff auf die GKE On-Prem API, mit der die Console den Clusterlebenszyklus verwaltet. Weitere Informationen zu den in dieser Rolle enthaltenen Berechtigungen finden Sie in der IAM-Dokumentation unter GKE On-Prem-Rollen.

Die folgenden Befehle zeigen, wie Sie die minimalen Rollen zuweisen, die zum Verwalten des Clusterlebenszyklus in der Console erforderlich sind:

gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
    --member=MEMBER \
    --role=roles/container.viewer

gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkeonprem.admin

Dabei gilt:

FLEET_HOST_PROJECT_ID ist das Flotten-Hostprojekt. Für Cluster, die mit gkectl erstellt wurden, ist dies das Projekt, das Sie im Abschnitt gkeConnect der Konfigurationsdatei des Nutzerclusters konfiguriert haben. Bei Clustern, die in der Console erstellt wurden, ist dies das Projekt, das Sie beim Erstellen des Clusters ausgewählt haben.
MEMBER ist die E-Mail-Adresse des Nutzers im Format user:emailID, z. B. user:alice@example.com.

Verwaltung des Clusterlebenszyklus in der Console aktivieren

Nutzercluster, die mit Standardtools (der Console, der gcloud CLI oder Terraform) erstellt wurden, werden automatisch in der GKE On-Prem API registriert und ermöglichen es Ihnen, Aufgaben zur Verwaltung des Clusterlebenszyklus in der Console auszuführen. Wenn Sie diese Funktion für Nutzercluster aktivieren möchten, die mit gkectl erstellt wurden, führen Sie die Schritte unter Konfigurieren Sie einen Nutzercluster, der von der GKE On-Prem API verwaltet werden soll aus. Wenn die Verwaltung des Clusterlebenszyklus aktiviert ist, können Sie die folgenden Aufgaben über die Console ausführen:

Google-Identitätsauthentifizierung einrichten

Damit sich Nutzer mit ihrer Google-Identität im Cluster anmelden können, müssen Sie Folgendes konfigurieren:

Nutzer benötigen bestimmte IAM-Rollen (Identity and Access Management), um Cluster in der Console auf der Liste der GKE-Cluster sehen und mit diesen interagieren zu können.
Nutzer müssen den Richtlinien der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes hinzugefügt werden, auf die das Connect-Gateway über den Kubernetes API-Server des Clusters den Connect-Agent zugreifen muss.

RBAC-Autorisierung konfigurieren

Der Kubernetes API-Server jedes Clusters muss Anfragen von der Console autorisieren. Zum Konfigurieren der Autorisierung müssen Sie auf jedem Cluster die RBAC-Richtlinien (Rollenbasierte Zugriffssteuerung) konfigurieren.

Wenn Sie den Nutzercluster mit einem Standardtool erstellt haben, haben Sie möglicherweise bereits die entsprechenden RBAC-Richtlinien, die Ihnen vollständigen Administratorzugriff auf den Cluster gewähren. Die GKE On-Prem API fügt Ihr Google-Konto in den folgenden Fällen automatisch als Administrator hinzu:

Sie haben den Nutzercluster in der Console erstellt.
Sie haben den Nutzercluster mit der gcloud CLI erstellt und Ihr Google-Konto wurde im Flag --admin-users des Befehls zur Clustererstellung angegeben.
Sie haben den Nutzercluster mit Terraform erstellt und Ihr Google-Konto wurde im Feld authorization.admin_users.username angegeben.

Nutzercluster, die mit gkectl erstellt wurden, gewähren Ihnen nicht die RBAC-Richtlinien, um den Cluster mithilfe der Console zu verwalten. Sie müssen sich selbst hinzufügen nachdem der Cluster erstellt wurde. Unabhängig davon, mit welchem Tool Sie den Cluster erstellt haben, können Sie nach dem Erstellen des Clusters weitere als Administratoren hinzufügen.

Sie haben folgende Möglichkeiten, Administratorzugriff auf die Cluster zu gewähren. Es werden zwei verschiedene gcloud-Befehle bereitgestellt.

Der Befehl gcloud ... generate-gateway-rbac muss auf Ihrer Administrator-Workstation ausgeführt werden, da der Befehl Zugriff auf die kubeconfig und den Kontext des Clusters benötigt (die in der Regel nur auf Ihrer Administrator-Workstation verfügbar sind). Mit dem Befehl generate-gateway-rbac können Sie die RBAC-Richtlinien anpassen. Die E-Mail-Adressen der Nutzer werden jedoch nicht als Administratoren im Abschnitt Clusterdetails der Console angezeigt.
Der Befehl gcloud ... update kann auf einer beliebigen Administratorworkstation oder einen beliebigen Computer mit Zugriff auf die GKE On-Prem API ausgeführt werden.

`generate-gateway-rbac`

Stellen Sie eine Verbindung zu Ihrer Administrator-Workstation her.
Führen Sie den folgenden Befehl aus, um die Komponenten zu aktualisieren:
```
gcloud components update
```
Generieren Sie die RBAC-Richtlinien für Nutzer und Dienstkonten und wenden Sie sie auf Ihren Cluster an:
```
gcloud container fleet memberships generate-gateway-rbac  \
    --membership=MEMBERSHIP_NAME \
    --role=ROLE \
    --users=USERS \
    --project=FLEET_HOST_PROJECT_ID \
    --kubeconfig=KUBECONFIG_PATH \
    --context=KUBECONFIG_CONTEXT \
    --apply
```
Ersetzen Sie dabei Folgendes:
- MEMBERSHIP_NAME: der Name, der zur eindeutigen Darstellung des Clusters in seiner Flotte verwendet wird. In Google Distributed Cloud sind der Name der Mitgliedschaft und der Clustername identisch.
- ROLE: die Kubernetes-Rolle, die Sie den Nutzern auf dem Cluster gewähren. Geben Sie clusterrole/cluster-admin an, um Nutzern vollen Zugriff auf alle Ressourcen im Cluster in allen Namespaces zu gewähren. Um schreibgeschützten Zugriff zu gewähren, geben Sie clusterrole/view an. Sie können auch eine benutzerdefinierte Rolle erstellen, z. B. role/mynamespace/namespace-reader. Die benutzerdefinierte Rolle muss bereits vorhanden sein, bevor Sie den Befehl ausführen.
- USERS: Die E-Mail-Adressen der Nutzer (Nutzerkonten oder Dienstkonten), denen Sie Berechtigungen erteilen möchten, als durch Kommas getrennte Liste. Beispiel: --users=foo@example.com,test-acct@test-project.iam.gserviceaccount.com.
- FLEET_HOST_PROJECT_ID: die Projekt-ID des Hostprojekts der Flotte.
- KUBECONFIG_PATH: der lokale Pfad, in dem die kubeconfig-Datei mit einem Eintrag für den Cluster gespeichert ist.
- KUBECONFIG_CONTEXT ist der Clusterkontext des Clusters, wie er in der Datei „kubeconfig” angezeigt wird. Sie können den aktuellen Kontext über die Befehlszeile abrufen, indem Sie kubectl config current-context ausführen. Unabhängig davon, ob Sie den aktuellen Kontext verwenden oder nicht, achten Sie darauf, dass er für den Zugriff auf den Cluster funktioniert. Führen Sie dazu einen einfachen Befehl wie den folgenden aus:
```
kubectl get namespaces \
  --kubeconfig=KUBECONFIG_PATH \
  --context=KUBECONFIG_CONTEXT
```
Nach der Ausführung von gcloud container fleet memberships generate-gateway-rbac wird am Ende der Ausgabe etwa Folgendes angezeigt, das zur besseren Lesbarkeit gekürzt ist:
```
Validating input arguments.
Specified Cluster Role is: clusterrole/cluster-admin
Generated RBAC policy is:
--------------------------------------------
...
Applying the generate RBAC policy to cluster with kubeconfig: /usr/local/google/home/foo/.kube/config, context: kind-kind
Writing RBAC policy for user: foo@example.com to cluster.
Successfully applied the RBAC policy to cluster.
```
Dies ist der Kontext für den Zugriff auf den Cluster über das Connect-Gateway.

Weitere Informationen zum Befehl generate-gateway-rbac finden Sie im Referenzhandbuch für die gcloud-Befehlszeile.

`update`

Führen Sie den folgenden Befehl aus, um die Komponenten zu aktualisieren:
```
gcloud components update
```
Fügen Sie für jeden Nutzer, dem die Rolle clusterrole/cluster-admin zugewiesen werden muss, das Flag --admin-users ein und führen Sie den folgenden Befehl aus. Sie können nicht mehrere Nutzer in einem einzelnen Flag angeben. Achten Sie darauf, dass Sie Ihr Google-Konto in den Befehl aufnehmen, da der Befehl die Berechtigungsliste mit den Nutzern überschreibt, die Sie im Befehl angeben.
```
gcloud container vmware clusters update USER_CLUSTER_NAME \
  --admin-users YOUR_GOOGLE_ACCOUNT \
  --admin-users ADMIN_GOOGLE_ACCOUNT_1 \
```

Zusätzlich zur Zuweisung der Kubernetes-Rolle clusterrole/cluster-admin gewährt der Befehl die RBAC-Richtlinien, die die Nutzer für den Zugriff auf den Cluster über das Connect-Gateway benötigen.

Console

Führen Sie die folgenden Schritte in der Console aus, um die RBAC-Richtlinien auf Nutzer anzuwenden:

Rufen Sie in der Console die Seite Google Kubernetes Engine-Cluster auf.

Zu GKE-Clustern
Wählen Sie das Google Cloud-Projekt aus, in dem sich der Nutzercluster befindet.
Klicken Sie in der Clusterliste auf den Namen des Clusters, um dessen Details aufzurufen.
Klicken Sie im Bereich Autorisierung auf die Bearbeitungsschaltfläche Administratoren.
Geben Sie im Bereich Autorisierung bearbeiten die E-Mail-Adresse des Nutzers ein, den Sie als Clusteradministrator hinzufügen möchten. Wenn Sie weitere Administratoren hinzufügen möchten, klicken Sie auf Administrator hinzufügen.
Wenn Sie alle gewünschten Nutzer hinzugefügt haben, klicken Sie auf Änderungen speichern.