Administratorcluster mit GKE On-Prem API-Clients erstellen

Auf dieser Seite wird beschrieben, wie Sie einen Administratorcluster mit der Google Cloud Console oder der Google Cloud CLI (gcloud CLI) erstellen. Diese beiden standardmäßigen Google Cloud-Clients verwenden die GKE On-Prem API, um den Cluster zu erstellen.

Was ist die GKE On-Prem API?

Die GKE On-Prem API ist eine von Google Cloud gehostete API, mit der Sie den Lebenszyklus Ihrer lokalen Cluster mithilfe von Terraform und Google Cloud-Standardanwendungen verwalten können. Die GKE On-Prem API wird in der Infrastruktur von Google Cloud ausgeführt. Terraform, die Console und die gcloud CLI sind Clients der API. Sie verwenden die API, um Cluster in Ihrem Rechenzentrum zu erstellen.

Zum Verwalten des Lebenszyklus Ihrer Cluster muss die GKE On-Prem API Metadaten zum Status Ihres Clusters in Google Cloud speichern. Dazu verwendet sie die Google Cloud-Region, die Sie beim Erstellen des Clusters angeben. Diese Metadaten ermöglichen der API die Verwaltung des Clusterlebenszyklus und enthalten keine arbeitslastspezifischen Daten.

Wenn Sie einen Cluster mit einem GKE On-Prem API-Client erstellen, geben Sie ein Google Cloud-Projekt an. Nachdem der Cluster erstellt wurde, wird er automatisch bei der Flotte des angegebenen Projekts registriert. Dieses Projekt wird als Flotten-Hostprojekt bezeichnet. Das Flotten-Hostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.

Wenn Sie möchten, können Sie einen Administratorcluster erstellen, indem Sie eine Konfigurationsdatei für den Administratorcluster erstellen und bmctl verwenden, wie unter Administratorcluster erstellen beschrieben.

Wenn Sie die Console oder die gcloud CLI zum Verwalten des Lebenszyklus von Clustern verwenden möchten, die mit bmctl erstellt wurden, finden Sie unter Cluster konfigurieren, die von der GKE On-Prem API verwaltet werden sollen weitere Informationen.

IAM-Berechtigungen

Wenn Sie kein Google Cloud-Project Owner sind, muss Ihnen ein Project Owner die folgenden Rollen zuweisen:

Wenn Sie auf die Seiten „GKE Enterprise“ und „GKE“ in der Console zugreifen möchten, benötigen Sie außerdem die Rolle roles/container.viewer.

Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Befehlszeilenzugriff

Wenn Sie nach dem Erstellen des Clusters das Connect-Gateway verwenden möchten, um für den Cluster kubectl-Befehle auf anderen Computern als der Administrator-Workstation auszuführen, installieren Sie die folgenden Befehlszeilentools auf dem Computer, den Sie verwenden möchten.

  • Die neueste Version der gcloud CLI.

  • kubectl zum Ausführen von Befehlen für Kubernetes-Cluster. Falls Sie kubectl installieren müssen, folgen Sie dieser Anleitung.

Client zum Erstellen des Administratorclusters auswählen

Sie können entweder die Console oder die gcloud CLI verwenden, um einen Admin-Cluster zu erstellen, der von der GKE On-Prem API verwaltet wird. Wenn Sie Google Distributed Cloud zum ersten Mal installieren, ist die Console möglicherweise einfacher zu verwenden als die gcloud CLI.

Nachdem Sie sich mit den Informationen vertraut gemacht haben, die Sie zum Erstellen von Clustern angeben müssen, eignet sich möglicherweise die gcloud CLI besser, da Sie den Befehl mit seinen Argumenten in einer Textdatei speichern können. Wenn Sie ein CI/CD-Tool wie Cloud Build verwenden, können Sie die gcloud-Befehle zum Erstellen eines Clusters und zum Angeben des Flags --impersonate-service-account verwenden, um die Erstellung zu automatisieren.

Vorbereitung

