Administratorcluster mit GKE On-Prem API-Clients erstellen

Console

1. Rufen Sie in der Console die Seite Distributed Cloud-Cluster erstellen auf.

   Zur Seite „Distributed Cloud-Cluster erstellen“

2. Wählen Sie das Google Cloud-Projekt aus, in dem Sie den Cluster erstellen möchten. Das ausgewählte Projekt wird auch als Flotten-Hostprojekt verwendet.

Auf der Seite Voraussetzungen werden die Anforderungen für die Administratorworkstation und die Clusterknotenmaschinen angezeigt. Mit dem IP-Adressplaner im Abschnitt Netzwerkanforderungen können Sie die IP-Adressen planen, die für eine minimale Installation eines Administratorclusters und eines Nutzerclusters erforderlich sind.

Vorbereitung der Administratorworkstation

Maximieren Sie diesen Bereich, um die Hardware-, Betriebssystem- und Verbindungsanforderungen für Ihre Administratorworkstation zu sehen.

Vorbereitung der Clusterknotenmaschinen

Maximieren Sie diesen Bereich, um die Hardware-, Betriebssystem- und Verbindungsanforderungen für die Clusterknotenmaschinen zu sehen.

Netzwerkanforderungen

In diesem Abschnitt erfahren Sie, welche IP-Adressen Sie für eine minimale Umgebung benötigen. Optional können Sie im Abschnitt Knoten-IP-Adressen und virtuelle IP-Adressen eine Startknoten-IP-Adresse und eine virtuelle IP-Adresse (VIP) angeben. In der Console wird dann eine Tabelle mit den erforderlichen IP-Adressen angezeigt. Diese IP-Adressen werden nicht auf die Administratorclusterkonfiguration angewendet. Sie sind als Orientierungshilfe für die Planung der IP-Adressen gedacht, die Sie für Ihre Installation benötigen. Sie können die Tabelle in eine CSV-Datei herunterladen und in eine Tabelle oder ein IP‑Adressplanungstool importieren, um die für Ihre Cluster erforderlichen IP‑Adressen leichter im Blick zu behalten.

Google Cloud-Ressourcen prüfen:

Achten Sie darauf, dass alle erforderlichen Google APIs im Flotten-Hostprojekt aktiviert sind. Außerdem müssen Sie die GKE On-Prem API aktivieren:

gcloud services enable --project FLEET_HOST_PROJECT_ID \
  gkeonprem.googleapis.com

Ersetzen Sie FLEET_HOST_PROJECT_ID durch die Projekt-ID des Flotten-Hostprojekts.

Bevor Sie den Cluster erstellen, führen Sie den Befehl bmctl register bootstrap auf Ihrer Administratorworkstation aus, wie unter Bootstrap-Umgebung vorbereiten beschrieben. Mit diesem Befehl können die erforderlichen Dienstkonten mit den zum Erstellen des Administratorclusters erforderlichen IAM-Mindestberechtigungen erstellt werden. Sie können Dienstkonten auch manuell konfigurieren.

Wenn Sie bereit sind, klicken Sie in der linken Navigationsleiste auf Bootstrap-Umgebung installieren.

gcloud CLI

Voraussetzungen für Hardware, Netzwerk und Betriebssystem

Für das Erstellen eines Administratorclusters mit einem GKE On-Prem API-Client gelten dieselben Hardware-, Netzwerk- und Betriebssystemvoraussetzungen wie beim Erstellen des Clusters mit bmctl. Weitere Informationen finden Sie unter Installationsvoraussetzungen.

Erforderliche Google APIs

Achten Sie darauf, dass alle erforderlichen Google APIs im Flotten-Hostprojekt aktiviert sind. Außerdem müssen Sie die GKE On-Prem API aktivieren:

gcloud services enable --project FLEET_HOST_PROJECT_ID \
  gkeonprem.googleapis.com

Ersetzen Sie FLEET_HOST_PROJECT_ID durch die Projekt-ID des Flotten-Hostprojekts.

Erforderliche Dienstkonten und Berechtigungen

