Nutzercluster mit GKE On-Prem API-Clients erstellen

Auf dieser Seite wird beschrieben, wie Sie einen Nutzercluster mit 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. Dabei wird die Google Cloud-Region verwendet, die Sie beim Erstellen des Clusters angeben. Mit diesen Metadaten kann die API den Clusterlebenszyklus verwalten. Sie enthalten keine arbeitslastspezifischen Daten.

Wenn Sie einen Cluster mit einem GKE On-Prem API-Client erstellen, geben Sie ein Google Cloud-Projekt an. Nachdem der Cluster erstellt wurde, wird er automatisch bei der Flotte des angegebenen Projekts registriert. Dieses Projekt wird als Flotten-Hostprojekt bezeichnet. Das Flotten-Hostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.

Wenn Sie möchten, können Sie einen 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 roles/gkeonprem.admin gewährt werden.

Wenn Sie in der Console auf die Seiten GKE Enterprise und Google Kubernetes Engine 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, ist roles/gkehub.gatewayReader ausreichend.

  • 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 verwenden, um den Cluster zu erstellen, 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 Zugriff auf den Kubernetes API-Server im Nutzercluster, nachdem dieser erstellt wurde.

  • Sie müssen nach dem Erstellen eine Netzwerkverbindung zu allen Knoten im Nutzercluster haben.

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

Vorbereitung der Clusterknotenmaschinen

Prüfen Sie die Voraussetzungen für Clusterknotenmaschinen, um dafür zu sorgen, dass 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 Terraform, die Google Cloud Console oder die Google Cloud CLI (gcloud CLI) verwenden, um einen Cluster zu 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.

Sobald Sie mit den Informationen vertraut sind, die Sie zum Erstellen von Clustern angeben müssen, können Sie Terraform oder die gcloud CLI als praktischer empfinden, insbesondere wenn Sie mehr als einen Cluster erstellen. Terraform ist ein branchenübliches Infrastruktur-als-Code-Tool. Wenn Ihre Organisation bereits Terraform verwendet, sollten Sie damit Cluster erstellen und den Clusterlebenszyklus verwalten.

Mit der gcloud CLI können Sie den Befehl mit seinen Argumenten in einer Textdatei speichern und nach Bedarf Änderungen vornehmen, um zusätzliche Cluster zu erstellen. Wenn Sie ein CI/CD-Tool wie Cloud Build verwenden, können Sie mit den gcloud-Befehlen einen Cluster und einen 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 Standort der Google Cloud API die Google Cloud-Region aus der Liste aus. Diese Einstellung gibt die Region an, in der die folgenden APIs und Dienste ausgeführt werden:

    • GKE On-Prem API (gkeonprem.googleapis.com)
    • Flottendienst (gkehub.googleapis.com)
    • Dienst verbinden (gkeconnect.googleapis.com)

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

    • Die 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

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

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

  5. Als Ersteller des Clusters erhalten Sie Administratorberechtigungen für den Cluster. Optional können Sie im Feld Administrator die E-Mail-Adresse eines anderen Nutzers eingeben, der den Cluster verwalten wird.

    Wenn der Cluster erstellt wird, 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 jede Ressource im Cluster in allen Namespaces bietet.

  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 zwischen 32 und 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-Netzwerk.

    • Containerlaufzeit: containerd ist die einzige verfügbare Containerlaufzeit für den 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 auch dieses.

  1. Geben Sie im Abschnitt Steuerungsebene die IPv4-Adressen 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 geändert werden, wenn Sie einen Cluster aktualisieren oder upgraden.

    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 Load-Balancer-Knotenpools 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 auf 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 Load-Balancer-Adresspools konfigurieren.

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

        2. Klicken Sie nach 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 hinzu, aus denen der MetalLB-Controller auswählen und diesen 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 entweder in CIDR-Notation (z. B. 192.0.2.0/26) oder in Bereichsnotation (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 die virtuelle IP-Adresse für eingehenden Traffic nicht im Adressbereich enthalten ist, 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 Services 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 den Traffic der Steuerungsebene und 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 der Datenebene verwendet werden. Sie können aber 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 Traffic verwendet werden soll, der an den Kubernetes API-Server des Nutzerclusters gesendet wird. Die virtuelle IP-Adresse der Steuerungsebene muss sich im selben Subnetz wie die Load-Balancer-Knoten befinden und darf sich nicht in einem der Adressbereiche befinden, die für die Load-Balancer-Adresspools verwendet werden.

    • Port: Der Zielport, der für Traffic verwendet wird, der an den Kubernetes API-Server gesendet 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 IP-Adressbereiche des Kubernetes-Dienstes und des Pods in CIDR-Notation an. Sie dürfen sich weder gegenseitig noch mit Adressen außerhalb des Clusters überschneiden, die Sie von innerhalb des Clusters erreichen möchten. Wir empfehlen, die durch RFC 1918 definierten privaten IP-Adressbereiche zu verwenden. Die Console bietet die folgenden Standardadressbereiche, 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 enthält.

    • 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. Optional können Sie im Abschnitt Erweiterte Attribute Folgendes angeben:

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

    • URLs: Eine durch Kommas getrennte Liste von 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) in Verbindung mit bereitgestellten Laufwerken an. Sie müssen diese Laufwerke formatieren und bereitstellen, was vor oder nach der Clustererstellung erfolgen kann.

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

  2. Klicken Sie auf Weiter.

