Nutzercluster mit GKE On-Prem API-Clients erstellen

Auf dieser Seite wird beschrieben, wie Sie einen Nutzercluster mithilfe der Google Cloud Console, der Google Cloud CLI (gcloud CLI) oder Terraform erstellen.

Was ist die GKE On-Prem API?

Die GKE On-Prem API ist eine von Google Cloud gehostete API, mit der Sie den Lebenszyklus Ihrer lokalen Cluster mithilfe von Terraform und Google Cloud-Standardanwendungen verwalten können. Die GKE On-Prem API wird in der Infrastruktur von Google Cloud ausgeführt. Terraform, die Console und die gcloud CLI sind Clients der API 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.

Wenn Sie möchten, können Sie einen Nutzercluster erstellen, indem Sie eine Nutzercluster-Konfigurationsdatei erstellen und bmctl verwenden, wie unter Nutzercluster erstellen beschrieben.

Wenn Sie Terraform, 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 Nutzercluster für die Verwaltung durch die GKE On-Prem API konfigurieren.

Hinweise

In diesem Abschnitt werden die Anforderungen zum Erstellen eines Nutzerclusters mit GKE On-Prem API-Clients beschrieben.

IAM-Berechtigungen gewähren

Wenn Sie kein Projektinhaber sind, muss Ihnen die Rolle roles/gkeonprem.admin gewährt werden.

Wenn Sie in der Console auf die GKE Enterprise- und Google Kubernetes Engine-Seiten zugreifen möchten, benötigen Sie außerdem die folgenden Rollen:

Wenn Sie nach dem Erstellen des Clusters kein Projektinhaber sind und das Connect-Gateway verwenden möchten, um über die Befehlszeile eine Verbindung zum Nutzercluster herzustellen, sind folgende Rollen erforderlich:

  • roles/gkehub.gatewayAdmin: Mit dieser Rolle können Sie auf die Connect Gateway API zugreifen. Wenn Sie nur Lesezugriff auf den Cluster benötigen, reicht roles/gkehub.gatewayReader aus.

  • roles/gkehub.viewer: Mit dieser Rolle können Sie Clusteranmeldedaten abrufen.

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

Erforderliche Google APIs

Achten Sie darauf, dass alle erforderlichen Google APIs im Flotten-Hostprojekt aktiviert sind.

Wenn Sie die gcloud CLI zum Erstellen des Clusters verwenden, müssen Sie die GKE On-Prem API aktivieren. Wenn Sie den Cluster über die Console erstellen, wird die GKE On-Prem API automatisch aktiviert.

gcloud services enable --project FLEET_HOST_PROJECT_ID \
    gkeonprem.googleapis.com

Voraussetzungen für Administratorcluster

Sie benötigen einen funktionierenden Administratorcluster, bevor Sie einen Nutzercluster erstellen können. Der Administratorcluster muss:

  • Sie haben nach der Erstellung Zugriff auf den Kubernetes API-Server im Nutzercluster.

  • Sie haben nach der Erstellung eine Netzwerkverbindung zu allen Knoten im Nutzercluster.

  • Muss bei einer Flotte registriert sein. Die Projekt-ID, die im Feld gkeConnect.projectID dieses Administratorclusters konfiguriert ist und als Flotten-Hostprojekt bezeichnet wird, muss das Projekt sein, in dem Sie den Nutzercluster erstellen.

Vorbereitung der Clusterknotenmaschinen

Prüfen Sie unter Voraussetzungen für Clusterknotenmaschinen, ob die Maschinen, auf denen der Nutzercluster ausgeführt wird, die Voraussetzungen erfüllen.

Befehlszeilenzugriff

Wenn Sie nach dem Erstellen des Clusters das Connect-Gateway verwenden möchten, um kubectl für den Nutzercluster 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.

Nutzercluster erstellen

Sie können mit Terraform, der Google Cloud Console oder der Google Cloud CLI (gcloud CLI) einen Cluster erstellen, der von der GKE On-Prem API verwaltet wird. Wenn Sie GKE on Bare Metal zum ersten Mal installieren, ist die Console möglicherweise das am einfachsten zu verwendende Tool.

Nachdem Sie mit den Informationen vertraut sind, die Sie zum Erstellen von Clustern angeben müssen, finden Sie Terraform oder die gcloud CLI möglicherweise hilfreicher, insbesondere wenn Sie mehr als einen Cluster erstellen werden. Terraform ist ein dem Branchenstandard entsprechendes Code-Tool. Wenn Ihre Organisation bereits Terraform verwendet, möchten Sie es wahrscheinlich zum Erstellen von Clustern und zum Verwalten des Clusterlebenszyklus verwenden.

Mit der gcloud CLI können Sie den Befehl mit seinen Argumenten in einer Textdatei speichern und bei Bedarf Änderungen vornehmen, um weitere Cluster zu erstellen. Wenn Sie ein CI/CD-Tool wie Cloud Build verwenden, können Sie mit den gcloud-Befehlen einen Cluster und Knotenpool erstellen und das Flag --impersonate-service-account angeben, um die Erstellung zu automatisieren.

Console

Die meisten Einstellungen in der Console entsprechen den Feldern in der Clusterkonfigurationsdatei.

  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. Dies muss dasselbe Projekt sein, bei dem der Administratorcluster registriert ist. Nachdem der Nutzercluster erstellt wurde, wird er automatisch bei der Flotte des ausgewählten Projekts registriert.

  3. Klicken Sie auf Weiter, um mit der Konfiguration des Clusters zu beginnen.

In den folgenden Abschnitten werden Sie durch die Konfiguration des Nutzerclusters geführt.

Clustergrundlagen

Geben Sie grundlegende Informationen zum Cluster ein.

  1. Geben Sie einen Namen für den Nutzercluster ein.

  2. Wählen Sie unter Administratorcluster den Administratorcluster aus der Liste 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 Metadaten des Nutzerclusters, 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. Wählen Sie die GKE on Bare Metal-Version für Ihren Nutzercluster aus. Nutzercluster müssen entweder dieselbe Nebenversion wie der Administratorcluster oder eine Nebenversion niedriger als der Administratorcluster haben.

  5. Als Ersteller des Clusters haben Sie Administratorberechtigungen für den Cluster. Geben Sie optional die E-Mail-Adresse eines anderen Nutzers, der den Cluster verwaltet, in das Feld Administrator ein.

    Beim Erstellen des Clusters wendet die GKE On-Prem API die Richtlinien für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes auf den Cluster an, um Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren, die vollständigen Zugriff auf alle Ressourcen im Cluster in allen Namespaces ermöglicht.

  6. Geben Sie im Abschnitt Knotenkonfiguration Folgendes an:

    • Maximale Anzahl von Pods pro Knoten: Geben Sie die maximale Anzahl von Pods ein, die auf einem einzelnen Knoten ausgeführt werden können. Die zulässigen Werte liegen im Bereich von 32 bis einschließlich 250. Kubernetes weist jedem Knoten einen CIDR-Block (Classless Inter-Domain Routing) zu, sodass jeder Pod eine eindeutige IP-Adresse haben kann. Die Größe des CIDR-Blocks entspricht der maximalen Anzahl von Pods pro Knoten. Weitere Informationen zum Festlegen der maximalen Anzahl von Pods pro Knoten finden Sie unter Pod-Netzwerke.

    • Containerlaufzeit: containerd ist die einzige verfügbare Containerlaufzeit für Ihren Cluster.

  7. Klicken Sie auf Weiter, um zum Abschnitt Netzwerk zu gelangen.