Bevor Sie den Cluster erstellen, führen Sie den Befehl bmctl register bootstrap auf Ihrer Administratorworkstation aus, wie unter Bootstrap-Umgebung vorbereiten beschrieben. Mit diesem Befehl können die erforderlichen Dienstkonten mit den zum Erstellen des Administratorclusters erforderlichen IAM-Mindestberechtigungen erstellt werden. Sie können Dienstkonten auch manuell konfigurieren.

IP-Adressen planen

Bevor Sie den Administratorcluster erstellen, müssen Sie die IP-Adressen für Ihre Cluster planen. Unter IP-Adressen planen finden Sie ein Beispiel für die Zuweisung von IP-Adressen für einen Administratorcluster mit Hochverfügbarkeit (HA) und zwei HA-Nutzercluster. Auch wenn Sie den Administratorcluster mit der gcloud CLI erstellen, sollten Sie die Console-Schritte in diesem Abschnitt ausführen, um den IP‑Adressplaner zu verwenden.

Console

1. Geben Sie einen Namen für den Administratorcluster ein. Der Name des Bootstrap-Clusters wird durch Voranstellen von bootstrap- vor dem Namen des Administratorclusters abgeleitet.

2. Wählen Sie die Google Distributed Cloud-Version für Ihren Administratorcluster aus.

3. Wählen Sie im Feld Standort der Google Cloud API die Google Cloud-Region aus der Liste aus. Diese Einstellung gibt die Region an, in der die folgenden APIs und Dienste ausgeführt werden:

   • GKE On-Prem API (gkeonprem.googleapis.com)
   • Flottendienst (gkehub.googleapis.com)
   • Connect-Dienst (gkeconnect.googleapis.com)

   Mit dieser Einstellung wird auch die Region festgelegt, in der Folgendes gespeichert wird:

   • Die Metadaten des Clusters, die die GKE On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
   • Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
   • Die von Cloud-Audit-Logs erstellten Administrator-Audit-Logs

   Anhand des Clusternamens, des Projekts und des Standorts kann der Cluster in Google Cloud eindeutig identifiziert werden.

4. In der Console werden die Befehle angezeigt, die Sie auf Ihrer Administratorworkstation ausführen müssen. Das bmctl-Befehlszeilentool muss mit der Version des Clusters übereinstimmen, den Sie erstellen. Wenn Sie die entsprechende Version von bmctl bereits auf Ihre Administratorworkstation heruntergeladen haben, müssen Sie sie nicht noch einmal herunterladen.

gcloud CLI

1. Aktualisieren Sie die Komponenten:

   gcloud components update
   

2. Führen Sie den folgenden Befehl aus, um sich mit Ihrem Google-Konto anzumelden:

   gcloud auth login
   

3. Rufen Sie eine Liste der verfügbaren Google Distributed Cloud-Versionen auf, die Sie installieren können. Die bmctl-Version, die Sie zum Erstellen der Bootstrap-Umgebung herunterladen, muss mit der Version übereinstimmen, die Sie auf dem Administratorcluster installieren.

   gcloud container bare-metal admin-clusters query-version-config \
     --location=REGION
   

   Ersetzen Sie REGION durch die Google Cloud-Region, die Sie beim Erstellen des Clusters verwenden. Dies ist die Region, in der die GKE On-Prem API und die Flotten- und Connect-Dienste ausgeführt werden. Geben Sie us-west1 oder eine andere unterstützte Region an.

bmctl erstellt Dienstkonten

Verwenden Sie den folgenden Befehl, wenn bmctl die erforderlichen Dienstkonten mit den zum Erstellen des Administratorclusters erforderlichen Mindestberechtigungen erstellen soll. Bei diesem Befehl wird davon ausgegangen, dass sich bmctl im aktuellen Arbeitsverzeichnis befindet.

./bmctl register bootstrap \
  --ssh-key=YOUR_PRIVATE_KEY \
  --target-cluster-name=ADMIN_CLUSTER_NAME \
  --project-id=FLEET_HOST_PROJECT_ID

Ersetzen Sie Folgendes:

• YOUR_PRIVATE_KEY: der Pfad zum privaten SSH-Schlüssel. Sie haben den SSH-Schlüssel erstellt, als Sie den SSH-Root-Zugriff auf Knoten eingerichtet haben.

Wenn Sie den in der Console angezeigten Befehl kopiert haben, sind die folgenden Felder bereits für Sie ausgefüllt.

• ADMIN_CLUSTER_NAME: der Name Ihres Administratorclusters.

• FLEET_HOST_PROJECT_ID: das Projekt, in dem der Administratorcluster nach der Erstellung automatisch registriert wird.

Mit dem Befehl bmctl register bootstrap werden die folgenden Dienstkonten erstellt. Die Dienstkontoschlüssel werden im Verzeichnis bmctl-workspace/.sa-keys gespeichert.

Dienstkonto-Schlüsseldateien angeben

Alternativ können Sie bmctl die von Ihnen erstellten Dienstkonto-Schlüsseldateien übergeben. Im folgenden Befehl werden die Namen der Schlüsseldateien aus Dienstkonten manuell konfigurieren verwendet. Es wird davon ausgegangen, dass sich bmctl und die Schlüsseldateien im aktuellen Arbeitsverzeichnis befinden.

./bmctl register bootstrap \
  --ssh-key=YOUR_PRIVATE_KEY \
  --target-cluster-name=ADMIN_CLUSTER_NAME \
  --project-id=FLEET_HOST_PROJECT_ID \
  --gcr-service-account-key=anthos-baremetal-gcr.json \
  --gke-agent-service-account-key=connect-agent.json \
  --gke-register-service-account-key=connect-register.json \
  --cloud-operation-service-account-key=anthos-baremetal-cloud-ops.json

Ersetzen Sie Folgendes:

• YOUR_PRIVATE_KEY: der Pfad zum privaten SSH-Schlüssel. Sie haben den SSH-Schlüssel erstellt, als Sie den SSH-Root-Zugriff auf Knoten eingerichtet haben.

• ADMIN_CLUSTER_NAME: der Name Ihres Administratorclusters.

• FLEET_HOST_PROJECT_ID: das Projekt, in dem der Administratorcluster nach der Erstellung automatisch registriert wird.

Mit den folgenden Flags wird der Pfad zu den Schlüsseldateien angegeben:

• -gcr-service-account-key: der Pfad zur Schlüsseldatei für das Dienstkonto, das Container-Images abruft (anthos-baremetal-gcr)

• --gke-agent-service-account-key: der Pfad zur Schlüsseldatei für das Connect Agent-Dienstkonto (anthos-baremetal-connect)

• --gke-register-service-account-key: der Pfad zur Schlüsseldatei für das Connect Agent-Dienstkonto, mit dem der Cluster bei der Flotte registriert wird (anthos-baremetal-register)

• --cloud-operation-service-account-key: der Pfad zur Schlüsseldatei für das Dienstkonto, mit dem Logs geprüft und Projekte überwacht werden (anthos-baremetal-cloud-ops)

Console

1. Klicken Sie auf der Seite Bootstrap-Umgebung installieren auf Verbindung prüfen.

   Bei Erfolg wird in der Consolecheck_circle Verbindung hergestellt angezeigt.

   Die Verbindung zum Bootstrap-Cluster muss hergestellt werden, bevor Sie fortfahren können. Wenn die Verbindung nicht hergestellt wird, prüfen Sie die Argumente, die Sie für den Befehl bmctl register bootstrap angegeben haben:

   • Der Wert für --target-cluster-name muss dem Namen des Administratorclusters entsprechen, der im Abschnitt Grundlagen der Bootstrap-Umgebung angezeigt wird.

   • Der Wert für --project-id muss der ID des Projekts entsprechen, das Sie in der Console ausgewählt haben.

   Wenn Sie den Namen des Bootstrap-Clusters oder die Projekt-ID ändern möchten, geben Sie Ctrl-C ein, um bmctl register bootstrap zu beenden, und führen Sie den Befehl noch einmal aus.

2. Klicken Sie auf Weiter, um mit der Konfiguration des Administratorclusters zu beginnen. Die meisten Einstellungen in der Console entsprechen den Feldern in der Clusterkonfigurationsdatei.

