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. Beide Google Cloud-Standardclients verwenden zum Erstellen des Clusters die GKE On-Prem API.

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 und 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. Dabei wird die Google Cloud-Region verwendet, die Sie beim Erstellen des Clusters angeben. Mit diesen Metadaten kann die API den Clusterlebenszyklus verwalten. Sie 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. Dazu erstellen Sie eine Konfigurationsdatei für den Administratorcluster und verwenden bmctl, wie unter Administratorcluster erstellen beschrieben.

Wenn Sie die Console oder die gcloud CLI verwenden möchten, um den Lebenszyklus von Clustern zu verwalten, die mit bmctl erstellt wurden, finden Sie weitere Informationen unter Cluster für die Verwaltung durch die GKE On-Prem API konfigurieren.

IAM-Berechtigungen

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

Wenn Sie in der Console auf die Seiten GKE Enterprise und GKE zugreifen möchten, benötigen Sie außerdem 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 kubectl-Befehle für den Cluster 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 instructions.

Wählen Sie den Client zum Erstellen des Administratorclusters aus

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

Sobald Sie mit den Informationen vertraut sind, die Sie zum Erstellen von Clustern bereitstellen müssen, ist die gcloud CLI möglicherweise praktischer, 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 mit den gcloud-Befehlen einen Cluster erstellen und das Flag --impersonate-service-account angeben, um die Erstellung zu automatisieren.

Vorbereitung

Console

  1. Rufen Sie in der Console die Seite GKE on Bare Metal-Cluster erstellen auf.

    Zur Seite „GKE on Bare Metal-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 Mindestinstallation eines Administratorclusters und eines Nutzerclusters erforderlich sind.

Voraussetzungen für Administratorworkstations

Maximieren Sie diesen Abschnitt, um die Hardware-, Betriebssystem- und Verbindungsanforderungen für Ihre Administratorworkstation anzeigen zu lassen.

Voraussetzungen für Clusterknotenmaschinen

Maximieren Sie diesen Abschnitt, um die Hardware-, Betriebssystem- und Verbindungsanforderungen der Clusterknotenmaschinen zu sehen.

Netzwerkanforderungen

In diesem Abschnitt erfahren Sie, wie Sie die IP-Adressen planen, die Sie für eine Minimalumgebung 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 eine Tabelle mit den erforderlichen IP-Adressen angezeigt. Diese IP-Adressen werden nicht auf die Konfiguration des Administratorclusters angewendet. Sie dienen als Leitfaden bei der Planung der IP-Adressen, die Sie für Ihre Installation benötigen. Sie können die Tabelle als CSV-Datei herunterladen und in eine Tabelle oder ein Tool zur Planung von IP-Adressen importieren, um die für Ihre Cluster erforderlichen IP-Adressen als Ausgangspunkt zu verwenden.

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 der Administratorworkstation aus, wie unter Bootstrap-Umgebung vorbereiten beschrieben. Mit diesem Befehl können die erforderlichen Dienstkonten mit den IAM-Mindestberechtigungen erstellt werden, die zum Erstellen des Administratorclusters erforderlich sind. Wenn Sie möchten, können Sie auch Dienstkonten manuell konfigurieren.

Wenn Sie beginnen möchten, klicken Sie in der linken Navigationsleiste auf Bootstrap-Umgebung installieren.

gcloud-CLI

Voraussetzungen für Hardware, Netzwerk und Betriebssysteme

Zum Erstellen eines Administratorclusters mit einem GKE On-Prem API-Client sind dieselben Hardware-, Netzwerk- und Betriebssystemvoraussetzungen wie für das Erstellen des Clusters mit bmctl erforderlich. Weitere Informationen finden Sie unter Voraussetzungen für die Installation.

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 der Administratorworkstation aus, wie unter Bootstrap-Umgebung vorbereiten beschrieben. Mit diesem Befehl können die erforderlichen Dienstkonten mit den IAM-Mindestberechtigungen erstellt werden, die zum Erstellen des Administratorclusters erforderlich sind. Wenn Sie möchten, können Sie auch Dienstkonten 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 das Zuweisen von IP-Adressen für einen Hochverfügbarkeits-Administratorcluster und zwei HA-Nutzercluster. Auch wenn Sie die gcloud CLI zum Erstellen des Administratorclusters verwenden, sollten Sie die Schritte in der Konsole in diesem Abschnitt ausführen, um den IP-Adressplaner zu verwenden.