Netzwerk

In diesem Abschnitt geben Sie die IP-Adressen für die Knoten, Pods und Services Ihres Clusters an. Wenn Sie gebündeltes Load-Balancing mit MetalLB verwenden, konfigurieren Sie das ebenfalls.

  1. Geben Sie im Abschnitt Knoten der Steuerungsebene die IPv4-Adresse jedes Knotens der Steuerungsebene ein. Knoten der Steuerungsebene führen die Systemarbeitslast aus. In der Regel ist dies entweder eine einzelne Maschine, wenn eine Mindestbereitstellung verwendet wird, oder drei Maschinen, wenn eine Bereitstellung mit Hochverfügbarkeit verwendet wird. Geben Sie eine ungerade Anzahl von Knoten an, um ein Mehrheitsquorum für Hochverfügbarkeit zu haben. Dieses Feld kann bei jeder Aktualisierung oder Aktualisierung eines Clusters geändert werden.

    Klicken Sie nach Bedarf auf + IP-Adresse hinzufügen, um weitere IP-Adressen einzugeben.

  2. Wählen Sie im Abschnitt Load-Balancer den Load-Balancer aus der Liste Modus aus, den Sie für Ihren Cluster einrichten möchten. Weitere Informationen finden Sie unter Übersicht über Load-Balancer.

    Gebündelt mit MetalLB

    Konfigurieren Sie das Load-Balancing mit dem gebündelten MetalLB-Load-Balancer. Mit dieser Option stellt GKE on Bare Metal Layer-4-Load-Balancer bereit, die entweder auf einem dedizierten Pool von Worker-Knoten oder auf denselben Knoten wie die Steuerungsebene ausgeführt werden.

    1. Wählen Sie im Abschnitt Knotenpools des Load-Balancers eine der folgenden Optionen aus:

      • Knoten der Steuerungsebene verwenden: Wählen Sie diese Option aus, um die Load-Balancer auf denselben Knoten wie die Steuerungsebene auszuführen.

      • Load-Balancer-Knotenpool erstellen: Wählen Sie diese erweiterte Option aus, wenn Sie die Load-Balancer in einem dedizierten Pool von Worker-Knoten ausführen müssen. Alle Knoten im Load-Balancer-Knotenpool müssen sich im selben Layer-2-Subnetz wie die virtuellen IP-Adressen (VIPs) des Load-Balancers befinden, die Sie im Abschnitt Adresspools des Load-Balancers konfigurieren.

        1. Geben Sie im Feld IP 1 des Load-Balancer-Knotenpools eine IPv4-Adresse für einen Knoten in Ihrem Load-Balancer-Knotenpool ein.

        2. Klicken Sie bei Bedarf auf + IP-Adresse hinzufügen, um weitere IP-Adressen einzugeben.

    2. Fügen Sie im Abschnitt Adresspools des Load-Balancers einen oder mehrere Adresspools für den MetalLB-Controller hinzu, aus denen er auswählen und den Diensten vom Typ LoadBalancer zuweisen kann. Die virtuelle IP-Adresse für eingehenden Traffic, die Sie im Abschnitt Virtuelle IP-Adressen angeben, muss sich in einem dieser Pools befinden.

      1. Geben Sie einen Namen für den Adresspool ein.

      2. Geben Sie einen IP-Adressbereich in der CIDR-Schreibweise (z. B. 192.0.2.0/26) oder in Bereichsschreibweise (z. B. 192.0.2.64-192.0.2.72) ein. Verwenden Sie /32 in der CIDR-Notation, um eine einzelne IP-Adresse in einem Pool anzugeben (z. B. 192.0.2.1/32).

      3. Wenn sich die virtuelle IP-Adresse für eingehenden Traffic nicht im Adressbereich befindet, wählen Sie + IP-Adressbereich hinzufügen aus und geben Sie einen weiteren Adressbereich ein, der die virtuelle IP-Adresse für eingehenden Traffic enthält.

        Die IP-Adressen in den einzelnen Pools dürfen sich nicht überschneiden und müssen sich im selben Subnetz wie die Clusterknoten befinden.

      4. Wählen Sie unter Zuweisung von IP-Adressen eine der folgenden Optionen aus:

        • Automatisch: Wählen Sie diese Option aus, wenn der MetalLB-Controller Dienste vom Typ LoadBalancer automatisch IP-Adressen aus dem Adresspool zuweisen soll.
        • Manuell: Wählen Sie diese Option aus, wenn Sie Adressen aus dem Pool verwenden möchten, um Adressen für Dienste vom Typ LoadBalancer manuell anzugeben.

      5. Klicken Sie auf Fehlerhafte IP-Adressen vermeiden, wenn der MetalLB-Controller keine Adressen aus dem Pool verwenden soll, die auf .0 oder .255 enden. Dadurch wird verhindert, dass fehlerhafte Geräte versehentlich Traffic löschen, der an diese speziellen IP-Adressen gesendet wird.

      6. Klicken Sie zum Schluss auf Fertig.

      7. Klicken Sie ggf. auf Adresspool hinzufügen.

    Manueller Load-Balancer

    Beim manuellen Load-Balancing konfigurieren Sie Ihre eigenen Load-Balancing-Lösungen für Traffic der Steuerungsebene und der Datenebene. Sie müssen die virtuelle IP-Adresse der Steuerungsebene auf dem externen Load-Balancer konfigurieren, bevor Sie einen Cluster erstellen. Der externe Load-Balancer der Steuerungsebene kann auch für Traffic auf der Datenebene verwendet werden. Sie können auch einen separaten Load-Balancer für die Datenebene einrichten. Weitere Informationen finden Sie unter Manuelles Load-Balancing konfigurieren.

  3. Geben Sie im Abschnitt Virtuelle IP-Adressen Folgendes ein:

    • Virtuelle IP-Adresse der Steuerungsebene: Die Ziel-IP-Adresse, die für den an den Kubernetes API-Server des Nutzerclusters gesendeten Traffics verwendet werden soll. Die virtuelle IP-Adresse der Steuerungsebene muss sich im selben Subnetz wie die Load-Balancer-Knoten und nicht in einem der Adressbereiche befinden, die für die Load-Balancer-Adresspools verwendet werden.

    • Port: Der Zielport, der für den an den Kubernetes API-Server gesendeten Traffic verwendet wird. Der Standardwert ist 443.

    • Ingress-VIP: Die IP-Adresse, die auf dem Load-Balancer für den Ingress-Proxy konfiguriert werden soll. Geben Sie eine Adresse aus einem der Load-Balancer-Adresspools ein.

  4. Geben Sie im Abschnitt Dienst- und Pod-CIDRs die Kubernetes-Dienst- und Pod-IP-Adressbereiche in CIDR-Notation an. Sie dürfen sich nicht gegenseitig oder mit Adressen außerhalb des Clusters überschneiden, die Sie von innerhalb des Clusters erreichen möchten. Wir empfehlen die Verwendung der durch RFC 1918 definierten privaten IP-Adressbereiche. Die Console stellt die folgenden Standardadressbereiche bereit, die Sie jedoch ändern können:

    • Dienst-CIDR: 10.96.0.0/20 Wenn Sie den Standardwert nicht akzeptieren, geben Sie einen CIDR-Bereich zwischen /24 und /12 ein, wobei /12 die meisten IP-Adressen bereitstellt.

    • Pod-CIDR: 192.168.0.0/16 Wenn Sie den Standardwert nicht akzeptieren, geben Sie einen CIDR-Bereich zwischen /18 und /8 ein, wobei /8 die meisten IP-Adressen bereitstellt.

  5. Im Abschnitt Erweiterte Attribute können Sie optional Folgendes angeben:

    • Proxy-URL: Die HTTP-Adresse Ihres Proxyservers. Geben Sie die Portnummer an, auch wenn sie mit dem Standardport des Schemas übereinstimmt. Beispiel: http://my-proxy.example.local:80.

    • URLs: Eine durch Kommas getrennte Liste mit IP-Adressen, IP-Adressbereichen, Hostnamen und Domainnamen, die nicht über den Proxyserver geleitet werden sollen. Wenn GKE on Bare Metal eine Anfrage an eine dieser Adressen, Hosts oder Domains sendet, wird die Anfrage direkt gesendet.

  6. Klicken Sie auf Weiter.