3. Geben Sie unter Knotenkonfiguration für Maximale Podanzahl pro Knoten einen Wert zwischen 64 und 250 ein oder übernehmen Sie den Standardwert 110. Nachdem der Cluster erstellt wurde, können Sie diesen Wert nicht mehr aktualisieren.

   Die maximale Anzahl von Pods pro Knoten (die sogenannte Pod-Dichte) wird auch durch die verfügbaren IP-Ressourcen des Clusters begrenzt. Weitere Informationen finden Sie unter Pod-Netzwerk.

4. Klicken Sie auf Weiter.

5. Legen Sie auf der Seite Netzwerk fest, wie die Knoten und Komponenten im Cluster miteinander und mit der Kubernetes-Steuerungsebene kommunizieren.

   Wenn Sie detaillierte Informationen zu einem Feld aufrufen möchten, bewegen Sie den Mauszeiger auf das zugehörige question_mark.

6. Klicken Sie auf Überprüfen und erstellen.

   Die Console zeigt Statusmeldungen an, während die Einstellungen geprüft und der Cluster in Ihrem Rechenzentrum erstellt wird.

   Wenn bei der Konfiguration ein Fehler auftritt, wird in der Console eine Fehlermeldung angezeigt, die klar genug sein sollte, um das Konfigurationsproblem zu beheben. Versuchen Sie danach noch einmal, den Cluster zu erstellen.

gcloud CLI

Bevor Sie den Administratorcluster erstellen, prüfen Sie, ob der Bootstrap-Cluster als Mitglied der Flotte registriert wurde:

gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

Wenn der Bootstrap-Cluster nicht aufgeführt ist, prüfen Sie den Namen und die Projekt-ID, die Sie für bmctl register bootstrap angegeben haben. Wenn Sie den Namen des Bootstrap-Clusters oder die Projekt-ID ändern möchten, geben Sie Ctrl-C ein, um bmctl register bootstrap zu beenden, und führen Sie den Befehl dann noch einmal aus.

Verwenden Sie den folgenden Befehl, um einen Administratorcluster zu erstellen:

gcloud container bare-metal admin-clusters create

Die meisten Flags, die Sie für den Befehl angeben, entsprechen den Feldern in der Nutzercluster-Konfigurationsdatei.

So erstellen Sie einen Administratorcluster mit dem gebündelten Load Balancer:

gcloud container bare-metal admin-clusters create ADMIN_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --version=VERSION \
  --max-pods-per-node=MAX_PODS_PER_NODE \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LOAD_BALANCER_PORT \
  --control-plane-node-configs 'CONTROL_PLANE_NODE_CONFIG' \
  --island-mode-service-address-cidr-blocks=SERVICE_ADDR_CIDR \
  --island-mode-pod-address-cidr-blocks=POD_ADDR_CIDR \
  --lvp-share-path=/mnt/localpv-share \
  --lvp-share-storage-class=local-shared \
  --lvp-node-mounts-config-path=/mnt/localpv-disk \
  --lvp-node-mounts-config-storage-class=local-disks

Wenn Sie das manuelle Load Balancing verwenden möchten, fügen Sie dem Befehl --enable-manual-lb hinzu.

Ersetzen Sie Folgendes:

• ADMIN_CLUSTER_NAME: der Name Ihres Administratorclusters. Der Name kann nach dem Erstellen des Clusters nicht mehr geändert werden.

• FLEET_HOST_PROJECT_ID: das Projekt, in dem der Administratorcluster nach der Erstellung automatisch registriert wird. Das Flotten-Hostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.

• REGION: die Google Cloud-Region, in der die GKE On-Prem API ausgeführt wird. Geben Sie us-west1 oder eine andere unterstützte Region an. Die Region kann nach dem Erstellen des Clusters nicht mehr geändert werden. Mit dieser Einstellung wird die Region angegeben, in der Folgendes gespeichert wird:

  • Die Clustermetadaten, die die GKE On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
  • Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
  • Die von Cloud-Audit-Logs erstellten Administrator-Audit-Logs

  Anhand des Clusternamens, des Projekts und des Standorts kann der Cluster in Google Cloud eindeutig identifiziert werden.

