Administratorcluster mit GKE On-Prem API-Clients erstellen

Auf dieser Seite wird beschrieben, wie Sie einen Administratorcluster mithilfe 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. Dazu 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 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 den Lebenszyklus von Clustern, die mit bmctl erstellt wurden, über die Console oder die gcloud CLI verwalten möchten, lesen Sie 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 gewähren:

Wenn Sie in der Console auf die GKE Enterprise- und GKE-Seiten 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 Verbindungsgateway verwenden möchten, um kubectl-Befehle für den Cluster auf anderen Computern als der Administratorworkstation 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.

Nachdem 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 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 Administratorworkstation und Ihre Clusterknotenmaschinen angezeigt. Mit dem IP-Adressplaner im Abschnitt Netzwerkanforderungen können Sie die IP-Adressen planen, die für eine Mindestinstallation von einem Administrator- und einem Nutzercluster erforderlich sind.

Voraussetzungen für Administratorworkstations

Maximieren Sie diesen Abschnitt, um die Hardware-, Betriebssystem- und Verbindungsanforderungen für Ihre Administrator-Workstation aufzurufen.

Voraussetzungen für Clusterknotenmaschinen

Maximieren Sie diesen Abschnitt, um die Hardware-, Betriebssystem- und Verbindungsanforderungen für die Clusterknotenmaschinen anzuzeigen.

Netzwerkanforderungen

In diesem Abschnitt erfahren Sie, wie Sie die IP-Adressen planen, die Sie für eine Mindestumgebung benötigen. Optional können Sie im Abschnitt Knoten-IP- und virtuelle IP-Adressen eine Start-IP-Adresse des Knotens und eine virtuelle IP-Adresse (VIP) angeben. In der Konsole wird dann eine Tabelle mit den benötigten IP-Adressen angezeigt. Diese IP-Adressen werden nicht auf die Konfiguration des Administratorclusters angewendet. Sie sollen Ihnen als Leitfaden bei der Planung der IP-Adressen helfen, 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 IP-Adressplanung importieren, um sie als Ausgangspunkt zum Verfolgen der für Ihre Cluster benötigten IP-Adressen zu verwenden.

Weitere Informationen zu Google Cloud-Ressourcen:

Achten Sie darauf, dass alle erforderlichen Google APIs im Flotten-Hostprojekt aktiviert sind. Darüber hinaus 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.

Führen Sie vor dem Erstellen des Clusters den Befehl bmctl register bootstrap auf Ihrer Administratorworkstation aus, wie unter Bootstrap-Umgebung vorbereiten beschrieben. Dieser Befehl kann die erforderlichen Dienstkonten mit den minimal erforderlichen IAM-Berechtigungen erstellen, die zum Erstellen des Administratorclusters erforderlich sind. Sie können aber auch Dienstkonten manuell konfigurieren.

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

gcloud-CLI

Voraussetzungen für Hardware, Netzwerke 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. Darüber hinaus 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

Führen Sie vor dem Erstellen des Clusters den Befehl bmctl register bootstrap auf Ihrer Administratorworkstation aus, wie unter Bootstrap-Umgebung vorbereiten beschrieben. Dieser Befehl kann die erforderlichen Dienstkonten mit den minimal erforderlichen IAM-Berechtigungen erstellen, die zum Erstellen des Administratorclusters erforderlich sind. Sie können aber auch Dienstkonten manuell konfigurieren.

IP-Adressen des Tarifs