Speicher

GKE on Bare Metal bietet Schnittstellen für Block- und Dateispeicher. Sie haben Standardoptionen, aber Sie können die Konfigurationen anpassen. Weitere Informationen finden Sie unter Lokalen Speicher konfigurieren.

  1. Optional können Sie Folgendes konfigurieren:

    • Knotenbereitstellungen des Bereitstellers lokaler Volumes: Gibt die Konfiguration für lokale PersistentVolumes (PVs) an, die auf bereitgestellten Laufwerken basieren. Sie müssen diese Laufwerke formatieren und bereitstellen, was vor oder nach der Clustererstellung erfolgen kann.

    • Freigabe des Bereitstellers lokaler Volumes: Gibt die Konfiguration für die lokale PersistentVolumes an, die von Unterverzeichnissen in einem freigegebenen Dateisystem gestützt wird. Diese Unterverzeichnisse werden bei der Clustererstellung automatisch erstellt.

  2. Klicken Sie auf Weiter.

Features

Folgende Funktionen werden automatisch aktiviert und können nicht deaktiviert werden, um das Monitoring, die Fehlerbehebung und den Betrieb Ihres Clusters zu vereinfachen:

Knotenpool erstellen

Der Cluster muss mindestens einen Knotenpool für Worker-Knoten haben. Ein Knotenpool ist eine Vorlage für die Gruppen von Worker-Knoten, die in diesem Cluster erstellt werden.

In der Console konfigurieren Sie mindestens einen Knotenpool (oder übernehmen die Standardwerte) und erstellen dann den Cluster. Sie können weitere Knotenpools hinzufügen, nachdem der Cluster erstellt wurde. Mit der gcloud CLI erstellen Sie zuerst den Cluster und fügen ihm dann einen oder mehrere Knotenpools hinzu.

  1. Klicken Sie in der linken Navigationsleiste auf Standardpool.

  2. Geben Sie im Abschnitt Knotenpoolstandards den Knotenpoolnamen ein oder akzeptieren Sie "default-pool" als Namen.

  3. Geben Sie im Abschnitt Worker-Knoten die IP-Adressen der Maschinen ein, auf denen der Cluster ausgeführt werden soll.

  4. Wenn Sie im Abschnitt Knotenpoolmetadaten (optional) Kubernetes-Labels und -Markierungen hinzufügen möchten, gehen Sie so vor:

    1. Klicken Sie auf + Kubernetes-Labels hinzufügen. Geben Sie den Schlüssel und den Wert für das Label ein. Wiederholen Sie diese Schritte für alle Suchabfragen, für die dies erforderlich ist.
    2. Klicken Sie auf + Markierung hinzufügen. Geben Sie den Schlüssel, den Wert und den Effekt für die Markierung ein. Wiederholen Sie diese Schritte für alle Suchabfragen, für die dies erforderlich ist.

  5. Klicken Sie auf Prüfen und abschließen, um den Nutzercluster zu erstellen. Das Erstellen des Nutzerclusters dauert mindestens 15 Minuten. Die Console zeigt Statusmeldungen an, während sie die Einstellungen überprüft und den Cluster in Ihrem Rechenzentrum erstellt.

    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

Sie verwenden den folgenden Befehl, um einen Nutzercluster zu erstellen:

gcloud container bare-metal clusters create

Nachdem Sie den Cluster erstellt haben, müssen Sie mit dem folgenden Befehl mindestens einen Knotenpool erstellen:

gcloud container bare-metal node-pools create

Die meisten Flags zum Erstellen des Clusters und des Knotenpools entsprechen den Feldern in der Konfigurationsdatei des Nutzerclusters. Sie können den vollständigen Befehl im Abschnitt Beispiele testen, um Ihnen den Einstieg zu erleichtern. Informationen zu den Flags finden Sie in den Abschnitten, die den Beispielen folgen, oder in der Referenz zur gcloud CLI.

Hinweise

Die GKE on Bare Metal-Version, die Sie beim Erstellen eines Nutzerclusters auswählen, muss eine Version sein, die von Ihrem Administratorcluster unterstützt wird. Darüber hinaus sind die neuesten Neben- oder Patchversionen erst 7 bis 10 Tage nach dem Release in der GKE On-Prem API verfügbar. Mit dem Befehl gcloud können Sie eine Liste der unterstützten Versionen abrufen, die Sie auf dem Nutzercluster installieren können.

  1. Aktualisieren Sie die Komponenten:

    gcloud components update

  2. Rufen Sie den Namen und den Standort der Flottenmitgliedschaft Ihres Administratorclusters ab:

    gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

    Ersetzen Sie FLEET_HOST_PROJECT_ID durch die ID des Projekts, für das der Administratorcluster registriert ist.

    Die Ausgabe sieht in etwa so aus:

    NAME             EXTERNAL_ID                           LOCATION
admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1

    Der Standort gibt an, wo die Fleet- und Connect-Dienste ausgeführt werden. Administratorcluster, die vor Version 1.28 erstellt wurden, werden von den globalen Fleet- und Connect-Diensten verwaltet. Ab Version 1.28 können Sie beim Erstellen des Administratorclusters entweder global oder eine Google Cloud-Region angeben. In den folgenden Beispielbefehlen geben Sie die Region im Flag --admin-cluster-membership-location an.

  3. Rufen Sie eine Liste der verfügbaren Versionen ab, die im Nutzercluster installiert werden können:

    gcloud container bare-metal clusters query-version-config \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION

    Ersetzen Sie Folgendes:

    • ADMIN_CLUSTER_NAME: Der Name des Administratorclusters.

    • FLEET_HOST_PROJECT_ID: Die ID des Projekts, für das der Administratorcluster registriert ist.

    • ADMIN_CLUSTER_REGION: Die Mitgliedschaftsregion des Administratorclusters. Dies ist entweder global oder eine Google Cloud-Region. Verwenden Sie den Standort für den Administratorcluster aus der Ausgabe von gcloud container fleet memberships list.

    • REGION: Die Google Cloud-Region, die Sie beim Erstellen des Clusters verwenden. 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.

    Die Ausgabe dieses Befehls sieht in etwa so aus:

    versions:
- version: 1.16.2
- version: 1.16.1
- version: 1.16.0
- version: 1.15.7
- version: 1.15.6
- version: 1.15.5

Wir empfehlen, die höchste unterstützte Version zu verwenden, um die neuesten Korrekturen und Verbesserungen zu erhalten.

Beispiele

Dieser Abschnitt enthält ein Beispiel für einen Befehl, der einen Cluster mit dem MetalLB-Load-Balancer erstellt, und ein Beispiel mit einem manuellen Load-Balancer. Welche Informationen Sie angeben, hängt vom Typ des verwendeten Load-Balancers ab. Weitere Informationen finden Sie unter Übersicht über Load-Balancer.

In den Beispielen wird der Cluster ohne Knotenpools erstellt. Nachdem der Cluster ausgeführt wurde, müssen Sie vor dem Bereitstellen von Arbeitslasten einen Knotenpool hinzufügen.

MetalLB

In diesem Beispiel wird gezeigt, wie Sie einen Nutzercluster mit dem gebündelten MetalLB-Load-Balancer erstellen.

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --metal-lb-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --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

Ersetzen Sie Folgendes:

  • USER_CLUSTER_NAME: Ein Name Ihrer Wahl für den Nutzercluster. Der Name kann nach dem Erstellen des Clusters nicht mehr geändert werden. Der Name muss:
    • darf höchstens 40 Zeichen enthalten.
    • darf nur kleingeschriebene, alphanumerische Zeichen und einen Bindestrich - enthalten.
    • Er muss mit einem Buchstaben beginnen.
    • Er muss mit einem alphanumerischen Zeichen enden.
  • FLEET_HOST_PROJECT_ID: Die ID des Projekts, in dem Sie den Cluster erstellen möchten. Das angegebene Projekt wird auch als Flotten-Hostprojekt verwendet. Dies muss dasselbe Projekt sein, für das der Administratorcluster registriert ist. Nachdem der Nutzercluster erstellt wurde, wird er automatisch bei der Flotte des ausgewählten Projekts registriert. Das Flotten-Hostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.
  • ADMIN_CLUSTER_NAME: Der Name des Administratorclusters, der den Nutzercluster verwaltet. Im Flag --admin-cluster-membership können Sie den vollständig angegebenen Clusternamen verwenden, der folgendes Format hat: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    Alternativ können Sie --admin-cluster-membership auf den Namen des Administratorclusters festlegen, wie im Beispielbefehl. Wenn Sie nur den Namen des Administratorclusters verwenden, legen Sie die Projekt-ID des Administratorclusters mit der --admin-cluster-membership-project und den Standort mit --admin-cluster-membership-location fest. Der Standort des Administratorclusters ist entweder global oder eine Google Cloud-Region. Wenn Sie die Region ermitteln müssen, führen Sie gcloud container fleet memberships list aus.

  • REGION: Die Google Cloud-Region, in der die GKE On-Prem API (gkeonprem.googleapis.com), der Flottendienst (gkehub.googleapis.com) und der Connect-Dienst (gkeconnect.googleapis.com) ausgeführt werden. 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 Nutzerclustermetadaten, 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 GKE on Bare Metal-Version für Ihren Nutzercluster.
  • YOUR_EMAIL_ADDRESS und ANOTHER_EMAIL_ADDRESS: Wenn Sie das Flag --admin-users nicht als Ersteller des Clusters angeben, erhalten Sie standardmäßig Administratorberechtigungen für den Cluster. Wenn Sie jedoch --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, wird der Standardwert überschrieben und Sie müssen sowohl Ihre E-Mail-Adresse als auch die E-Mail-Adresse des anderen Administrators angeben. So fügen Sie beispielsweise zwei Administratoren hinzu: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Beim Erstellen des Clusters wendet die GKE On-Prem API die Richtlinien für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes auf den Cluster an, um Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren, die vollständigen Zugriff auf alle Ressourcen im Cluster in allen Namespaces ermöglicht.

MetalLB-Adresspools

  • --metal-lb-address-pools: Geben Sie die Konfiguration für Adresspools an, die vom MetalLB-Load-Balancer verwendet werden sollen. Der Wert für das Flag hat folgendes Format:
'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

Der Wert enthält Segmente, die mit den Keywords pool, avoid-buggy-ip, manual-assign und addresses beginnen. Trennen Sie die Segmente durch Kommas.

  • pool: Ein Name Ihrer Wahl für den Pool.

  • avoid-buggy-ips: Wenn Sie diesen Wert auf True festlegen, weist der MetalLB-Controller Diensten keine IP-Adressen mit der Endung .0 oder .255 zu. Dadurch wird das Problem vermieden, dass fehlerhafte Nutzergeräte den an diese speziellen IP-Adressen gesendeten Traffic versehentlich unterbrechen. Wenn keine Angabe erfolgt, wird standardmäßig False verwendet.

  • manual-assign: Wenn der MetalLB-Controller nicht automatisch IP-Adressen aus diesem Pool Diensten zuweisen soll, legen Sie True fest. Anschließend kann ein Entwickler einen Service vom Typ LoadBalancer erstellen und manuell eine der Adressen aus dem Pool angeben. Wenn keine Angabe erfolgt, wird manual-assign auf False gesetzt.

  • In der Liste der addresses: Jede Adresse muss ein Bereich im Format CIDR oder mit Bindestrich sein. Wenn Sie eine einzelne IP-Adresse in einem Pool angeben möchten (z. B. für die virtuelle IP-Adresse für eingehenden Traffic), verwenden Sie /32 in CIDR-Notation (z. B. 192.0.2.1/32).

Beachten Sie die folgenden Syntaxregeln:

  • Setzen Sie den gesamten Wert in einfache Anführungszeichen.
  • Leerzeichen sind nicht zulässig.
  • Trennen Sie die einzelnen IP-Adressbereiche durch ein Semikolon.

Sie können mehr als eine Instanz des Flags angeben, wie im folgenden Beispiel gezeigt:

--metal-lb-address-pools='pool=pool1,avoid-buggy-ips=False,manual-assign=True,addresses=192.0.2.0/26;192.0.2.64-192.0.2.72'
--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.133.0/24;10.251.134.80/32'