• VERSION: die Google Distributed Cloud-Version. Die Version muss der bmctl-Version entsprechen, mit der Sie bmctl register bootstrap ausgeführt haben. Sie können die bmctl-Version prüfen, indem Sie auf der Administratorworkstation bmctl version ausführen.

• MAX_PODS_PER_NODE : Zulässige Werte für Administratorcluster sind 32–250 und für Cluster ohne Hochverfügbarkeit 64–250. Wenn --max-pods-per-node nicht im Befehl enthalten ist, lautet der Standardwert 110. Nachdem der Cluster erstellt wurde, kann dieser Wert nicht mehr aktualisiert werden.

  Die maximale Anzahl von Pods pro Knoten (als Pod-Dichte bezeichnet) wird auch durch die verfügbaren IP-Ressourcen des Clusters begrenzt. Weitere Informationen finden Sie unter Pod-Netzwerk.

• CONTROL_PLANE_VIP: die virtuelle IP-Adresse (VIP) auf dem Load Balancer für den Kubernetes API-Server des Clusters. Die virtuelle IP-Adresse der Steuerungsebene muss in dasselbe Subnetz aufgenommen werden wie die Load-Balancer-Knoten. Beziehen Sie die virtuelle IP-Adresse der Steuerungsebene nicht in die Adresspools des Load Balancers ein.

• CONTROL_PLANE_LOAD_BALANCER_PORT: der Port, über den der Load Balancer die Steuerungsebene bereitstellt. Sie können zwar einen anderen Wert konfigurieren, aber Port 443 ist der Standardport für HTTPS-Verbindungen.

• CONTROL_PLANE_NODE_CONFIG: die IPv4-Adresse eines Knotens der Steuerungsebene. Knoten der Steuerungsebene führen die Systemarbeitslast aus. Geben Sie dieses Flag für jeden Knoten der Steuerungsebene an. In der Regel haben Sie eine einzelne Maschine für eine Mindestbereitstellung oder drei Maschinen für eine Bereitstellung mit Hochverfügbarkeit. Geben Sie eine ungerade Anzahl von Knoten an, um ein Mehrheitsquorum für Hochverfügbarkeit zu erhalten. Sie können diese Adressen jederzeit ändern, wenn Sie den Cluster aktualisieren.

  Der Wert für das Flag hat das folgende Format:

  'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  

  Der Wert umfasst Segmente, die mit den Keywords node-ip und labels beginnen. Trennen Sie die einzelnen Segmente durch ein Komma.

  • node-ip: die IP-Adresse eines Knotens der Steuerungsebene. Sie können nur eine node-ip pro Flag festlegen. Wenn Sie mehr als einen Knoten angeben möchten, fügen Sie das Flag für jeden Knoten noch einmal hinzu.

  • labels: ein oder mehrere Schlüssel/Wert-Paare, die an den Knoten angehängt sind.

  Beachten Sie die folgenden Syntaxregeln:

  • Setzen Sie den gesamten Wert in einfache Anführungszeichen.
  • Leerzeichen sind nicht zulässig.
  • Trennen Sie jedes Schlüssel/Wert-Paar im labels-Segment durch ein Semikolon.

  Beispiel:

  --control-plane-node-configs 'node-ip=192.0.2.1' \
  --control-plane-node-configs 'node-ip=192.0.2.2,labels=key2.1=value2.1' \
  --control-plane-node-configs 'node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  

• SERVICE_ADDR_CIDR: ein Bereich von IPv4-Adressen im CIDR-Format für Dienste in Ihrem Cluster. Der CIDR-Bereich muss zwischen /24 und /12 liegen, wobei /12 die meisten IP-Adressen bietet. Wir empfehlen, einen Bereich im IP‑Adressraum für privates Internet zu verwenden, der in RFC 1918 definiert ist, z. B. 10.96.0.0/20.

