Einfache Installation auf Ihrer Hardware planen

Diese Seite ist der erste Teil eines Leitfadens, der Sie durch die Verwendung der Google Distributed Cloud-Software (ehemals Google Distributed Cloud) führt, um eine kleine Proof-of-Concept-Installation von GKE-Clustern auf Ihrer Bare-Metal-Hardware zu erstellen. In diesem Dokument erfahren Sie, wie Sie eine minimale Hardwareumgebung einrichten und Ihre IP-Adressen planen. Im nachfolgenden Abschnitt Einfache Cluster erstellen erfahren Sie, wie Sie einen Administrator- und einen Nutzercluster erstellen.

Diese Seite richtet sich an Administratoren, Architekten und Operatoren, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur einrichten, überwachen und verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Gängige GKE Enterprise-Nutzerrollen und ‑Aufgaben.

Die Infrastruktur, die Sie mit dieser Anleitung einrichten, ist möglicherweise nicht für Ihre tatsächlichen Produktionsanforderungen und Anwendungsfälle geeignet. Weitere Informationen zu Produktionsinstallationen finden Sie unter Bereitstellungsmodell auswählen.

Hinweise

  1. Informationen zu Google Distributed Cloud
  2. Machen Sie sich mit einigen grundlegenden Google Cloud-Konzepten vertraut, einschließlich Projekten, IAM-Berechtigungen und Dienstkonten.
  3. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  5. Make sure that billing is enabled for your Google Cloud project.

  6. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  7. Make sure that billing is enabled for your Google Cloud project.

  8. Notieren Sie sich die Google Cloud-Projekt-ID, da sie später benötigt wird.

Verfahrensübersicht

Eine minimale Infrastruktureinrichtung besteht aus diesen Hauptschritten:

  1. Richten Sie Ihre Administrator-Workstation ein. Richten Sie eine Linux-Administratorworkstation für lokale Verwaltungsaufgaben ein. Dies kann eine vorhandene oder eine dedizierte Maschine sein, die mehrere Cluster verwalten kann.

  2. Richten Sie Ihre Clusterknoten-Rechner ein. Erstellen Sie mindestens drei Maschinen für Knoten: einen Knoten des Administratorclusters, einen Knoten der Steuerungsebene des Nutzerclusters und einen Worker-Knoten des Nutzerclusters.

  3. Netzwerk planen Planen Sie die IP-Adressen für Ihre Knotenmaschinen, virtuellen IP-Adressen (VIPs) und Dienst- und Pod-CIDR-Bereiche.

  4. Erforderliche Google Cloud-Ressourcen prüfen Zum Erstellen von Clustern erfordert Ihr Google Cloud-Projekt bestimmte Google APIs und Dienstkonten.

1. Administrator-Workstation einrichten

Die Administrator-Workstation hostet Tools und Konfigurationsdateien zum Erstellen und Arbeiten mit Ihren Clustern.

Hardwareanforderungen

Die Administrator-Workstation benötigt erhebliche Rechenleistung, Arbeitsspeicher und Speicher, um Tools auszuführen und die Ressourcen für die Clustererstellung und -verwaltung zu speichern.

Achten Sie darauf, dass Ihre Administrator-Workstation die folgenden Hardwareanforderungen erfüllt:

  • Mindestens 2 CPU-Kerne
  • Mindestens 4 GiB RAM
  • Mindestens 128 GiB Speicherplatz

Anforderungen an das Betriebssystem

Zum Ausführen von bmctl und zum Erstellen eines Clusters hat die Administrator-Workstation dieselben Betriebssystemanforderungen wie Knoten. Auf jeder Maschine muss eine unterstützte Version von Ubuntu ausgeführt werden.

Betriebssystem und Software konfigurieren

Auf der Administrator-Workstation installieren und Folgendes konfigurieren:

  • Ubuntu konfigurieren

  • gcloud-CLI installieren

  • Installierenkubectl

  • Installierenbmctl

Betriebssystem konfigurieren

Führen Sie die folgenden Befehle aus, um die Firewalleinstellungen zu aktualisieren, Docker zu installieren und zu konfigurieren und dafür zu sorgen, dass jede Maschine die Zeitsynchronisierung verwendet:

  1. Deaktivieren Sie Unkomplizierte Firewall (UFW) und prüfen Sie ihren Status:

    sudo ufw disable
