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 Standard-Google Cloud-Clients 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 und verwenden die API, um Cluster in Ihrem Rechenzentrum zu erstellen.

Zum Verwalten des Lebenszyklus Ihrer Cluster muss die Anthos On-Prem API Metadaten zum Clusterstatus 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 und enthält 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 nicht mehr geändert werden, nachdem der Cluster erstellt wurde.

Wenn Sie möchten, können Sie einen Administratorcluster durch Erstellen einer Administratorclusterkonfigurationsdatei erstellen und bmctl verwenden, wie unter Administratorcluster erstellen beschrieben.

Informationen zum Verwalten des Lebenszyklus von Clustern, die mit bmctl erstellt wurden, finden Sie unter Cluster für die Anthos On-Prem API verwalten.

IAM-Berechtigungen

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

Wenn Sie auf die Seiten „Anthos“ und „Google Kubernetes Engine“ in der Console 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 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 dieser Anleitung.

Client zum Erstellen des Administratorclusters auswählen

Sie können die Console oder die gcloud CLI verwenden, um einen Administratorcluster zu erstellen, der von der Anthos On-Prem API verwaltet wird. Wenn Sie zum ersten Mal Anthos-Cluster auf Bare Metal installieren, ist die Konsole möglicherweise einfacher zu verwenden als die gcloud CLI.

Nachdem Sie sich mit den Informationen, die Sie zum Erstellen von Clustern bereitstellen müssen, vertraut machen, ist die gcloud CLI möglicherweise einfacher, da Sie den Befehl mit den zugehörigen Argumenten in einer Textdatei speichern können. Wenn Sie ein CI/CD-Tool wie Cloud Build verwenden, können Sie mit den Befehlen gcloud einen Cluster erstellen und das Flag --impersonate-service-account angeben, um das Erstellen zu automatisieren.

Vorbereitung

Console

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

    Zur Seite "Anthos-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 die Administratorworkstation und die Clusterknotenmaschinen angezeigt. Mit dem IP-Adressplaner im Abschnitt Netzwerkanforderungen können Sie die IP-Adressen planen, die für eine Mindestinstallation eines Administrator- und eines Nutzerclusters erforderlich sind.

Voraussetzungen für die Administratorworkstation

Maximieren Sie diesen Abschnitt, um die Hardware-, Betriebssystem- und Konnektivitätsanforderungen für Ihre Administratorworkstation anzusehen.

Voraussetzungen für Clusterknotenmaschinen

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

Netzwerkanforderungen

Dieser Abschnitt hilft Ihnen bei der Planung der IP-Adressen, die Sie für eine minimale Umgebung benötigen. Optional können Sie im Bereich Knoten-IP-Adressen und virtuelle IP-Adressen eine IP-Adresse für den Startknoten und eine virtuelle IP-Adresse (VIP) angeben. In der Konsole 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 in eine CSV-Datei herunterladen und in ein Tabellen- oder IP-Adressplanungstool importieren, um sie als Ausgangspunkt für das Tracking der für Ihre Cluster erforderlichen IP-Adressen zu verwenden.

Google Cloud-Ressourcen ansehen:

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.

Vor dem Erstellen des Clusters führen Sie auf Ihrer Administratorworkstation den Befehl bmctl register bootstrap aus, wie unter Bootstrap-Umgebung vorbereiten beschrieben. Mit diesem Befehl können die erforderlichen Dienstkonten mit den erforderlichen IAM-Berechtigungen erstellt werden, die zum Erstellen des Administratorclusters erforderlich sind. Sie können die Dienstkonten auch 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 Anthos On-Prem API-Client gelten dieselben Voraussetzungen für Hardware, Netzwerk und Betriebssystem wie für den Cluster 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

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

IP-Adressen planen

Bevor Sie den Administratorcluster erstellen, müssen Sie die IP-Adressen für Ihre Cluster planen. Unter IP-Adressen planen erfahren Sie, wie Sie IP-Adressen für einen Hochverfügbarkeits-Administratorcluster und zwei Hochverfügbarkeits-Nutzercluster zuweisen. Selbst 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 Kubernetes-Cluster in Docker (kind) 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 des Bootstrap-Clusters Knoten bereit, führen Preflight-Prüfungen aus und registrieren den Administratorcluster in der Flotte. Der Bootstrap-Cluster wird nach dem Erstellen des Clusters automatisch gelöscht.