Bootstrap-Umgebung vorbereiten

Bevor Sie den Administratorcluster erstellen, müssen Sie den Befehl bmctl register bootstrap auf der Administratorworkstation ausführen. Mit diesem Befehl wird ein Kubernetes in Docker-Cluster (Art) auf der Administratorworkstation 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 er erfolgreich erstellt wurde.

Console

  1. Geben Sie einen Namen für den Administratorcluster ein. Der Name des Bootstrap-Clusters wird abgeleitet, indem dem Namen des Administratorclusters bootstrap- vorangestellt wird.

  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)
    • Dienst verbinden (gkeconnect.googleapis.com)

    Mit dieser Einstellung wird auch die Region festgelegt, in der die folgenden Daten gespeichert werden:

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

    Der Clustername, das Projekt und der Standort identifizieren zusammen den Cluster in Google Cloud eindeutig.

  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 zu erstellenden Clusters übereinstimmen. 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ühre den folgenden Befehl aus, um dich mit deinem Google-Konto anzumelden:

    gcloud auth login

  3. Listen Sie die 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 werden. Dies ist die Region, in der die GKE On-Prem API und die Fleet and Connect-Dienste ausgeführt werden. Geben Sie us-west1 oder eine andere unterstützte Region an.

Bootstrap-Cluster erstellen

Führen Sie auf Ihrer Administratorworkstation die folgenden Schritte aus. Diese Befehle werden in der Konsole angezeigt.

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

    gcloud auth application-default login

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

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

    gsutil 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 (SAs) erstellen lassen oder die Dienstkonten und Schlüsseldateien selbst erstellen und an den Befehl bmctl register bootstrap übergeben.

bmctl erstellt SAs

Verwenden Sie den folgenden Befehl, wenn bmctl die erforderlichen Dienstkonten mit den erforderlichen Berechtigungen erstellen soll, die zum Erstellen des Administratorclusters erforderlich sind. 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, für das der Administratorcluster nach dem Erstellen des Clusters 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 aus Clustern nach Cloud Logging und Cloud Monitoring zu exportieren. rollen/logging.logWriter
roles/monitoring.metricWriter
roles/Stackdriver.resourceMetadata.writer
roles/opsconfigmonitoring.resourceMetadata.writer
roles/monitoring.dashboardEditor

SA-Schlüsseldateien angeben

Wenn Sie möchten, können Sie die von Ihnen erstellten Dienstkonto-Schlüsseldateien bmctl übergeben. Im folgenden Befehl werden die Namen der Schlüsseldateien aus Dienstkonten manuell konfigurieren verwendet. Dabei 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 zu Ihrem privaten SSH-Schlüssel. Sie haben den SSH-Schlüssel beim Einrichten des Root-SSH-Zugriffs auf Knoten erstellt.

  • ADMIN_CLUSTER_NAME: Der Name Ihres Administratorclusters.

  • FLEET_HOST_PROJECT_ID: Das Projekt, für das der Administratorcluster nach dem Erstellen des Clusters automatisch registriert wird.