sudo ufw status

  2. Entfernen Sie alle vorherigen Docker-Versionen, aktualisieren Sie Ihren Paketmanager und installieren Sie die neueste Version von Docker:

    sudo apt-get remove docker docker-engine docker.io containerd runc
sudo apt-get update
sudo apt-get install \
  apt-transport-https \
  ca-certificates \
  curl \
  gnupg-agent \
  software-properties-common \
  docker.io

  3. Prüfen Sie, ob Sie jetzt die Docker-Version 19.03 oder höher verwenden:

    sudo docker version

    Sowohl die Client- als auch die Serverversion sollten mindestens 19.03 sein, wie in der folgenden Beispielantwort gezeigt:

    Client:
 Version:           20.10.21
 API version:       1.41
 Go version:        go1.18.1
 ...

Server:
 Engine:
  Version:          20.10.21
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.1
  ...

  4. Erstellen Sie die Gruppe docker.

    sudo groupadd docker

  5. Fügen Sie sich selbst der Docker-Gruppe hinzu:

    sudo usermod -aG docker $USER

  6. Führen Sie den folgenden Befehl aus, um Ihre Gruppenänderungen zu aktivieren:

    newgrp docker

  7. Führen Sie den folgenden Befehl aus, um zu prüfen, ob die Systemuhr synchronisiert ist:

    timedatectl

    Die Ausgabe von timedatectl sollte den folgenden Status enthalten:

    System clock synchronized: yes

Google Cloud CLI installieren

Folgen Sie der Anleitung in dieser Installationsanleitung, um die Google Cloud CLI unter Ubuntu zu installieren.

Führen Sie die folgenden Schritte auf Ihrer Administrator-Workstation aus, um die gcloud CLI zu konfigurieren:

  1. Melden Sie sich an, um das account-Attribut der gcloud CLI festzulegen:

    gcloud auth login

  2. Legen Sie das project-Attribut der gcloud CLI fest:

    gcloud config set project PROJECT_ID

    Ersetzen Sie PROJECT_ID durch die ID Ihres Google Cloud-Projekts.

  3. Prüfen Sie, ob die Attribute account und project richtig eingestellt sind:

    gcloud config list

    Die Ausgabe zeigt die Werte Ihrer Attribute account und project. Beispiel:

    [core]
account = my-name@google.com
disable_usage_reporting = False
project = my-project-1234
Your active configuration is: [default]

kubectl installieren

So installieren Sie kubectl:

  1. Führen Sie den folgenden Befehl auf Ihrer Administrator-Workstation aus:

    gcloud components install kubectl

bmctl installieren

bmctl ist das proprietäre Befehlszeilentool für Google Distributed Cloud, das Sie zum Erstellen und Verwalten von Clustern verwenden können.

So installieren Sie bmctl auf Ihrer Administrator-Workstation:

  1. Erstellen Sie ein baremetal-Verzeichnis und fügen Sie es Ihrem Pfad hinzu. Wenn Sie sich in Ihrem Basisverzeichnis befinden, lauten die Befehle so:

    mkdir baremetal
export PATH="$HOME/baremetal:$PATH"

  2. Führen Sie den folgenden Befehl aus, um die neueste Version der Binärdatei bmctl herunterzuladen und ausführbar zu machen:

    gcloud storage cp gs://anthos-baremetal-release/bmctl/1.30.100-gke.96/linux-amd64/bmctl .
chmod +x ./bmctl

  3. Prüfen Sie, ob bmctl installiert und ausführbar ist:

    bmctl version

    Die Antwort sollte in etwa so aussehen:

    [2023-05-12 17:36:16+0000] bmctl version: 1.14.2-gke.11, git commit: 4ff1347446a93925a079000b50437d4ecebcdf3a, build date: Mon Feb 27 14:07:30 PST 2023

Verbindung

Die Administrator-Workstation benötigt Zugriff auf Google Cloud und alle Clusterknoten.

Zugriff auf Google Cloud