MetalLB-Knoten

  • Optional: --metal-lb-load-balancer-node-configs: Standardmäßig wird der Load-Balancer auf denselben Knoten wie die Steuerungsebene ausgeführt. Wenn Sie den Load-Balancer in einem dedizierten Pool von Worker-Knoten ausführen müssen, geben Sie dieses Flag für jeden Knoten an. Alle Knoten im Knotenpool des Load-Balancers müssen sich im selben Layer-2-Subnetz wie die virtuellen IP-Adressen (VIPs) des Load-Balancers befinden.

    Der Wert für das Flag hat folgendes Format:

    'node-ip=LB_IP_ADDRESS_1,labels=LB_KEY_1.1=LB_VALUE_1.1;LB_KEY_1.2=LB_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 in Ihrem Knotenpool des Load-Balancers. 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.

    Wenn Sie --metal-lb-load-balancer-node-configs angeben, können Sie optional die folgenden Flags angeben:

    • --metal-lb-load-balancer-node-labels: Verwenden Sie dieses Flag, um allen Knoten im Knotenpool des Load-Balancers Labels hinzuzufügen. Trennen Sie die Liste der Schlüssel/Wert-Paare durch ein Komma.

      --metal-lb-load-balancer-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2

    • --metal-lb-load-balancer-node-taints: Verwenden Sie dieses Flag, um allen Knoten im Load-Balancer-Knotenpool Markierungen hinzuzufügen. Jede Markierung ist ein Schlüssel/Wert-Paar, das einer Auswirkung zugeordnet ist. Es muss eines der folgenden Werte sein: PreferNoSchedule, NoSchedule oder NoExecute.

      --metal-lb-load-balancer-node-taints=KEY_1=VALUE_1:EFFECT_1,KEY_2=VALUE_2:EFFECT_2

    Im folgenden Beispiel werden dem Knotenpool des Load-Balancers drei Knoten hinzugefügt. Alle Knoten sind mit lb-pool-key=lb-pool-value gekennzeichnet und haben die Markierung dedicated=experimental:PreferNoSchedule.

    --metal-lb-load-balancer-node-configs='node-ip=192.0.2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
--metal-lb-load-balancer-node-labels=lb-pool-key=lb-pool-value \
--metal-lb-load-balancer-node-taints=dedicated=experimental:PreferNoSchedule \

Knoten der Steuerungsebene

  • --control-plane-node-configs: 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 oder Aktualisierung eines 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 die einzelnen Schlüssel/Wert-Paare im labels-Segment durch ein Semikolon.

    Fügen Sie optional die folgenden Flags hinzu:

  • --control-plane-node-labels: Verwenden Sie dieses Flag, um allen Knoten der Steuerungsebene Labels hinzuzufügen. Trennen Sie die Liste der Schlüssel/Wert-Paare durch ein Komma. 
      --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
  • --control-plane-node-taints: Verwenden Sie dieses Flag, um allen Knoten der Steuerungsebene Markierungen hinzuzufügen. Jede Markierung ist ein Schlüssel/Wert-Paar, das einer Wirkung zugeordnet ist. Es muss einer der folgenden Werte sein: PreferNoSchedule, NoSchedule oder NoExecute.

    Im folgenden Beispiel werden den Knoten der Steuerungsebene drei Knoten hinzugefügt. Alle Knoten sind mit cp-node-pool-key=cp-node-pool-value gekennzeichnet und haben die Markierung dedicated=experimental:PreferNoSchedule.

      --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-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

Virtuelle IP-Adressen

  • CONTROL_PLANE_VIP: Die IP-Adresse, die Sie auf dem Load-Balancer für den Kubernetes API-Server des Nutzerclusters konfiguriert haben.

    Beispiel: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: Der Port, über den der Load-Balancer den Kubernetes API-Server bedient.

    Beispiel: -control-plane-load-balancer-port=443

  • INGRESS_VIP: Die IP-Adresse, die Sie auf dem Load-Balancer für den Ingress-Proxy konfigurieren möchten.

    Beispiel: --ingress-vip=10.251.134.80

    Die IP-Adresse für die virtuelle IP-Adresse für eingehenden Traffic muss sich in einem der MetalLB-Adresspools befinden.

Dienst- und Pod-CIDRs

  • SERVICE_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, die für Dienste in Ihrem Cluster verwendet werden sollen. Der CIDR-Bereich muss zwischen /24 und /12 liegen, wobei /12 die meisten IP-Adressen bereitstellt.

    Beispiel: --island-mode-service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, der für Pods in Ihrem Cluster verwendet werden soll. Der CIDR-Bereich muss zwischen /18 und /8 liegen, wobei /8 die meisten IP-Adressen bereitstellt.

    Beispiel: --island-mode-pod-address-cidr-blocks=192.168.0.0/16

Speicher

  1. --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.
  2. --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.
  3. --lvp-node-mounts-config-path: Dies ist der Pfad zum Hostcomputer, in dem bereitgestellte Laufwerke erkannt werden können. Für jede Bereitstellung wird ein lokales nichtflüchtiges Volume (PV) erstellt.
  4. --lvp-node-mounts-config-storage: Die Speicherklasse, mit der PVs bei der Clustererstellung erstellt werden.

Weitere Informationen zum Speichern finden Sie unter Lokalen Speicher konfigurieren.

Manuell

Beim manuellen Load-Balancing konfigurieren Sie Ihre eigenen Load-Balancing-Lösungen für Traffic der Steuerungsebene und der Datenebene. Sie müssen die virtuelle IP-Adresse der Steuerungsebene auf dem externen Load-Balancer konfigurieren, bevor Sie einen Cluster erstellen. Der externe Load-Balancer der Steuerungsebene kann auch für Traffic auf der Datenebene verwendet werden. Sie können auch einen separaten Load-Balancer für die Datenebene einrichten. Weitere Informationen finden Sie unter Manuelles Load-Balancing konfigurieren.

Scrollen Sie gegebenenfalls nach unten, um den Platzhalter ADMIN_CLUSTER_NAME für das Flag --admin-cluster-membership auszufüllen.

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --enable-manual-lb \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --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