Die folgenden Flags geben den Pfad zu den Schlüsseldateien an:

  • -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, das den Cluster bei der Flotte registriert (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, sieht die Ausgabe in etwa so aus:

[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 Konsole Verbindung hergestellt angezeigt.

    Die Verbindung zum Bootstrap-Cluster muss hergestellt werden, bevor Sie fortfahren. Wenn keine Verbindung hergestellt wird, prüfen Sie die Argumente, die Sie im Befehl bmctl register bootstrap angegeben haben:

    • Der Wert für --target-cluster-name muss mit dem Name 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üssen, geben Sie Ctrl-C ein, um bmctl register bootstrap zu beenden und den Befehl noch einmal auszuführen.

  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 bei Maximale Anzahl von Pods pro Knoten einen Wert zwischen 64 und 250 ein oder übernehmen Sie den Standardwert von 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.

  4. Klicken Sie auf Weiter.

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

    Um ausführliche Informationen zu erhalten, bewegen Sie den Mauszeiger auf das -Symbol neben den einzelnen Feldern.

  6. Klicken Sie auf Bestätigen und erstellen.

    Während der Überprüfung der Einstellungen und der Erstellung des Clusters in Ihrem Rechenzentrum werden in der Console Statusmeldungen angezeigt.

    Wenn ein Problem mit der Konfiguration auftritt, wird in der Console eine Fehlermeldung angezeigt, die klar genug sein sollte, damit Sie das Konfigurationsproblem beheben und noch einmal versuchen können, den Cluster zu erstellen.

gcloud-CLI

Prüfen Sie vor dem Erstellen des Administratorclusters, 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 des Bootstrap-Clusters, die Sie für bmctl register bootstrap angegeben haben. Wenn Sie den Namen des Bootstrap-Clusters oder die Projekt-ID ändern müssen, geben Sie Ctrl-C ein, um bmctl register bootstrap zu beenden und den Befehl noch einmal auszuführen.

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 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, für das der Administratorcluster nach dem Erstellen des Clusters 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. Diese Einstellung gibt die Region an, 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
    • Das von Cloud-Audit-Logs erstellte Administrator-Audit-Log

    Der Clustername, das Projekt und der Standort identifizieren zusammen den Cluster in Google Cloud eindeutig.

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

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

    Die maximale Anzahl von Pods pro Knoten (auch 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. Fügen Sie die VIP der Steuerungsebene in dasselbe Subnetz wie die Load-Balancer-Knoten ein. Fügen 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 bedient. 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, wenn Sie eine Mindestbereitstellung verwenden, oder drei Maschinen, wenn Sie eine Bereitstellung mit Hochverfügbarkeit verwenden. Geben Sie eine ungerade Anzahl von Knoten an, um ein Mehrheitsquorum für Hochverfügbarkeit zu haben. Sie können diese Adressen ändern, wenn Sie den Cluster aktualisieren oder upgraden.

    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 angeben. Wenn Sie mehr als einen Knoten angeben müssen, fügen Sie das Flag noch einmal für jeden Knoten 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 die Verwendung eines in RFC 1918 definierten IP-Adressbereichs für private Internets, 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 wird. Der CIDR-Bereich muss zwischen /18 und /8 liegen, wobei /8 die meisten IP-Adressen bietet. Wir empfehlen die Verwendung eines in RFC 1918 definierten IP-Adressbereichs für private Internets, 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 nichtflüchtiges Volume (PV) erstellt.

  • --lvp-share-storage-class: Dies ist die Speicherklasse, die zum Erstellen nichtflüchtiger Volumes verwendet wird. Die StorageClass wird während der Clustererstellung erstellt.

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

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

Eine vollständige Liste der Flags und ihrer 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

Vor dem Erstellen des Clusters führt bmctl eine Reihe von Preflight-Prüfungen aus, um die Konfiguration zu prüfen. Wenn es ein Problem mit der Konfiguration gibt, wird der Befehl gcloud ... create mit einem Fehler wie dem 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 sehen Sie in etwa Folgendes:

[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. Ist dies nicht der Fall, führen Sie den Befehl mit denselben Argumenten noch einmal 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 zur Clustererstellung werden auf Ihrer Administrator-Workstation ausgegeben. Wenn die Preflight-Prüfungen bestanden sind, wird in etwa Folgendes angezeigt:

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

Mit dem Administratorcluster verbinden

Mit dem Befehl bmctl register bootstrap wird eine kubeconfig-Datei für den Administratorcluster auf Ihrer Administratorworkstation 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 dieses kubeconfig einschränken, da es Authentifizierungsanmeldedaten für den Cluster enthält.

Wenn Sie sich mit Ihrer Google-Identität im Cluster anmelden möchten, können Sie das Verbindungsgateway 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:

    • Gewährt Ihrem Nutzerkonto die Kubernetes-Rolle clusterrole/view für den Cluster.
    • Konfiguriert den Cluster so, dass Sie schreibgeschützte kubectl-Befehle auf Ihrem lokalen Computer ausführen können, ohne eine SSH-Verbindung zur Administratorworkstation herstellen zu müssen.

    Ersetzen Sie 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 und ist zur besseren Lesbarkeit gekü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 vorhanden sind, können Sie sich über die Console mit Ihrer Google-Identität im Cluster anmelden. Außerdem können Sie schreibgeschützte kubectl-Befehle auf anderen Computern als der Administratorworkstation ausführen. Verwenden Sie dazu eine spezielle kubeconfig, die Anfragen über das Verbindungsgateway weiterleitet.

  1. Führen Sie den folgenden Befehl auf einem anderen Computer als der Administratorworkstation aus, um den Eintrag kubeconfig abzurufen, der über das Verbindungsgateway 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 Verbindungsgateway ausführen:

    kubectl get pods -A

Nächste Schritte