Die Administrator-Workstation greift auf Google Cloud zu, um Tools und Images herunterzuladen und zu installieren, Autorisierungsanfragen zu verarbeiten, Dienstkonten zu erstellen sowie Logging und Monitoring zu verwalten. Sie können keine Cluster ohne Zugriff auf Google Cloud erstellen.

Zugriff über die Administrator-Workstation

Zum Erstellen und Verwalten von Clustern über Ihre Administrator-Workstation benötigen Sie den folgenden Zugriff auf die Knotenmaschinen:

  • Es muss eine Ebene-3-Verbindung zu allen Clusterknoten-Rechnern existieren.
  • Zugriff auf die VIP der Steuerungsebene.
  • Passwortloser SSH-Zugriff auf alle Clusterknoten-Rechner als root oder als Nutzer mit passwortlosen sudo-Berechtigungen.

Der folgende Abschnitt enthält eine Anleitung zum Einrichten von SSH auf der Administrator-Workstation und den Knotenrechnern.

2. Clusterknoten-Rechner einrichten

Für die minimale Installation eines einzelnen Administratorclusters mit hoher Verfügbarkeit und eines einzelnen Nicht-Hochverfügbarkeits-Nutzerclusters benötigen Sie drei Maschinen:

  • Eine Maschine für einen Administratorcluster mit einem Knoten der Steuerungsebene.

  • Zwei Maschinen für einen Nutzercluster mit einem Knoten für die Steuerungsebene und einem Worker-Knoten.

Hardwareanforderungen

Jede Knoten-Maschine muss die folgenden Hardwareanforderungen erfüllen:

  • Mindestens 2 CPU-Kerne
  • Mindestens 4 GiB RAM
  • Mindestens 128 GiB Speicherplatz

Anforderungen an das Betriebssystem

Auf jeder Knotenmaschine muss eine unterstützte Version von Ubuntu ausgeführt werden.

Ubuntu konfigurieren

Konfigurieren Sie Ubuntu auf jedem Knoten mit derselben Anleitung, die für die Administrator-Workstation verwendet wurde.

SSH-Zugriff auf Knoten einrichten

Die Administrator-Workstation benötigt passwortlosen SSH-Zugriff auf alle Clusterknoten-Rechner. Sie können SSH als root oder mit einem Nutzer mit passwortlosen sudo-Berechtigungen einrichten.

Dies sind die allgemeinen Schritte zum Einrichten von SSH für Google Distributed Cloud:

  1. SSH auf allen Computern installieren und konfigurieren

  2. SSH-Schlüssel erstellen und den öffentlichen Schlüssel auf jede Knotenmaschine kopieren

  3. Passwortauthentifizierung auf Knotenrechnern deaktivieren

  4. SSH-Zugriff zwischen Administrator-Workstation und Knotenrechnern prüfen

SSH auf allen Computern installieren und konfigurieren

Google Distributed Cloud erfordert eine passwortlose SSH-Kommunikation zwischen der Administrator-Workstation und den Clusterknoten. Die folgenden Schritte müssen auf der Administrator-Workstation und jeder Knotenmaschine ausgeführt werden.

So konfigurieren Sie SSH auf Maschinen, auf denen Ubuntu ausgeführt wird:

  1. Installieren Sie einen SSH-Server, wenn noch keiner vorhanden ist:

    sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh

  2. Aktivieren Sie die SSH-Passwortauthentifizierung root, indem Sie die Kommentarzeichen bei der Datei /etc/ssh/sshd_config entfernen oder die Zeilen PermitRootLogin und PasswordAuthentication hinzufügen und die Werte auf yes setzen:

    # Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
...
PasswordAuthentication yes

  3. Root-Passwort festlegen:

    sudo passwd root

  4. Starten Sie den SSH-Dienst neu, um die Änderungen an der SSH-Konfiguration anzuwenden:

    sudo systemctl restart ssh.service

  5. Starten Sie das Gerät neu.

  6. Um zu prüfen, ob SSH funktioniert, stellen Sie eine SSH-Verbindung von einem anderen Computer aus her.

SSH-Schlüssel erstellen und den öffentlichen Schlüssel auf jede Knotenmaschine kopieren