Console

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

    Zur Seite „Google 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 Ihre Administrator-Workstation und 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 Administrator-Workstation aufzurufen.

Vorbereitung der Clusterknotenmaschinen

Maximieren Sie diesen Bereich, um die Hardware-, Betriebssystem- und Verbindungsanforderungen für die Clusterknotencomputer aufzurufen.

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- 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 dienen als Leitfaden für die Planung der IP-Adressen, 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 zu verfolgen.

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 Flottenhostprojekts.

Bevor Sie den Cluster erstellen, führen Sie den Befehl bmctl register bootstrap auf Ihrer Administrator-Workstation aus, wie unter Bootstrap-Umgebung vorbereiten beschrieben. Mit diesem Befehl können die erforderlichen Dienstkonten mit den für das Erstellen des Administratorclusters erforderlichen IAM-Berechtigungen 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 Flottenhostprojekts.

Erforderliche Dienstkonten und Berechtigungen

Bevor Sie den Cluster erstellen, führen Sie den Befehl bmctl register bootstrap auf Ihrer Administrator-Workstation aus, wie unter Bootstrap-Umgebung vorbereiten beschrieben. Mit diesem Befehl können die erforderlichen Dienstkonten mit den für das Erstellen des Administratorclusters erforderlichen IAM-Berechtigungen 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 Schritte in diesem Abschnitt zur Verwendung des IP‑Adressplaners ausführen.

Bootstrap-Umgebung vorbereiten

Bevor Sie den Administratorcluster erstellen, müssen Sie den Befehl bmctl register bootstrap auf Ihrer Administrator-Workstation ausführen. Mit diesem Befehl wird ein Kubernetes in Docker-Cluster (kind) auf der Administrator-Workstation bereitgestellt. Dieser Bootstrap-Cluster hostet die Kubernetes-Controller, die zum Erstellen des Administratorclusters erforderlich sind. Wenn Sie den Administratorcluster erstellen, stellen die Controller im Bootstrap-Cluster Knoten bereit, führen Preflight-Prüfungen aus und registrieren den Administratorcluster bei der Flotte. Der Bootstrap-Cluster wird automatisch gelöscht, nachdem der Cluster erfolgreich erstellt wurde.

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.

  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

    Clustername, Projekt und Standort identifizieren den Cluster in Google Cloud eindeutig.

  4. In der Console werden die Befehle angezeigt, die Sie auf Ihrer Administrator-Workstation 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 Administrator-Workstation 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. Liste der verfügbaren Google Distributed Cloud-Versionen, 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.

Bootstrap-Cluster erstellen

Führen Sie die folgenden Schritte auf Ihrer Administrator-Workstation aus. Diese Befehle werden in der Console angezeigt.

  1. Legen Sie Ihre Nutzeranmeldedaten als Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) fest:

    gcloud auth application-default login

    Folgen Sie den Anweisungen, um Ihr Google-Konto für ADC auszuwählen.

  2. Laden Sie bei Bedarf das bmctl-Befehlszeilentool in das aktuelle Arbeitsverzeichnis herunter.

    gcloud storage cp gs://anthos-baremetal-release/bmctl/VERSION/linux-amd64/bmctl .
chmod a+x ./bmctl

    Ersetzen Sie VERSION durch die Version von Google Distributed Cloud, die Sie installieren möchten. Wenn Sie den Befehl aus der Console kopiert haben, ist die Version bereits im Befehl enthalten.

  3. Erstellen Sie den Bootstrap-Cluster. Sie können entweder bmctl die erforderlichen Dienstkonten erstellen lassen oder die Dienstkonten und Schlüsseldateien selbst erstellen und an den Befehl bmctl register bootstrap übergeben.

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:

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, bei 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 Zweck IAM-Rollen
anthos-baremetal-gcr Google Distributed Cloud verwendet dieses Dienstkonto, um Container-Images aus Google Container Registry herunterzuladen. Ohne
anthos-baremetal-connect Connect Agent verwendet dieses Dienstkonto, um eine Verbindung zwischen Ihrem Cluster und Google Cloud aufrechtzuerhalten roles/gkehub.connect
anthos-baremetal-register Connect Agent verwendet dieses Dienstkonto, um Ihre Cluster bei der Google Cloud-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

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, bei 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, um Logs zu prüfen und Projekte zu überwachen (anthos-baremetal-cloud-ops).