• POD_ADDR_CIDR: ein Bereich von IPv4-Adressen im CIDR-Format, der für Pods im Nutzercluster verwendet werden soll. Der CIDR-Bereich muss zwischen /18 und /8 liegen, wobei /8 die meisten IP-Adressen bietet. Wir empfehlen, einen Bereich im IP‑Adressraum für privates Internet zu verwenden, der in RFC 1918 definiert ist, z. B. 192.168.0.0/16.

Sie müssen die folgenden Speicher-Flags angeben. Der Beispielbefehl enthält typische Werte. Weitere Informationen finden Sie unter Lokalen Speicher konfigurieren.

• --lvp-share-path: der Pfad zum Hostcomputer, in dem Unterverzeichnisse erstellt werden können. Für jedes Unterverzeichnis wird ein lokales PersistentVolume (PV) erstellt.

• --lvp-share-storage-class: die Speicherklasse, die zum Erstellen von nichtflüchtigen Volumes verwendet werden soll. Die StorageClass wird während der Clustererstellung erstellt.

• --lvp-node-mounts-config-path: der Pfad zum Hostcomputer, in dem bereitgestellte Laufwerke erkannt werden können. Für jede Bereitstellung wird ein lokales PersistentVolume (PV) erstellt.

• --lvp-node-mounts-config-storage: die Speicherklasse, mit der PVs während der Clustererstellung erstellt werden.

Eine vollständige Liste der Flags mit ihren Beschreibungen finden Sie in der Referenz zur gcloud CLI

Die Ausgabe des Befehls sieht in etwa so aus:

Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.

In der Beispielausgabe ist der String operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 der OPERATION_ID des Vorgangs mit langer Ausführungszeit. Sie können den Status des Vorgangs mit dem folgenden Befehl ermitteln:

gcloud container bare-metal operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION

Weitere Informationen finden Sie unter gcloud container bare-metal operations.

Preflight-Fehler beheben

Bevor der Cluster erstellt wird, führt bmctl eine Reihe von Preflight-Prüfungen aus, um die Konfiguration zu überprüfen. Wenn ein Problem mit der Konfiguration vorliegt, wird der Befehl gcloud ... create mit einer Fehlermeldung beendet, die in etwa so aussieht:

ERROR: (gcloud.container.bare-metal.admin-clusters.create) Invalid resource state for "projects/694677185633/locations/us-west1/bareMetalAdminClusters/abm-cluster-1": cluster preflight checks failed

Angenommen, eine Preflight-Prüfung ist fehlgeschlagen, weil der Knoten der Steuerungsebene nicht erreicht werden konnte. Auf der Administratorworkstation könnte dann etwa Folgendes angezeigt werden:

[2023-03-27 20:34:38+0000] Waiting for preflight check job to finish... OK
[2023-03-27 20:35:58+0000] - Validation Category: machines and network
[2023-03-27 20:35:58+0000]    - [PASSED] pod-cidr
[2023-03-27 20:35:58+0000]    - [FAILED] node-network (log: bmctl-workspace/log/register-bootstrap-20230327-201548/node-network)
[2023-03-27 20:35:58+0000]        - Failed to connect to the host via ssh: ssh: connect to host 10.100.0.5 port 22: Connection timed out
[2023-03-27 20:35:58+0000] Flushing logs... OK
[2023-03-27 20:35:58+0000] Error polling the preflight check abm-cluster-mar-27 in the cluster-abm-cluster-mar-27: preflight check failed

1. Prüfen Sie auf der Administratorworkstation, ob der Prozess bmctl register bootstrap noch ausgeführt wird. Ist dies nicht der Fall, führen Sie den Befehl noch einmal mit denselben Argumenten aus und fügen Sie das Flag --reuse-bootstrap-cluster=true hinzu.

2. Führen Sie gcloud ... update aus, um die ungültige IP-Adresse zu korrigieren:

   gcloud container bare-metal admin-clusters update ADMIN_CLUSTER_NAME \
     --project=FLEET_HOST_PROJECT_ID \
     --location=REGION \
     --control-plane-node-configs 'node-ip=NEW_NODE_ID_ADDRESS'
   

   Weitere Informationen finden Sie unter gcloud container bare-metal admin-clusters update.