Für sichere, passwortlose Verbindungen zwischen der Administrator-Workstation und den Knoten erstellen Sie einen SSH-Schlüssel auf Ihrer Administrator-Workstation und geben den öffentlichen Schlüssel für die Knoten frei.

  1. Generieren Sie auf Ihrer Administrator-Workstation ein privates und öffentliches Schlüsselpaar. Legen Sie keine Passphrase für die Schlüssel fest:

    ssh-keygen -t rsa

  2. Kopieren Sie auf Ihrer Administrator-Workstation den generierten öffentlichen Schlüssel auf jede Knotenmaschine:

    ssh-copy-id -i PUBLIC_KEY root@CLUSTER_NODE_IP

    Ersetzen Sie Folgendes:

    • PUBLIC_KEY: Der Pfad zur Datei mit dem öffentlichen SSH-Schlüssel. Der Pfad ist standardmäßig /home/USERNAME/.ssh/id_rsa.pub
    • CLUSTER_NODE_IP: die IP-Adresse der Knotenmaschine
Passwortauthentifizierung auf Knotenrechnern deaktivieren

Zu diesem Zeitpunkt muss die Passwortauthentifizierung nicht mehr aktiviert sein.

Für jede Knotenmaschine:

  1. Öffnen Sie /etc/ssh/sshd_config, setzen Sie PasswordAuthentication auf no und speichern Sie die Datei.

  2. Starten Sie den SSH-Dienst neu.

    sudo systemctl restart ssh.service
SSH-Zugriff zwischen Administrator-Workstation und Knotenrechnern prüfen

Wenn SSH ordnungsgemäß konfiguriert ist, können Sie von der Administrator-Workstation (als Root) aus ohne Passwort eine SSH-Verbindung zur Knotenmaschine herstellen.

So prüfen Sie, ob die Authentifizierung mit öffentlichem Schlüssel zwischen Ihrer Administrator-Workstation und Ihren Clusterknoten funktioniert:

  1. Führen Sie auf der Administrator-Workstation den folgenden Befehl für jede Knotenmaschine aus:

    ssh -o IdentitiesOnly=yes -i PRIVATE_KEY root@CLUSTER_NODE_IP

    Ersetzen Sie Folgendes:

    • PRIVATE_KEY: Pfad zur Datei mit dem privaten SSH-Schlüssel. Der Pfad ist standardmäßig /home/USERNAME/.ssh/id_rsa
    • CLUSTER_NODE_IP: die IP-Adresse der Knotenmaschine

3. Netzwerk planen

Bei der Installation von Clustern ist es wichtig, dass Sie Ihre IP-Adressen planen und dafür sorgen, dass keine Adressenkonflikte auftreten. Möglicherweise benötigen Sie Ihren Netzwerkadministrator, um geeignete Adressen zu finden, auch für diese einfache Installation. Wenn Pods und Dienst-CIDRs nicht gezählt werden, benötigen Sie mindestens 15 eindeutige IP-Adressen für eine Mindestinstallation von Administratorclustern und Nutzerclustern.

Planen und geben Sie IP-Adressen für die folgenden Clusterkomponenten an:

  • Clusterknoten: Sie benötigen eine IP-Adresse für jede Knotenmaschine
  • Virtuelle IP-Adressen (VIPs): Sie benötigen VIPs für den Zugriff auf die Kubernetes API-Server, den Ingress-Proxy und Dienste vom Typ LoadBalancer
  • Pods und Dienste: Sie benötigen CIDR-Adressbereiche, um jeden Pod und Service zu berücksichtigen, der in Ihren Clustern ausgeführt wird.

Der Rest dieses Abschnitts enthält anschauliche Beispiele für Werte, die für diese Installation in einem hypothetischen Netzwerk funktionieren – Ihre Werte werden anders lauten.

Für diese kleine Installation platzieren Sie Ihre Administrator-Workstation, den Administratorclusterknoten und die Nutzerclusterknoten in derselben Ebene-2-Domain. Angenommen, alle IP-Adressen im Bereich 172.16.20.0/24 werden an eine bestimmte Ebene-2-Domain weitergeleitet. Angenommen, Ihr Netzwerkadministrator besagt, dass Sie 172.16.20.10 – 172.16.20.12 für Knotenmaschinenadressen und 172.16.0.13 – 172.16.20.24 für VIPs verwenden können.