Console

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

  2. Wählen Sie die Anthos-Cluster auf Bare Metal-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 Anthos On-Prem API ausgeführt wird, und die Region, 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 geben den Cluster in Google Cloud eindeutig an.

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

gcloud-CLI

  1. Sie benötigen die neueste Version der gcloud CLI, einschließlich der Beta-Komponenten der gcloud CLI.

  2. Wenn Sie die Betakomponenten noch nicht haben, installieren Sie sie mit dem folgenden Befehl:

    gcloud components install beta

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

    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 Anthos-Cluster auf 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 beta 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 auf der Administratorworkstation die folgenden Schritte aus. Diese Befehle werden in der Konsole angezeigt.

  1. Legen Sie die Nutzeranmeldedaten als Standardanmeldedaten für Anwendungen 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 Anthos-Clustern auf Bare Metal, die Sie installieren möchten. Wenn Sie den Befehl aus der Console kopiert haben, befindet sich die Version bereits im Befehl.

  3. Erstellen Sie den Bootstrap-Cluster. Sie können 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 \
  --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 für Sie ausgefüllt.

  • ADMIN_CLUSTER_NAME ist der Name Ihres Administratorclusters. Das Format des Bootstrap-Clusternamens muss bootstrap-ADMIN_CLUSTER_NAME sein.

  • FLEET_HOST_PROJECT_ID: Das Projekt, in dem der Administratorcluster automatisch erstellt 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-barmetal-gcr Anthos on Bare Metal verwendet dieses Dienstkonto, um Container-Images aus Google Container Registry herunterzuladen. –
anthos-barmetal-connect Der Connect Agent verwendet dieses Dienstkonto, um eine Verbindung zwischen Ihrem Cluster und Google Cloud aufrechtzuerhalten Rollen/gkehub.connect
anthos-barmetal-register Connect Agent verwendet dieses Dienstkonto, um Ihre Cluster bei der Google Cloud-Flotte zu registrieren. roles/gkehub.admin
anthos-barmetal-cloud-ops Der Stackdriver Agent verwendet dieses Dienstkonto zum Exportieren von Logs und Messwerten aus Clustern nach Cloud Logging und Cloud Monitoring. Rollen/Logging.logWriter
roles/monitoring.metricWriter
roles/lpurl.resourceMetadata.writer
roles/opsconfigmonitoring.resourceMetadata.writer
roles/monitoring.dashboardEditor

SA-Schlüsseldateien angeben

Wenn Sie möchten, können Sie bmctl die von Ihnen erstellten Dienstkontoschlüsseldateien übergeben. Im folgenden Befehl werden die Schlüsseldateien unter 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 \
  --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 erstellt, als Sie Root-SSH-Zugriff auf Knoten einrichten.

  • ADMIN_CLUSTER_NAME ist der Name Ihres Administratorclusters. Das Format des Bootstrap-Clusternamens muss bootstrap-ADMIN_CLUSTER_NAME sein.

  • FLEET_HOST_PROJECT_ID: Das Projekt, in dem der Administratorcluster automatisch erstellt 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 (anthos-baremetal-gcr) abruft.

  • --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 in der Flotte registriert (Anthos-baremetal-register).

  • --cloud-operation-service-account-key: Der Pfad zur Schlüsseldatei für das Dienstkonto zum Prüfen von Logs und Überwachen von Projekten (anthos-baremetal-cloud-ops).

Nachdem bmctl den Bootstrap-Cluster erstellt hat, sollte die Ausgabe in etwa so aussehen:

[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 können. Wenn die Verbindung nicht hergestellt wurde, prüfen Sie die Argumente, die Sie für den Befehl bmctl register bootstrap angegeben haben:

    • Achten Sie darauf, dass der Wert für --name mit dem abgeleiteten Bootstrap-Namen übereinstimmt, der im Abschnitt Bootstrap-Umgebung – Grundlagen 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 Bootstrap-Clusternamen 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 unter Maximale Anzahl Pods pro Knoten einen Wert zwischen 64 und 250 ein oder übernehmen Sie den Standardwert 110. Nachdem der Cluster erstellt wurde, können Sie diesen Wert nicht mehr aktualisieren.

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

  4. Klicken Sie auf Next (Weiter).

  5. Auf der Seite Netzwerk definieren Sie, wie Ihre Knoten und Komponenten im Cluster miteinander und mit der Kubernetes-Steuerungsebene kommunizieren.

    Bewegen Sie den Mauszeiger über das neben dem jeweiligen Feld, um detaillierte Informationen zu erhalten.

  6. Klicken Sie auf Bestätigen und erstellen.

    In der Console werden Statusmeldungen angezeigt, während die Einstellungen geprüft und der Cluster in Ihrem Rechenzentrum erstellt wird.

    Wenn bei der Konfiguration ein Problem auftritt, wird in der Console eine Fehlermeldung angezeigt. Diese sollte klar genug sein, dass Sie das Konfigurationsproblem beheben können, und noch einmal versuchen, 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 des Bootstrap-Clusters und die Projekt-ID, die Sie für bmctl register bootstrap angegeben haben. Wenn Sie den Namen des Bootstrap-Clusters oder die Projekt-ID ändern mü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 beta 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 beta 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 manuelles Load-Balancing verwenden möchten, fügen Sie --enable-manual-lb dem Befehl hinzu.

Ersetzen Sie Folgendes:

  • ADMIN_CLUSTER_NAME ist 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 automatisch erstellt wird, nachdem der Cluster erstellt wurde. Das Flotten-Hostprojekt kann nicht mehr geändert werden, nachdem der Cluster erstellt wurde.

  • 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. Mit dieser Einstellung wird die Region angegeben, 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 geben den Cluster in Google Cloud eindeutig an.

  • VERSION: Die Version von Anthos-Clustern auf Bare Metal. 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, indem Sie bmctl version auf der Administrator-Workstation ausführen.

  • MAX_PODS_PER_NODE : Für Administratorcluster sind zulässige Werte von 32 bis 250 und 64 bis 250 von Clustern, die keine Hochverfügbarkeit sind. 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) ist auch durch die verfügbaren IP-Ressourcen Ihres Clusters begrenzt. Weitere Informationen finden Sie unter Pod-Netzwerke.

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

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

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

    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 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 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 Segment labels 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. Es empfiehlt sich, für IP-Adressen im privaten IP-Bereich einen Bereich zu verwenden, der in RFC 1918 definiert ist, z. B. 172.26.232.0/24.

  • POD_ADDR_CIDR: Ein Bereich von IPv4-Adressen im CIDR-Format, der für Pods im Nutzercluster verwendet werden soll. Der CIDR-Bereich muss zwischen /18 und /8 liegen, wobei /8 die meisten IP-Adressen bietet. Es empfiehlt sich, für IP-Adressen im privaten IP-Bereich einen Bereich 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 Hostcomputer-Pfad, unter dem Unterverzeichnisse erstellt werden können. Für jedes Unterverzeichnis wird ein lokales PersistentVolume (PV) erstellt.

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

  • --lvp-node-mounts-config-path: Dies ist der Pfad 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. Mit dem folgenden Befehl können Sie den Status des Vorgangs ermitteln:

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

Weitere Informationen finden Sie unter gcloud-Beta-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 überprüfen. Wenn ein Problem mit der Konfiguration auftritt, wird der Befehl gcloud ... create mit einem Fehler wie dem folgenden beendet:

ERROR: (gcloud.alpha.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 erreichbar war. Auf der Administratorworkstation 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. Achten Sie auf der Administratorworkstation darauf, dass der bmctl register bootstrap-Prozess 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 beta 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 beta container bare-metal admin-clusters update.

Details zum Clustererstellungsprozess werden auf Ihrer Administratorworkstation ausgegeben. Wenn die Preflight-Prüfungen erfolgreich sind, wird 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 diesen kubeconfig einschränken, da er Authentifizierungsdaten für den Cluster enthält.

Wenn Sie die Google-Identität verwenden möchten, um sich im Cluster anzumelden, können Sie das Connect-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 Rolle clusterrole/view von Kubernetes im 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 so aus, weil er gekürzt wurde:

    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 der Google-Identität von der Konsole aus im Cluster anmelden. Außerdem können Sie schreibgeschützte kubectl-Befehle auf anderen Computern als der Administratorworkstation ausführen. Dazu verwenden Sie ein spezielles kubeconfig, das 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