Administratorcluster mit Anthos 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 die Anthos On-Prem API, um den Cluster zu erstellen.

Was ist die Anthos On-Prem API?

Die Anthos 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 Anthos 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 Anthos On-Prem API Metadaten zum Status Ihres Clusters in Google Cloud speichern. Dabei muss die Google Cloud-Region verwendet werden, die Sie beim Erstellen des Clusters angegeben haben. Mit diesen Metadaten kann die API den Clusterlebenszyklus verwalten. Sie enthalten keine arbeitslastspezifischen Daten.

Wenn Sie einen Cluster mit einem Anthos On-Prem API-Client erstellen, geben Sie ein Google Cloud-Projekt an. Nachdem der Cluster erstellt wurde, wird er automatisch in 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.

Sie können auch 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 zur Verwaltung durch die Anthos 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 Google Kubernetes Engine 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 Anthos On-Prem API verwaltet wird. Wenn Sie GKE on Bare Metal zum ersten Mal installieren, ist die Konsole möglicherweise einfacher zu verwenden als die gcloud CLI.

Wenn Sie mit den Informationen vertraut sind, die Sie zum Erstellen von Clustern angeben 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 Google Cloud Console die Seite „GKE Enterprise-Cluster“ auf.

    Zur Seite „GKE Enterprise-Cluster“

  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.

  3. Klicken Sie auf Cluster erstellen.

  4. Klicken Sie im Dialogfeld auf Lokal.

  5. Klicken Sie neben Bare Metal auf Konfigurieren. Achten Sie darauf, dass Administratorcluster erstellen ausgewählt ist.

Auf der Seite Voraussetzungen werden die Anforderungen für Ihre Administrator-Workstation und die Maschinen mit Clusterknoten angezeigt. Der IP-Adressplaner im Abschnitt Netzwerkanforderungen unterstützt Sie bei der Planung der IP-Adressen, 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 aufzurufen.

Voraussetzungen für Clusterknotenmaschinen

Maximieren Sie diesen Abschnitt, um die Hardware-, Betriebssystem- und Verbindungsanforderungen für die Maschinen mit Clusterknoten aufzurufen.

Netzwerkanforderungen

In diesem Abschnitt erfahren Sie, wie Sie die IP-Adressen planen, die Sie für eine minimale Umgebung benötigen. Optional können Sie im Abschnitt Knoten-IP-Adresse und virtuelle IP-Adressen eine Start-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 Konfiguration des Administratorclusters 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 Tool zur Planung von IP-Adressen importieren, um sie als Ausgangspunkt für das Tracking der für Ihre Cluster erforderlichen IP-Adressen zu verwenden.

Google Cloud-Ressourcen prüfen:

Achten Sie darauf, dass alle erforderlichen Google APIs im Flotten-Hostprojekt aktiviert sind. Darüber hinaus müssen Sie die Anthos 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-Berechtigungen erstellt werden, die zum Erstellen des Administratorclusters mindestens 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 Betriebssystem

Das Erstellen eines Administratorclusters mit einem Anthos On-Prem API-Client erfordert dieselben Hardware-, Netzwerk- und Betriebssystemvoraussetzungen wie das Erstellen des Clusters mit bmctl. 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. Darüber hinaus müssen Sie die Anthos 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-Berechtigungen erstellt werden, die zum Erstellen des Administratorclusters mindestens 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 die Zuweisung 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 Ihrer 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 bootstrap- dem Namen des Administratorclusters vorangestellt wird.

  2. Wählen Sie die GKE on Bare Metal-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 Anthos On-Prem API ausgeführt wird, und die Region, in der Folgendes gespeichert ist:

    • Die Clustermetadaten, die die Anthos 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 von Ihnen erstellten 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. Prüfen Sie, ob Sie die neueste Version der gcloud-Befehlszeile haben, einschließlich der Betakomponenten der gcloud CLI.

  2. Wenn Sie die Betakomponenten noch nicht haben, führen Sie den folgenden Befehl aus, um sie zu installieren:

    gcloud components install beta

  3. Aktualisieren Sie bei Bedarf die Komponenten der gcloud CLI:

    gcloud components update

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

    gcloud auth login

  5. Listen Sie die verfügbaren GKE on Bare Metal-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, in der die Anthos On-Prem API ausgeführt wird. 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 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 GKE on Bare Metal, 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 mindestens erforderlichen Berechtigungen zum Erstellen des Administratorclusters erstellen soll. Bei diesem Befehl wird davon ausgegangen, dass sich bmctl im aktuellen Arbeitsverzeichnis befindet.