Das folgende Diagramm zeigt eine Ebene-2-Domain mit einer Administrator-Workstation, einem Administratorcluster und einem Nutzercluster:

IP-Adressen für einen Administrator- und einen Nutzercluster.
IP-Adressen für einen Administrator- und einen Nutzercluster (zum Vergrößern klicken)

Beispiel-IP-Adressen für Clusterknoten

Die folgende Tabelle enthält ein Beispiel für die Verwendung von IP-Adressen für Clusterknoten:

Maschine Beschreibung IP-Adresse
Knoten der Steuerungsebene des Administratorclusters Physische Maschine, die als Knoten der Steuerungsebene für den Administratorcluster dient 172.16.20.10
Knoten der Steuerungsebene des Nutzerclusters Physische Maschine, die als Knoten der Steuerungsebene für den Nutzercluster dient 172.16.20.11
Worker-Knoten des Nutzerclusters Physische Maschine, auf der Nutzerarbeitslasten ausgeführt werden 172.16.20.12

Beispiele für virtuelle IP-Adressen (VIPs)

Die folgende Tabelle enthält ein Beispiel dafür, wie Sie VIPs für Ihre Cluster angeben können:

VIP Beschreibung IP-Adresse
Virtuelle IP-Adresse der Steuerungsebene des Administratorclusters Virtuelle IP-Adresse der Steuerungsebene des Administratorclusters (Kubernetes API-Server des Administratorclusters) 172.16.20.13
Virtuelle IP-Adresse der Steuerungsebene des Nutzerclusters Virtuelle IP-Adresse der Steuerungsebene des Nutzerclusters (Kubernetes API-Server des Nutzerclusters) 172.16.20.14
Virtuelle IP-Adresse für eingehenden Traffic Virtuelle IP-Adresse für eingehenden Traffic (im MetalLB-Adresspoolbereich enthalten) 172.16.20.15
Virtuelle IP-Adressen des Dienstes Zehn Adressen zur Verwendung als externe IP-Adressen für Dienste vom Typ LoadBalancer. Adressen werden nach Bedarf auf Nutzerclusterknoten zugewiesen.

Dieser Bereich enthält die Ingress-VIP. Diese Überschneidung von IP-Adressen ist eine Anforderung für den standardmäßigen gebündelten Load-Balancer MetalLB.

 172.16.20.15 - 172.16.20.24

IP-Adressen für Pods und Dienste

Zusätzlich zu den IP-Adressen, die Sie für Clusterknoten und VIPs angegeben haben, müssen Sie Adressen für Pods und Dienste angeben. Sie geben einen CIDR an, der für Pod-IP-Adressen verwendet werden soll, und einen weiteren CIDR-Bereich, der für die ClusterIP-Adressen von Kubernetes-Diensten verwendet wird. Verwenden Sie IP-Adressen im privaten Adressbereich, wie in RFC 1918 beschrieben. Diese Adressen werden im Rahmen der Clusterkonfiguration angegeben, wie im nächsten Teil dieser Anleitung dargestellt.

Entscheiden Sie im Rahmen der IP-Planung, welche CIDR-Bereiche Sie für Pods und Dienste verwenden möchten. Wenn Sie keinen anderen Grund haben, verwenden Sie die folgenden vorgeschlagenen Bereiche:

Zweck Vorab ausgefüllter CIDR-Bereich
Administratorcluster-Pods 192.168.0.0/16
Dienste des Administratorclusters 10.96.0.0/20
Nutzercluster-Pods 192.168.0.0/16
Nutzercluster-Dienste 10.96.0.0/20

Die vorgeschlagenen Bereiche veranschaulichen diese Punkte:

  • Der Pod-CIDR-Bereich kann für mehrere Cluster im Standard-Netzwerkmodell im Inselmodus identisch sein.

  • Der Service-CIDR-Bereich kann für mehrere Cluster identisch sein.

  • In der Regel benötigen Sie mehr Pods als Dienste in einem Cluster. Daher benötigen Sie wahrscheinlich einen Pod-CIDR-Bereich, der größer als der Dienst-CIDR-Bereich ist. Der vorgeschlagene Pod-Bereich für einen Nutzercluster hat beispielsweise 2(32-16) = 216 Adressen, aber der vorgeschlagene Dienstbereich für einen Nutzercluster hat nur 2(32-20) = 212 Adressen.