Bevor Sie den Administratorcluster erstellen, müssen Sie die IP-Adressen für Ihre Cluster planen. Unter IP-Adressen planen finden Sie ein Beispiel dafür, wie IP-Adressen für einen Hochverfügbarkeits-Administratorcluster und zwei Hochverfügbarkeits-Nutzercluster zugewiesen werden. Auch wenn Sie den Administratorcluster über die gcloud CLI erstellen, sollten Sie die Schritte in der Console 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 Cluster des Typs Kubernetes in Docker (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 der Cluster 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 Google Distributed Cloud-Version für Ihren Administratorcluster aus.

  3. Wählen Sie im Feld Google Cloud API-Standort 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 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

    Durch den Clusternamen, das Projekt und den Standort wird der Cluster in Google Cloud eindeutig identifiziert.

  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. Listen Sie die verfügbaren Google Distributed Cloud-Versionen auf, die Sie installieren können. Die Version bmctl, die Sie zum Erstellen der Bootstrap-Umgebung herunterladen, muss mit der Version übereinstimmen, die Sie im 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 möchten. Dies ist die Region, in der die GKE On-Prem API und die Fleet- 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 Administratorworkstation 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 Mindestberechtigungen 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 \
  --target-cluster-name=ADMIN_CLUSTER_NAME \
  --project-id=FLEET_HOST_PROJECT_ID

Ersetzen Sie Folgendes:

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

  • ADMIN_CLUSTER_NAME: Der Name Ihres Administratorclusters.

  • FLEET_HOST_PROJECT_ID: Das Projekt, in dem 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 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

SA-Schlüsseldateien angeben

Sie können auch bmctl die von Ihnen erstellten Dienstkonto-Schlüsseldateien ü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 erstellt, als Sie den SSH-Root-Zugriff auf Knoten eingerichtet haben.

  • ADMIN_CLUSTER_NAME: Der Name Ihres Administratorclusters.

  • FLEET_HOST_PROJECT_ID: Das Projekt, in dem der Administratorcluster nach dem Erstellen des Clusters automatisch registriert wird.

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

  • -gcr-service-account-key: Pfad zur Schlüsseldatei für das Dienstkonto, mit dem Container-Images abgerufen werden (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, mit dem Logs geprüft und Projekte überwacht werden können (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 zeigt die Console Verbindung hergestellt an.

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

    • Achten Sie darauf, dass der Wert für --target-cluster-name mit dem Namen des Administratorclusters übereinstimmt, 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 110. Nachdem der Cluster erstellt wurde, können Sie diesen Wert nicht mehr aktualisieren.

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

  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.

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

  6. Klicken Sie auf Verify and Create (Bestätigen und erstellen).

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

    Wenn ein Problem mit der Konfiguration auftritt, zeigt die Console eine Fehlermeldung an, die deutlich 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 des Nutzerclusters.

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

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

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

Ersetzen Sie Folgendes:

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

  • FLEET_HOST_PROJECT_ID: Das Projekt, in dem der Administratorcluster nach 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

    Durch den Clusternamen, das Projekt und den Standort wird der Cluster in Google Cloud eindeutig identifiziert.

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

  • MAX_PODS_PER_NODE : Die zulässigen Werte für Administratorcluster sind 32–250 und 64–250 für Cluster ohne Hochverfügbarkeit. Wenn --max-pods-per-node nicht im Befehl enthalten ist, ist der Standardwert 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) ist auch durch die verfügbaren IP-Ressourcen des Clusters begrenzt. Weitere Informationen finden Sie unter Pod-Netzwerke.

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

  • CONTROL_PLANE_LOAD_BALANCER_PORT: Der Port, an dem der Load-Balancer die Steuerungsebene bedient. Obwohl Sie auch einen anderen Wert konfigurieren können, ist Port 443 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 bei jeder Aktualisierung des Clusters ändern.

    Der Wert für das Flag hat folgendes 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 enthält Segmente, die mit den Keywords node-ip und labels beginnen. Trennen Sie die Segmente durch Kommas.

    • node-ip: Die IP-Adresse eines Knotens der Steuerungsebene. Sie können nur ein 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 bereitstellt. Wir empfehlen, im IP-Adressbereich für private Internets, wie in RFC 1918 definiert, einen Bereich zu verwenden, 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 sollen. Der CIDR-Bereich muss zwischen /18 und /8 liegen, wobei /8 die meisten IP-Adressen bereitstellt. Wir empfehlen, im IP-Adressbereich für private Internets, wie in RFC 1918 definiert, einen Bereich zu verwenden, 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 werden soll. Die StorageClass wird während der Clustererstellung erstellt.

  • --lvp-node-mounts-config-path: Dies ist der Pfad zum Hostcomputer, in dem bereitgestellte Laufwerke gefunden 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 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 die OPERATION_ID des Vorgangs mit langer Ausführungszeit. Mit dem folgenden Befehl können Sie den Status des Vorgangs ermitteln:

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

Weitere Informationen finden Sie unter Bare-Metal-Vorgänge mit gcloud-Containern.

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 diesem 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 Administratorworkstation 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 Administratorworkstation, 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 zum Clustererstellungsprozess werden auf Ihrer Administratorworkstation 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 Anmeldedaten zur Authentifizierung für den Cluster enthält.

Wenn Sie sich mit Ihrer Google-Identität im Cluster anmelden möchten, können Sie das Verbindungs-Gateway so einrichten:

  1. Legen Sie auf Ihrer Administratorworkstation 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, dass er zur besseren Lesbarkeit abgeschnitten wird:

    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.

Mit diesen RBAC-Richtlinien können Sie sich über die Console mit Ihrer Google-Identität beim Cluster anmelden. Außerdem können Sie schreibgeschützte kubectl-Befehle auf anderen Computern als der Administrator-Workstation ausführen. Verwenden Sie dazu ein spezielles kubeconfig, das Anfragen über das Verbindungsgateway leitet.

  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 Verbindungs-Gateway ausführen:

    kubectl get pods -A

Nächste Schritte