Features

Für das Monitoring, die Fehlerbehebung und den Betrieb des Clusters sind die folgenden Komponenten automatisch aktiviert und können nicht deaktiviert werden:

Knotenpool erstellen

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

In der Console konfigurieren Sie mindestens einen Knotenpool (oder übernehmen die Standardwerte) und erstellen dann den Cluster. Sie können zusätzliche 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 Standardeinstellungen für Knotenpools 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 Knotenpool-Metadaten (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. In der Console werden Statusmeldungen angezeigt, während die Einstellungen überprüft und der Cluster in Ihrem Rechenzentrum erstellt wird.

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

gcloud-CLI

Mit dem folgenden Befehl erstellen Sie einen Nutzercluster:

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 für Nutzercluster. Für einen leichteren Einstieg können Sie den vollständigen Befehl im Abschnitt Beispiele testen. Informationen zu den Flags finden Sie in den Abschnitten nach den Beispielen 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 Ihr Administratorcluster unterstützt. 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. Sie können den Befehl gcloud ausführen, um eine Liste der unterstützten Versionen abzurufen, die Sie im 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 1.28 erstellt wurden, werden von den globalen Flotten- und Connect-Diensten verwaltet. In Version 1.28 und höher 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 sollen:

    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: Region der Flottenmitgliedschaft 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 and 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 Fehlerkorrekturen und Verbesserungen zu erhalten.

Beispiele

Dieser Abschnitt enthält ein Beispiel für einen Befehl, mit dem ein Cluster mit dem MetalLB-Load-Balancer erstellt wird, und ein Beispiel mit einem manuellen Load-Balancer. Die von Ihnen angegebenen Informationen variieren je nach Typ des zu verwendenden Load-Balancers. Weitere Informationen finden Sie unter Übersicht über Load-Balancer.

In den Beispielen wird der Cluster ohne Knotenpools erstellt. Wenn der Cluster ausgeführt wird, müssen Sie einen Knotenpool hinzufügen, bevor Sie Arbeitslasten bereitstellen.

MetalLB

Dieses Beispiel zeigt, 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 Ihren 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 im folgenden Format verwenden: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    Alternativ können Sie --admin-cluster-membership wie im Beispielbefehl auf den Namen des Administratorclusters festlegen. Wenn Sie nur den Namen des Administratorclusters verwenden, legen Sie die Projekt-ID des Administratorclusters mit --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 suchen, 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

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

  • 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 angeben, erhalten Sie als Clusterersteller standardmäßig Administratorberechtigungen für den Cluster. Wenn Sie jedoch --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, wird die Standardeinstellung überschrieben und es müssen sowohl Ihre E-Mail-Adresse als auch die des anderen Administrators enthalten sein. So fügen Sie beispielsweise zwei Administratoren hinzu: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Wenn der Cluster erstellt wird, wendet die GKE On-Prem API die Richtlinien der rollenbasierten 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. Diese gewährt vollständigen Zugriff auf jede Ressource im Cluster in allen Namespaces.

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 umfasst Segmente, die mit den Keywords pool, avoid-buggy-ip, manual-assign und addresses beginnen. Trennen Sie die einzelnen 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 zu, die auf .0 oder .255 enden. Dadurch wird das Problem vermieden, dass fehlerhafte Verbrauchergeräte versehentlich den an diese speziellen IP-Adressen gesendeten Traffic verwerfen. 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 diesen Wert auf True fest. Anschließend kann ein Entwickler einen Dienst 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 CIDR-Format oder als Bereich 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 auf 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 das folgende 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 umfasst Segmente, die mit den Keywords node-ip und labels beginnen. Trennen Sie die einzelnen Segmente durch Kommas.

    • node-ip: Die IP-Adresse eines Knotens in Ihrem Load-Balancer-Knotenpool. Sie können nur eine node-ip pro Flag angeben. Wenn Sie mehr als einen Knoten angeben müssen, fügen Sie das Flag noch einmal für jeden Knoten hinzu.

    • labels: Ein oder mehrere Schlüssel/Wert-Paare, die an den Knoten angehängt sind.

    Beachten Sie die folgenden Syntaxregeln:

    • Setzen Sie den gesamten Wert in einfache Anführungszeichen.
    • Leerzeichen sind nicht zulässig.
    • Trennen Sie jedes Schlüssel/Wert-Paar im labels-Segment durch ein Semikolon.

    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 Load-Balancer-Knotenpool 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 einem Effekt zugeordnet ist. Dabei muss es sich um einen der folgenden Werte handeln: 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 Load-Balancer-Knotenpool 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 jedem Update oder Upgrade eines Clusters ä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 umfasst Segmente, die mit den Keywords node-ip und labels beginnen. Trennen Sie die einzelnen Segmente durch Kommas.

  • node-ip: Die IP-Adresse eines Knotens der Steuerungsebene. Sie können nur eine node-ip pro Flag angeben. Wenn Sie mehr als einen Knoten angeben müssen, fügen Sie das Flag noch einmal für jeden Knoten hinzu.
  • labels: Ein oder mehrere Schlüssel/Wert-Paare, die an den Knoten angehängt sind.

    Beachten Sie die folgenden Syntaxregeln:

    • Setzen Sie den gesamten Wert in einfache Anführungszeichen.
    • Leerzeichen sind nicht zulässig.
    • Trennen Sie 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 einem Effekt zugeordnet ist. Dabei muss es sich um einen der folgenden Werte handeln: 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 konfiguriert haben.

    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, der für Dienste in Ihrem Cluster verwendet wird. Der CIDR-Bereich muss zwischen /24 und /12 liegen, wobei /12 die meisten IP-Adressen bietet.

    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 wird. Der CIDR-Bereich muss zwischen /18 und /8 liegen, wobei /8 die meisten IP-Adressen bietet.

    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 wird. 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 während der Clustererstellung erstellt werden.

Weitere Informationen zum Speicher finden Sie unter Lokalen Speicher konfigurieren.

Manuell

Beim manuellen Load-Balancing konfigurieren Sie Ihre eigenen Load-Balancing-Lösungen für den Traffic der Steuerungsebene und 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 der Datenebene verwendet werden. Sie können aber auch einen separaten Load-Balancer für die Datenebene einrichten. Weitere Informationen finden Sie unter Manuelles Load-Balancing konfigurieren.

Scrollen Sie bei Bedarf 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 Ihren 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 im folgenden Format verwenden: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    Alternativ können Sie --admin-cluster-membership wie im Beispielbefehl auf den Namen des Administratorclusters festlegen. Wenn Sie nur den Namen des Administratorclusters verwenden, legen Sie die Projekt-ID des Administratorclusters mit --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 suchen, 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

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

  • 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 angeben, erhalten Sie als Clusterersteller standardmäßig Administratorberechtigungen für den Cluster. Wenn Sie jedoch --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, wird die Standardeinstellung überschrieben und es müssen sowohl Ihre E-Mail-Adresse als auch die des anderen Administrators enthalten sein. So fügen Sie beispielsweise zwei Administratoren hinzu: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Wenn der Cluster erstellt wird, wendet die GKE On-Prem API die Richtlinien der rollenbasierten 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. Diese gewährt vollständigen Zugriff auf jede Ressource im Cluster in allen Namespaces.

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 jedem Update oder Upgrade eines Clusters ä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 umfasst Segmente, die mit den Keywords node-ip und labels beginnen. Trennen Sie die einzelnen Segmente durch Kommas.

  • node-ip: Die IP-Adresse eines Knotens der Steuerungsebene. Sie können nur eine node-ip pro Flag angeben. Wenn Sie mehr als einen Knoten angeben müssen, fügen Sie das Flag noch einmal für jeden Knoten hinzu.
  • labels: Ein oder mehrere Schlüssel/Wert-Paare, die an den Knoten angehängt sind.

    Beachten Sie die folgenden Syntaxregeln:

    • Setzen Sie den gesamten Wert in einfache Anführungszeichen.
    • Leerzeichen sind nicht zulässig.
    • Trennen Sie 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 einem Effekt zugeordnet ist. Dabei muss es sich um einen der folgenden Werte handeln: 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 konfiguriert haben.

    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, der für Dienste in Ihrem Cluster verwendet wird. Der CIDR-Bereich muss zwischen /24 und /12 liegen, wobei /12 die meisten IP-Adressen bietet.

    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 wird. Der CIDR-Bereich muss zwischen /18 und /8 liegen, wobei /8 die meisten IP-Adressen bietet.

    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 wird. 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 während der Clustererstellung erstellt werden.

Weitere Informationen zum Speicher finden Sie unter Lokalen Speicher konfigurieren.

Bevor Sie den Befehl gcloud zum Erstellen des Clusters ausführen, sollten Sie --validate-only einbinden, 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 Sie 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 der OPERATION_ID des Vorgangs mit langer Ausführungszeit. Sie können den Status des Vorgangs mit dem folgenden Befehl ermitteln:

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

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 Gruppen von Worker-Knoten, die in diesem Cluster erstellt werden. 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: 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 eines Worker-Knotencomputers. Geben Sie dieses Flag für jeden Knoten an. Der Wert für das Flag hat das folgende 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 umfasst Segmente, die mit den Keywords node-ip und labels beginnen. Trennen Sie die einzelnen Segmente durch Kommas.

    • node-ip: Die IP-Adresse eines Worker-Knotens. Sie können nur eine 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-Paare), 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 eine der folgenden Optionen an: NoSchedule, PreferNoSchedule, NoExecute.