Überlappung vermeiden

Verwenden Sie möglicherweise andere CIDR-Bereiche als die vorherigen Vorschläge, um eine Überschneidung mit IP-Adressen zu vermeiden, die in Ihrem Netzwerk erreichbar sind. Die Dienst- und Pod-Bereiche dürfen sich nicht mit einer Adresse außerhalb des Clusters überschneiden, die Sie von innerhalb des Clusters erreichen möchten.

Angenommen, Ihr Dienstbereich lautet 10.96.232.0/24 und Ihr Pod-Bereich ist 192.168.0.0/16. Traffic, der von einem Pod an eine Adresse in einem dieser Bereiche gesendet wird, wird als clusterintern behandelt und kann kein Ziel außerhalb des Clusters erreichen.

Insbesondere dürfen sich die Bereiche für Dienste und Pods nicht überschneiden mit:

  • IP-Adressen von Knoten in einem beliebigen Cluster

  • Von Load-Balancer-Maschinen verwendete IP-Adressen

  • Von Knoten der Steuerungsebene und Load-Balancern verwendete VIPs

  • IP-Adresse von DNS-Servern oder NTP-Servern

4. Erforderliche Google Cloud-Ressourcen prüfen

Bevor Sie Cluster erstellen können, muss für Google Distributed Cloud ein bestimmter Satz von Google APIs in Ihrem verknüpften Google Cloud-Projekt aktiviert sein. Zur Verwendung der Google APIs erfordert Google Distributed Cloud Dienstkonten, die mit bestimmten IAM-Rollen in Ihrem verknüpften Google Cloud-Projekt konfiguriert sind.

Der Prozess zum Erstellen von Clustern im nächsten Teil dieser Anleitung (Einfache Cluster erstellen) aktiviert APIs und erstellt automatisch Dienstkonten.

Folgende Google APIs sind automatisch aktiviert:

  • anthos.googleapis.com
  • anthosaudit.googleapis.com
  • anthosgke.googleapis.com
  • cloudresourcemanager.googleapis.com
  • connectgateway.googleapis.com
  • container.googleapis.com
  • gkeconnect.googleapis.com
  • gkehub.googleapis.com
  • gkeonprem.googleapis.com
  • iam.googleapis.com
  • logging.googleapis.com
  • monitoring.googleapis.com
  • opsconfigmonitoring.googleapis.com
  • serviceusage.googleapis.com
  • stackdriver.googleapis.com
  • storage.googleapis.com

In der folgenden Tabelle werden die Dienstkonten beschrieben, die automatisch erstellt werden:

Dienstkonto Zweck Rollen
anthos-baremetal-gcr Google Distributed Cloud verwendet dieses Dienstkonto, um Container-Images aus Container Registry herunterzuladen. Keine
anthos-baremetal-connect Connect Agent verwendet dieses Dienstkonto, um eine Verbindung zwischen Ihrem Cluster und Google Cloud aufrechtzuerhalten Dies ermöglicht den Zugriff auf den Cluster- und auf Arbeitslastverwaltungsfunktionen, einschließlich der Google Cloud Console und des Connect-Gateways für die Interaktion mit Ihrem Cluster. roles/gkehub.connect
anthos-baremetal-register Connect Agent verwendet dieses Dienstkonto, um Ihre Cluster bei einer Flotte zu registrieren. roles/gkehub.admin
anthos-baremetal-cloud-ops Stackdriver Agent verwendet dieses Dienstkonto, um Logs und Messwerte von Clustern nach Cloud Logging und Cloud Monitoring zu exportieren. roles/logging.logWriter
roles/monitoring.metricWriter
roles/stackdriver.resourceMetadata.writer
roles/opsconfigmonitoring.resourceMetadata.writer
roles/monitoring.dashboardEditor

Nächste Schritte

Einfache Cluster erstellen