./bmctl register bootstrap \
  --ssh-key=YOUR_PRIVATE_KEY \
  --name=bootstrap-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 ausgefüllt.

  • ADMIN_CLUSTER_NAME: Der Name Ihres Administratorclusters. Das Format des Bootstrap-Clusternamens muss bootstrap-ADMIN_CLUSTER_NAME sein.

  • FLEET_HOST_PROJECT_ID: Das Projekt, unter dem der Administratorcluster automatisch registriert wird, nachdem der Cluster erstellt wurde.

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 Anthos on Bare Metal verwendet dieses Dienstkonto, um Container-Images aus Google Container Registry herunterzuladen. Keine
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. roles/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 unter Dienstkonten manuell konfigurieren verwendet. Dabei wird davon ausgegangen, dass sich bmctl und die Schlüsseldatei im aktuellen Arbeitsverzeichnis befinden.

./bmctl register bootstrap \
  --ssh-key=YOUR_PRIVATE_KEY \
  --name=bootstrap-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 bei der Einrichtung des Root-SSH-Zugriffs auf Knoten erstellt.

  • ADMIN_CLUSTER_NAME: Der Name Ihres Administratorclusters. Das Format des Bootstrap-Clusternamens muss bootstrap-ADMIN_CLUSTER_NAME sein.

  • FLEET_HOST_PROJECT_ID: Das Projekt, unter dem der Administratorcluster automatisch registriert wird, nachdem der Cluster erstellt wurde.

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 (anthos-baremetal-register) registriert.

  • --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 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 Console Verbindung hergestellt angezeigt.

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

    • Achten Sie darauf, dass der Wert für --name mit dem abgeleiteten Bootstrap-Namen übereinstimmt, der im Abschnitt Grundlagen der Bootstrap-Umgebung angezeigt wird.

    • Achten Sie darauf, dass der Wert für --project-id mit der ID des Projekts übereinstimmt, 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 Next (Weiter).

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

    Bewegen Sie den Mauszeiger auf das neben dem jeweiligen Feld, um weitere Informationen zu erhalten.

  6. Klicken Sie auf Bestätigen und erstellen.

    Bei 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 Konsole 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, unter dem der Administratorcluster automatisch registriert wird, nachdem der Cluster erstellt wurde. Das Flotten-Hostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.

  • REGION: Die Google Cloud-Region, in der die Anthos 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 Anthos 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 GKE on Bare Metal-Version. Die Version muss der bmctl-Version entsprechen, mit der Sie bmctl register bootstrap ausgeführt haben. Sie können die Version bmctl prüfen, indem Sie bmctl version auf der Administratorworkstation ausführen.

  • MAX_PODS_PER_NODE : Für Administratorcluster sind die Werte 32–250 und 64–250 für Cluster ohne Hochverfügbarkeit zulässig. Wenn --max-pods-per-node nicht im Befehl enthalten ist, wird als Standardwert 110 verwendet. 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. Beziehen 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 Hochverfügbarkeitsbereitstellung verwenden. Geben Sie eine ungerade Anzahl von Knoten an, um ein Mehrheitsquorum für Hochverfügbarkeit zu erhalten. 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 einen node-ip pro Flag angeben. Wenn Sie mehr als einen Knoten angeben müssen, 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 Semikolons.

    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, für private Internets einen Bereich im IP-Adressbereich 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, die für Pods im Nutzercluster verwendet werden. Der CIDR-Bereich muss zwischen /18 und /8 liegen, wobei /8 die meisten IP-Adressen bietet. Wir empfehlen, für private Internets einen Bereich im IP-Adressbereich 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 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 PersistentVolume (PV) erstellt.

  • --lvp-node-mounts-config-storage: Die Speicherklasse, mit der PVs bei 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-Vorgänge.

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 ein Problem mit der Konfiguration auftritt, wird der Befehl gcloud ... create mit einem Fehler wie dem folgenden beendet:

ERROR: (gcloud.beta.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. Ist dies nicht der Fall, führen Sie den Befehl mit denselben Argumenten noch einmal aus und fügen 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.

Verbindung zum Administratorcluster herstellen

Mit dem Befehl bmctl register bootstrap wird eine kubeconfig-Datei für den Administratorcluster auf Ihrer Administratorworkstation erstellt. Das Verzeichnis, in dem sich 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 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:

    • 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 etwa so aus, ist aber 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 mit Ihrer Google-Identität über die Console beim Cluster anmelden. Darüber hinaus 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 Connect-Gateway weiterleitet.

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