Im folgenden Beispiel wird ein Knotenpool mit dem Namen default-pool in 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 Ihr Administratorcluster unterstützt. 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. Sie können den Befehl gcloud ausführen, um eine Liste der unterstützten Versionen abzurufen, die Sie im 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 1.28 erstellt wurden, werden von den globalen Flotten- und Connect-Diensten verwaltet. In Version 1.28 und höher 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 sollen:

    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: Region der Flottenmitgliedschaft 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 and 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 Fehlerkorrekturen und Verbesserungen zu erhalten.

Beispiel

Sie können das folgende grundlegende Konfigurationsbeispiel verwenden, um einen Nutzercluster mit einem gebündelten 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 Beispielvariablendatei zur Übergabe an main.tf, die zeigt, wie der gebündelte MetalLB-Load-Balancer konfiguriert wird.

  1. Klonen Sie das Repository anthos-samples 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, die an main.tf übergeben wird.

  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. In diesem 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, was 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 dieselbe Version wie der Administratorcluster 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 Ihre E-Mail-Adresse hinzu, wenn Sie den Cluster verwalten möchten.

      Wenn der Cluster erstellt wird, 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 Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren. Diese gewährt vollständigen Zugriff auf jede Ressource im Cluster in allen Namespaces. Dadurch können sich Nutzer auch mit ihrer Google-Identität in der Console 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 jedem Update oder Upgrade eines Clusters ändern.

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

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

    • ingress_vip: Die IP-Adresse, die Sie auf dem 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 Richtlinien für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes konfiguriert, sodass Sie sich mit Ihrer Google Cloud-Identität im Cluster anmelden können. Wenn Sie einen Nutzercluster mit der gcloud CLI erstellen, erhalten Sie standardmäßig diese RBAC-Richtlinien, wenn Sie das Flag --admin-users nicht angeben. Wenn Sie --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, überschreiben Sie die Standardeinstellung und müssen 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 des Clusters haben, können Sie eine direkte Verbindung zum privaten Endpunkt herstellen und direkt eine kubeconfig-Datei generieren. Andernfalls können Sie Connect Gateway verwenden.

Wenn Sie über die Befehlszeile auf den Nutzercluster zugreifen möchten, benötigen Sie die Datei kubeconfig. 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 das kubeconfig des Connect-Gateways, das 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 über diese.

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

Connect-Gateway

  1. initialize Sie entweder die gcloud CLI zur Verwendung mit dem Flotten-Hostprojekt oder führen Sie die folgenden Befehle aus, um sich mit Ihrem Google-Konto anzumelden, Ihr Flottenhostprojekt 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.

Wenn Sie die erforderlichen Anmeldedaten haben, können Sie Befehle mit kubectl wie gewohnt für jeden Kubernetes-Cluster ausführen. Dabei müssen Sie 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. Der TIMESTAMP im Dateinamen gibt an, wann die Datei erstellt wurde (Datum und Uhrzeit).

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