Ersetzen Sie Folgendes:

  • USER_CLUSTER_NAME: Ein Name Ihrer Wahl für den Nutzercluster. Der Name kann nach dem Erstellen des Clusters nicht mehr geändert werden. Der Name muss:
    • darf höchstens 40 Zeichen enthalten.
    • darf nur kleingeschriebene, alphanumerische Zeichen und einen Bindestrich - enthalten.
    • Er muss mit einem Buchstaben beginnen.
    • Er muss mit einem alphanumerischen Zeichen enden.
  • FLEET_HOST_PROJECT_ID: Die ID des Projekts, in dem Sie den Cluster erstellen möchten. Das angegebene Projekt wird auch als Flotten-Hostprojekt verwendet. Dies muss dasselbe Projekt sein, für das der Administratorcluster registriert ist. Nachdem der Nutzercluster erstellt wurde, wird er automatisch bei der Flotte des ausgewählten Projekts registriert. Das Flotten-Hostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.
  • ADMIN_CLUSTER_NAME: Der Name des Administratorclusters, der den Nutzercluster verwaltet. Im Flag --admin-cluster-membership können Sie den vollständig angegebenen Clusternamen verwenden, der folgendes Format hat: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    Alternativ können Sie --admin-cluster-membership auf den Namen des Administratorclusters festlegen, wie im Beispielbefehl. Wenn Sie nur den Namen des Administratorclusters verwenden, legen Sie die Projekt-ID des Administratorclusters mit der --admin-cluster-membership-project und den Standort mit --admin-cluster-membership-location fest. Der Standort des Administratorclusters ist entweder global oder eine Google Cloud-Region. Wenn Sie die Region ermitteln müssen, führen Sie gcloud container fleet memberships list aus.

  • REGION: Die Google Cloud-Region, in der die GKE On-Prem API (gkeonprem.googleapis.com), der Flottendienst (gkehub.googleapis.com) und der Connect-Dienst (gkeconnect.googleapis.com) ausgeführt werden. 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 Nutzerclustermetadaten, 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 GKE on Bare Metal-Version für Ihren Nutzercluster.
  • YOUR_EMAIL_ADDRESS und ANOTHER_EMAIL_ADDRESS: Wenn Sie das Flag --admin-users nicht als Ersteller des Clusters angeben, erhalten Sie standardmäßig Administratorberechtigungen für den Cluster. Wenn Sie jedoch --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, wird der Standardwert überschrieben und Sie müssen sowohl Ihre E-Mail-Adresse als auch die E-Mail-Adresse des anderen Administrators angeben. So fügen Sie beispielsweise zwei Administratoren hinzu: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Beim Erstellen des Clusters wendet die GKE On-Prem API die Richtlinien für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes auf den Cluster an, um Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren, die vollständigen Zugriff auf alle Ressourcen im Cluster in allen Namespaces ermöglicht.

Knoten der Steuerungsebene

  • --control-plane-node-configs: 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 oder Aktualisierung eines 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 die einzelnen Schlüssel/Wert-Paare im labels-Segment durch ein Semikolon.

    Fügen Sie optional die folgenden Flags hinzu:

  • --control-plane-node-labels: Verwenden Sie dieses Flag, um allen Knoten der Steuerungsebene Labels hinzuzufügen. Trennen Sie die Liste der Schlüssel/Wert-Paare durch ein Komma. 
      --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
  • --control-plane-node-taints: Verwenden Sie dieses Flag, um allen Knoten der Steuerungsebene Markierungen hinzuzufügen. Jede Markierung ist ein Schlüssel/Wert-Paar, das einer Wirkung zugeordnet ist. Es muss einer der folgenden Werte sein: PreferNoSchedule, NoSchedule oder NoExecute.

    Im folgenden Beispiel werden den Knoten der Steuerungsebene drei Knoten hinzugefügt. Alle Knoten sind mit cp-node-pool-key=cp-node-pool-value gekennzeichnet und haben die Markierung dedicated=experimental:PreferNoSchedule.

      --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-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

Virtuelle IP-Adressen

  • CONTROL_PLANE_VIP: Die IP-Adresse, die Sie auf dem Load-Balancer für den Kubernetes API-Server des Nutzerclusters konfiguriert haben.

    Beispiel: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: Der Port, über den der Load-Balancer den Kubernetes API-Server bedient.

    Beispiel: -control-plane-load-balancer-port=443

  • INGRESS_VIP: Die IP-Adresse, die Sie auf dem Load-Balancer für den Ingress-Proxy konfigurieren möchten.

    Beispiel: --ingress-vip=10.251.134.80

    Die IP-Adresse für die virtuelle IP-Adresse für eingehenden Traffic muss sich in einem der MetalLB-Adresspools befinden.

Dienst- und Pod-CIDRs

  • SERVICE_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, die für Dienste in Ihrem Cluster verwendet werden sollen. Der CIDR-Bereich muss zwischen /24 und /12 liegen, wobei /12 die meisten IP-Adressen bereitstellt.

    Beispiel: --island-mode-service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: Ein Bereich von IP-Adressen im CIDR-Format, der für Pods in Ihrem Cluster verwendet werden soll. Der CIDR-Bereich muss zwischen /18 und /8 liegen, wobei /8 die meisten IP-Adressen bereitstellt.

    Beispiel: --island-mode-pod-address-cidr-blocks=192.168.0.0/16

Speicher

  1. --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.
  2. --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.
  3. --lvp-node-mounts-config-path: Dies ist der Pfad zum Hostcomputer, in dem bereitgestellte Laufwerke erkannt werden können. Für jede Bereitstellung wird ein lokales nichtflüchtiges Volume (PV) erstellt.
  4. --lvp-node-mounts-config-storage: Die Speicherklasse, mit der PVs bei der Clustererstellung erstellt werden.

Weitere Informationen zum Speichern finden Sie unter Lokalen Speicher konfigurieren.

Bevor Sie den Befehl gcloud zum Erstellen des Clusters ausführen, sollten Sie --validate-only einschließen, um die Konfiguration zu validieren, die Sie in den Flags für den Befehl gcloud angegeben haben. Wenn Sie bereit sind, den Cluster zu erstellen, entfernen Sie dieses Flag und führen den Befehl aus.

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

Das Erstellen des Nutzerclusters dauert mindestens 15 Minuten. Sie können den Cluster in der Google Cloud Console auf der Seite GKE-Cluster ansehen.

Eine vollständige Liste der Flags und ihrer Beschreibungen finden Sie in der Referenz zur gcloud CLI.

Knotenpool erstellen

Nachdem der Cluster erstellt wurde, müssen Sie mindestens einen Knotenpool erstellen, bevor Sie Arbeitslasten bereitstellen. Ein Knotenpool ist eine Vorlage für die in diesem Cluster erstellten Gruppen von Worker-Knoten. Mit der gcloud CLI erstellen Sie zuerst den Cluster und fügen ihm dann einen oder mehrere Knotenpools hinzu.

gcloud container bare-metal node-pools create NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --node-configs='node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...'

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME: Ein Name Ihrer Wahl für den Knotenpool. Der Name:

    • darf höchstens 40 Zeichen enthalten.
    • darf nur kleingeschriebene, alphanumerische Zeichen und einen Bindestrich - enthalten.
    • Er muss mit einem Buchstaben beginnen.
    • Er muss mit einem alphanumerischen Zeichen enden.

  • USER_CLUSTER_NAME: Der Name des neu erstellten Nutzerclusters.

  • FLEET_HOST_PROJECT_ID: Die ID des Projekts, für das der Cluster registriert ist.

  • REGION: Die Google Cloud-Region, die Sie beim Erstellen des Clusters angegeben haben.

  • --node-configs: Die IPv4-Adresse einer Worker-Knotenmaschine. Geben Sie dieses Flag für jeden Knoten an. Der Wert für das Flag hat folgendes Format:

    'node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_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 Worker-Knotens. Sie können nur ein node-ip pro Flag angeben. Fügen Sie dieses Flag noch einmal für jeden Knoten im Knotenpool 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.

    Optional können Sie Folgendes angeben:

    • --node-labels=KEY=VALUE,...: Eine durch Kommas getrennte Liste von Kubernetes-Labels (Schlüssel/Wert-Paaren), die auf jeden Knoten im Pool angewendet werden.

    • --node-taints=KEY=VALUE:EFFECT,... Eine durch Kommas getrennte Liste von Kubernetes-Markierungen, die auf jeden Knoten im Pool angewendet werden. Markierungen sind Schlüssel/Wert-Paare, die einem Effekt zugeordnet sind. Markierungen werden mit Toleranzen für die Pod-Planung verwendet. Geben Sie für EFFECT einen der folgenden Werte an: NoSchedule, PreferNoSchedule oder NoExecute.