Nachdem bmctl den Bootstrap-Cluster erfolgreich erstellt hat, wird eine Ausgabe ähnlich der folgenden angezeigt:

[2023-03-22 17:35:24+0000] Waiting for the temporary cluster to be registered... OK
[2023-03-22 17:35:37+0000] Please go to https://console.cloud.google.com/home/dashboard?project=example-project-12345 to create the cluster
[2023-03-22 17:35:37+0000] Waiting for preflight checks and cluster to run..

Erstellen Sie den Administratorcluster.

Console

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

    Bei Erfolg wird in der Console 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 mit dem Namen des Administratorclusters übereinstimmen, der im Abschnitt Grundlagen der Bootstrap-Umgebung angezeigt wird.

    • Der Wert für --project-id muss mit der ID des Projekts übereinstimmen, 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 in Maximale Anzahl Pods 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 daneben.

  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 des Bootstrap-Clusters 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 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 Konfigurationsdatei für den Nutzercluster.

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, bei 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 ist:

    • 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

    Clustername, Projekt und Standort identifizieren den Cluster in Google Cloud eindeutig.

  • 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 Administrator-Workstation bmctl version ausführen.

  • MAX_PODS_PER_NODE : Für Administratorcluster sind zulässige Werte 32–250 und für Cluster ohne HA sind 64–250 zulässig. Wenn --max-pods-per-node nicht im Befehl enthalten ist, ist der Standardwert 110. Sobald der Cluster erstellt ist, kann dieser Wert nicht mehr aktualisiert werden.

    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.

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

  • CONTROL_PLANE_LOAD_BALANCER_PORT: der Port, über den der Load Balancer die Steuerungsebene bedient. Sie können zwar einen anderen Wert konfigurieren, Port 443 ist jedoch 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 handelt es sich dabei entweder um 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 Kommas.

    • 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 dem Knoten zugeordnet 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: Dies ist 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: Dies ist die StorageClass, die zum Erstellen von nichtflüchtigen Volumes verwendet werden soll. Die StorageClass wird während der Clustererstellung erstellt.

  • --lvp-node-mounts-config-path: Dies ist der Pfad des Hostcomputers, 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 wie der folgenden beendet:

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 Administrator-Workstation wird in etwa Folgendes angezeigt:

[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 Administrator-Workstation, ob der Prozess bmctl register bootstrap noch ausgeführt wird. Falls nicht, 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.

Details zum Clustererstellungsprozess werden auf Ihrer Administrator-Workstation ausgegeben. Wenn die Preflight-Prüfungen erfolgreich sind, sehen Sie in etwa Folgendes:

[2023-03-22 23:12:47+0000] Waiting for cluster kubeconfig to become ready OK
[2023-03-22 23:15:47+0000] Writing kubeconfig file
[2023-03-22 23:15:47+0000] kubeconfig of cluster being created is present at bmctl-workspace/abm-cluster-1/abm-cluster-1-kubeconfig
[2023-03-22 23:15:47+0000] Please restrict access to this file as it contains authentication credentials of your cluster.
[2023-03-22 23:15:47+0000] Waiting for cluster to become ready OK
[2023-03-22 23:20:17+0000] Please run
[2023-03-22 23:20:17+0000] kubectl --kubeconfig bmctl-workspace/abm-cluster-1/abm-cluster-1-kubeconfig get nodes
[2023-03-22 23:20:17+0000] to get cluster nodes status.
[2023-03-22 23:20:17+0000] Waiting for node pools to become ready OK
[2023-03-22 23:20:37+0000] Waiting for metrics to become ready in GCP OK
[2023-03-22 23:25:38+0000] Waiting for cluster API provider to install in the created admin cluster OK
[2023-03-22 23:25:48+0000] Moving admin cluster resources to the created admin cluster
[2023-03-22 23:25:51+0000] Waiting for node update jobs to finish OK
[2023-03-22 23:27:41+0000] Flushing logs... OK
[2023-03-22 23:27:41+0000] Deleting membership... OK
[2023-03-22 23:27:42+0000] Deleting bootstrap cluster.

Verbindung zum Administratorcluster herstellen

Mit dem Befehl bmctl register bootstrap wird auf Ihrer Administrator-Workstation eine kubeconfig-Datei für den Administratorcluster erstellt. Das Verzeichnis, in dem sich die kubeconfig befindet, und der Dateiname basieren auf dem Namen des Administratorclusters:

bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig

Sie müssen den Zugriff auf diese kubeconfig einschränken, da sie Authentifizierungsdaten für den Cluster enthält.

Wenn Sie sich mit Ihrer Google-ID im Cluster anmelden möchten, können Sie das Connect-Gateway so einrichten:

  1. Legen Sie auf Ihrer Administrator-Workstation die Umgebungsvariable KUBECONFIG fest:

    export KUBECONFIG=$HOME/bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig

  2. Legen Sie den aktuellen Kontext in einer Umgebungsvariablen fest:

    export CONTEXT="$(kubectl config current-context)"

  3. Führen Sie dazu den folgenden gcloud-Befehl aus. Mit diesem Befehl wird Folgendes ausgeführt:

    • Ihrem Nutzerkonto wird die Kubernetes-Rolle clusterrole/view für den Cluster zugewiesen.
    • Konfiguriert den Cluster so, dass Sie kubectl-Befehle mit Lesezugriff auf Ihrem lokalen Computer ausführen können, ohne sich per SSH mit der Administrator-Workstation verbinden zu müssen.

    Ersetzen Sie dabei GOOGLE_ACCOUNT_EMAIL durch die E-Mail-Adresse, die mit Ihrem Google Cloud-Konto verknüpft ist. Beispiel: --users=alex@example.com.

    gcloud container fleet memberships generate-gateway-rbac  \
    --membership=ADMIN_CLUSTER_NAME \
    --role=clusterrole/view \
    --users=GOOGLE_ACCOUNT_EMAIL \
    --project=FLEET_HOST_PROJECT_ID \
    --kubeconfig=$KUBECONFIG \
    --context=$CONTEXT\
    --apply

    Die Ausgabe dieses Befehls sieht in etwa so aus (zur besseren Lesbarkeit verkürzt):

    Validating input arguments.
Specified Cluster Role is: clusterrole/view
Generated RBAC policy is:
--------------------------------------------
...

Writing RBAC policy for user: GOOGLE_ACCOUNT_EMAIL to cluster.
Successfully applied the RBAC policy to cluster.

Wenn diese RBAC-Richtlinien eingerichtet sind, können Sie sich über die Console mit Ihrer Google-ID im Cluster anmelden. Außerdem können Sie kubectl-Befehle mit Lesezugriff auf anderen Computern als der Administrator-Workstation ausführen. Verwenden Sie dazu eine spezielle kubeconfig, die Anfragen über das Connect-Gateway weiterleitet.

  1. Führen Sie den folgenden Befehl auf einem anderen Computer als der Administrator-Workstation aus, um den kubeconfig-Eintrag abzurufen, der über das Connect-Gateway auf den Cluster zugreifen kann.

    gcloud container fleet memberships get-credentials ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID

    Die Ausgabe sieht in etwa so aus:

    Starting to build Gateway kubeconfig...
Current project_id: FLEET_HOST_PROJECT_ID
A new kubeconfig entry "connectgateway_FLEET_HOST_PROJECT_ID_global_ADMIN_CLUSTER_NAME" has been generated and set as the current context.

  2. Sie können jetzt kubectl-Befehle über das Connect-Gateway ausführen:

    kubectl get pods -A

Nächste Schritte