Im folgenden Beispiel wird ein Knotenpool namens default-pool auf user-cluster- erstellt und dem Knotenpool zwei Knoten hinzugefügt. Alle beiden Knoten sind mit node-pool-key=node-pool-value gekennzeichnet und haben die Markierung dedicated=experimental:PreferNoSchedule.

gcloud container bare-metal node-pools create default-pool \
  --cluster=user-cluster-1  \
  --project=example-project-12345 \
  --location=us-west1 \
  --node-configs='node-ip=10.200.0.10' \
  --node-configs='node-ip=10.200.0.11,labels=key2.1=value2.1' \
  --node-labels=node-pool-key=node-pool-value \
  --node-taints=dedicated=experimental:PreferNoSchedule

Weitere Informationen finden Sie in der Referenz zur gcloud CLI.

Terraform

Hinweise

Die GKE on Bare Metal-Version, die Sie beim Erstellen eines Nutzerclusters auswählen, muss eine Version sein, die von Ihrem Administratorcluster unterstützt wird. Darüber hinaus sind die neuesten Neben- oder Patchversionen erst 7 bis 10 Tage nach dem Release in der GKE On-Prem API verfügbar. Mit dem Befehl gcloud können Sie eine Liste der unterstützten Versionen abrufen, die Sie auf dem Nutzercluster installieren können.

  1. Aktualisieren Sie die Komponenten:

    gcloud components update

  2. Rufen Sie den Namen und den Standort der Flottenmitgliedschaft Ihres Administratorclusters ab:

    gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

    Ersetzen Sie FLEET_HOST_PROJECT_ID durch die ID des Projekts, für das der Administratorcluster registriert ist.

    Die Ausgabe sieht in etwa so aus:

    NAME             EXTERNAL_ID                           LOCATION
admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1

    Der Standort gibt an, wo die Fleet- und Connect-Dienste ausgeführt werden. Administratorcluster, die vor Version 1.28 erstellt wurden, werden von den globalen Fleet- und Connect-Diensten verwaltet. Ab Version 1.28 können Sie beim Erstellen des Administratorclusters entweder global oder eine Google Cloud-Region angeben. In den folgenden Beispielbefehlen geben Sie die Region im Flag --admin-cluster-membership-location an.

  3. Rufen Sie eine Liste der verfügbaren Versionen ab, die im Nutzercluster installiert werden können:

    gcloud container bare-metal clusters query-version-config \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION

    Ersetzen Sie Folgendes:

    • ADMIN_CLUSTER_NAME: Der Name des Administratorclusters.

    • FLEET_HOST_PROJECT_ID: Die ID des Projekts, für das der Administratorcluster registriert ist.

    • ADMIN_CLUSTER_REGION: Die Mitgliedschaftsregion des Administratorclusters. Dies ist entweder global oder eine Google Cloud-Region. Verwenden Sie den Standort für den Administratorcluster aus der Ausgabe von gcloud container fleet memberships list.

    • REGION: Die Google Cloud-Region, die Sie beim Erstellen des Clusters verwenden. 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.

    Die Ausgabe dieses Befehls sieht in etwa so aus:

    versions:
- version: 1.16.2
- version: 1.16.1
- version: 1.16.0
- version: 1.15.7
- version: 1.15.6
- version: 1.15.5

Wir empfehlen, die höchste unterstützte Version zu verwenden, um die neuesten Korrekturen und Verbesserungen zu erhalten.

Beispiel

Sie können das folgende grundlegende Konfigurationsbeispiel verwenden, um einen Nutzercluster mit gebündeltem MetalLB-Load-Balancer zu erstellen. Weitere Informationen finden Sie in der Referenzdokumentation zu google_gkeonprem_bare_metal_cluster.

Variablen in terraform.tfvars festlegen

Das Beispiel enthält eine Beispieldatei mit Variablen, die an main.tf übergeben werden kann. Dies zeigt, wie der gebündelte MetalLB-Load-Balancer konfiguriert wird.

  1. Klonen Sie das anthos-samples-Repository und wechseln Sie in das Verzeichnis, in dem sich das Terraform-Beispiel befindet:

    git clone https://github.com/GoogleCloudPlatform/anthos-samples
cd anthos-samples/anthos-onprem-terraform/abm_user_cluster_metallb

    Das Beispiel enthält eine Beispielvariablendatei zur Übergabe an main.tf.

  2. Erstellen Sie eine Kopie der Datei terraform.tfvars.sample:

    cp terraform.tfvars.sample terraform.tfvars

  3. Ändern Sie die Parameterwerte in terraform.tfvars und speichern Sie die Datei.

    
project_id          = "PROJECT_ID"
region              = "ON_PREM_API_REGION"
admin_cluster_name  = "ADMIN_CLUSTER_NAME"
bare_metal_version  = "VERSION"
admin_user_emails   = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
cluster_name        = "abm-user-cluster-metallb"
control_plane_ips   = ["10.200.0.4"]
worker_node_ips     = ["10.200.0.5", "10.200.0.6"]
control_plane_vip   = "10.200.0.50"
ingress_vip         = "10.200.0.51"
lb_address_pools    = [
    { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
]

    In der folgenden Liste werden die Variablen beschrieben:

    • project_id: Die ID des Projekts, in dem Sie den Cluster erstellen möchten. Das angegebene Projekt wird auch als Flotten-Hostprojekt verwendet. Dies muss dasselbe Projekt sein, für das der Administratorcluster registriert ist. Nachdem der Nutzercluster erstellt wurde, wird er automatisch bei der Flotte des ausgewählten Projekts registriert. 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 (gkeonprem.googleapis.com), der Flottendienst (gkehub.googleapis.com) und der Connect-Dienst (gkeconnect.googleapis.com) ausgeführt werden. Geben Sie us-west1 oder eine andere unterstützte Region an.

    • admin_cluster_name: Der Name des Administratorclusters, der den Nutzercluster verwaltet. Im Beispiel wird davon ausgegangen, dass der Administratorcluster global als Region verwendet. Wenn Sie einen regionalen Administratorcluster haben:

      1. Öffnen Sie main.tf in einem Texteditor.

      2. Suchen Sie nach admin_cluster_membership, das in etwa so aussieht:

        admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"

      3. Ändern Sie global in die Region, die der Administratorcluster verwendet, und speichern Sie die Datei.

    • bare_metal_version: Die GKE on Bare Metal-Version für Ihren Nutzercluster. Geben Sie entweder die Version des Administratorclusters oder eine Version an, die nicht mehr als eine Nebenversion niedriger als der Administratorcluster ist.

    • admin_user_emails: Eine Liste der E-Mail-Adressen der Nutzer, denen Administratorberechtigungen für den Cluster gewährt werden sollen. Fügen Sie unbedingt Ihre E-Mail-Adresse hinzu, wenn Sie den Cluster verwalten möchten.

      Beim Erstellen des Clusters wendet die GKE On-Prem API die Richtlinien für die rollenbasierte Zugriffssteuerung (Role-based Access Control, RBAC) von Kubernetes auf den Cluster an, um den Administratornutzern die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren, die vollständigen Zugriff auf jede Ressource im Cluster in allen Namespaces bietet. Auf diese Weise können sich Nutzer auch mit ihrer Google-Identität in der Konsole anmelden.

    • cluster_name: Ein Name Ihrer Wahl für Ihren Nutzercluster. Der Name kann nach dem Erstellen des Clusters nicht mehr geändert werden. Der Name:

      • darf höchstens 40 Zeichen enthalten.
      • darf nur kleingeschriebene, alphanumerische Zeichen und einen Bindestrich - enthalten.
      • Er muss mit einem Buchstaben beginnen.
      • Er muss mit einem alphanumerischen Zeichen enden.

    • control_plane_ips: Eine Liste mit einer oder mehreren IPv4-Adressen für die Knoten der Steuerungsebene. Knoten der Steuerungsebene führen die Systemarbeitslast aus. 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 oder Aktualisierung eines Clusters ändern.

    • worker_node_ips: Eine Liste mit einer oder mehreren IPv4-Adressen für die Maschinen mit Worker-Knoten.

    • control_plane_vip: Die virtuelle IP-Adresse (VIP), die Sie für den Load-Balancer für den Kubernetes API-Server des Nutzerclusters konfiguriert haben.

    • ingress_vip: Die IP-Adresse, die Sie für den Load-Balancer für den Ingress-Proxy konfiguriert haben.

    • lb_address_pools: Eine Liste von Zuordnungen, die die vom MetalLB-Load-Balancer zu verwendenden Adresspools definieren. Die virtuelle IP-Adresse für eingehenden Traffic muss sich in einem dieser Pools befinden.

  4. Speichern Sie die Änderungen in terraform.tfvars.

  5. Initialisieren und erstellen Sie den Terraform-Plan:

    terraform init

    Terraform installiert alle erforderlichen Bibliotheken, z. B. den Google Cloud-Anbieter.

  6. Überprüfen Sie die Konfiguration und nehmen Sie bei Bedarf Änderungen vor:

    terraform plan

  7. Wenden Sie den Terraform-Plan an, um den Nutzercluster zu erstellen:

    terraform apply

    Das Erstellen des Nutzerclusters dauert mindestens 15 Minuten. Sie können den Cluster in der Google Cloud Console auf der Seite GKE-Cluster ansehen.

Verbindung zum Nutzercluster herstellen

Wenn Sie einen Nutzercluster in der Console erstellen, wird der Cluster mit den Kubernetes-Richtlinien für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) konfiguriert, sodass Sie sich mit Ihrer Google Cloud Identity beim Cluster anmelden können. Wenn Sie einen Nutzercluster mit der gcloud CLI erstellen, werden Ihnen standardmäßig diese RBAC-Richtlinien gewährt, wenn Sie das Flag --admin-users nicht einfügen. Wenn Sie --admin-users verwenden, um einen anderen Nutzer als Administrator festzulegen, wird der Standardwert überschrieben. Sie müssen dann sowohl Ihre E-Mail-Adresse als auch die E-Mail-Adresse des anderen Administrators angeben. Weitere Informationen zu den erforderlichen IAM- und RBAC-Richtlinien finden Sie unter Google-Identitätsauthentifizierung einrichten.

Alle Cluster haben einen kanonischen Endpunkt. Der Endpunkt macht den Kubernetes API-Server verfügbar, den kubectl und andere Dienste zur Kommunikation mit der Steuerungsebene des Clusters über TCP-Port 443 verwenden. Dieser Endpunkt ist im öffentlichen Internet nicht zugänglich. Wenn Sie über Ihre VPC Zugriff auf den privaten Endpunkt Ihres Clusters haben, können Sie eine direkte Verbindung zum privaten Endpunkt herstellen und direkt eine kubeconfig-Datei generieren. Andernfalls können Sie das Gateway verbinden.

Für den Zugriff auf den Nutzercluster über die Befehlszeile benötigen Sie eine kubeconfig-Datei. Es gibt zwei Möglichkeiten, eine kubeconfig-Datei abzurufen:

  • Verwenden Sie das Connect-Gateway, um von einem Computer mit installierter Google Cloud CLI aus auf den Cluster zuzugreifen. In diesem Fall verwendet kubectl die kubeconfig des Connect-Gateways, die den Traffic in Ihrem Namen sicher an den privaten Endpunkt weiterleitet.

  • Erstellen Sie für direkten Zugriff auf private Endpunkte eine kubeconfig-Datei auf Ihrer Administratorworkstation und verwalten Sie den Cluster von Ihrer Administratorworkstation aus.

Warten Sie, bis die Google Cloud Console anzeigt, dass der Nutzerclusterstatus fehlerfrei ist.

Connect-Gateway

  1. initialize Sie entweder die gcloud CLI für die Verwendung mit dem Flotten-Hostprojekt oder führen Sie die folgenden Befehle aus, um sich mit Ihrem Google-Konto anzumelden, Ihr Flotten-Hostprojekt als Standard festzulegen und die Komponenten zu aktualisieren:

    gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update

  2. Rufen Sie die Clusteranmeldedaten ab, die für die Interaktion mit dem Connect-Gateway verwendet werden. Ersetzen Sie im folgenden Befehl MEMBERSHIP_NAME durch den Namen Ihres Clusters. In GKE on Bare Metal ist der Name der Mitgliedschaft mit dem Clusternamen identisch.

    gcloud container fleet memberships get-credentials MEMBERSHIP_NAME

    Dieser Befehl gibt eine spezielle Connect-Gateway-spezifische kubeconfig zurück, mit der Sie über das Gateway eine Verbindung zum Cluster herstellen können.

Sobald Sie die erforderlichen Anmeldedaten haben, können Sie wie bei jedem Kubernetes-Cluster Befehle mit kubectl ausführen. Sie müssen den Namen der Datei kubeconfig nicht angeben. Beispiel:

kubectl get namespaces

Administratorworkstation

Verwenden Sie den Befehl bmctl get credentials, um eine kubeconfig-Datei für den neu erstellten Nutzercluster abzurufen.

bmctl get credentials --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Ersetzen Sie Folgendes:

  • CLUSTER_NAME gibt den Namen des Zielnutzerclusters an.

  • ADMIN_KUBECONFIG_PATH gibt den Pfad zur Datei kubeconfig des Administratorclusters an.

Ein kubeconfig mit den Anmeldedaten des Nutzerclusters wird in die Datei bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig geschrieben. Das TIMESTAMP im Dateinamen gibt das Datum und die Uhrzeit an, zu der die Datei erstellt wurde.

Da diese Datei Authentifizierungsdaten für den Cluster enthält, sollten Sie sie an einem sicheren Ort mit eingeschränktem Zugriff speichern.

Nächste Schritte