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. Sie 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 verwendet sie die Google Cloud-Region, die Sie beim Erstellen des Clusters angeben. Diese Metadaten ermöglichen der API die Verwaltung des Clusterlebenszyklus und 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 zum Verwalten des Lebenszyklus von Clustern, die mit bmctl erstellt wurden, verwenden möchten, finden Sie unter Nutzercluster konfigurieren, der von der GKE On-Prem API verwaltet werden soll weitere Informationen.

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 Berechtigung roles/gkeonprem.admin erteilt werden.

Wenn Sie auf die Seiten „GKE Enterprise“ und „Google Kubernetes Engine“ in der Console 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 den Cluster mit der gcloud CLI erstellen, müssen Sie die GKE On-Prem API aktivieren. Wenn Sie die Console zum Erstellen des Clusters verwenden, 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:

  • Zugriff auf den Kubernetes API-Server im Nutzercluster haben, nachdem dieser erstellt wurde.

  • Netzwerkverbindung zu allen Knoten im Nutzercluster haben, nachdem dieser erstellt wurde.

  • In einer Flotte registriert sein. Die Projekt-ID, die im Feld gkeConnect.projectID des Administratorclusters konfiguriert ist, der als Flotten-Hostprojekt bezeichnet wird, muss dasselbe Projekt sein, in dem Sie den Nutzercluster erstellen.

Vorbereitung der Clusterknotenmaschinen

Überprü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 die Administratorworkstation auszuführen, installieren Sie die folgenden Befehlszeilentools auf dem Computer, den Sie verwenden möchten.

  • Die neueste Version der gcloud CLI.
  • kubectl zum Ausführen von Befehlen für Kubernetes-Cluster. Falls Sie kubectl installieren müssen, folgen Sie dieser Anleitung.

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 Konsole möglicherweise das einfachste Tool, das verwendet werden kann.

Nachdem Sie sich mit den Informationen vertraut gemacht haben, die Sie zum Erstellen von Clustern benötigen, eignet sich möglicherweise Terraform oder die gcloud CLI besser, insbesondere wenn Sie mehr als einen Cluster erstellen. Terraform ist eine branchenübliche Infrastruktur als Code-Tool. Wenn Ihre Organisation bereits Terraform verwendet, dann möchten Sie es wahrscheinlich zum Erstellen von Clustern und 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 zusätzliche Cluster zu erstellen. Wenn Sie ein CI/CD-Tool wie Cloud Build verwenden, können Sie die gcloud-Befehle zum Erstellen eines Clusters und Knotenpools und zum Angeben des Flags --impersonate-service-account verwenden, um die Erstellung zu automatisieren.

Console

Die meisten Einstellungen in der Konsole entsprechen den Feldern in der Clusterkonfigurationsdatei

  1. Rufen Sie in der Console die Seite GKE auf 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)
    • Connect-Dienst (gkeconnect.googleapis.com)

    Mit dieser Einstellung wird auch die Region gesteuert, 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
    • Die von Cloud-Audit-Logs erstellten Administrator-Audit-Logs

    Der Clustername, das Projekt und der Standort identifizieren 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 Clusterersteller erhalten Sie Administratorberechtigungen für den Cluster. Optional: Geben Sie die E-Mail-Adresse eines anderen Nutzers ein, der den Cluster im Feld Administratornutzer verwalten wird.

    Wenn der Cluster erstellt wird, wendet die GKE On-Prem API die Kubernetes-RBAC-Richtlinien (Role-Based Access Control, rollenbasierte Zugriffssteuerung) 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 Bereich 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. Zulässige Werte liegen zwischen 32 und 250 (einschließlich). 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 Container-Laufzeit für den Cluster.

  7. Klicken Sie auf Weiter, um den Abschnitt Netzwerk aufzurufen.

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 dies auch.

  1. Geben Sie im Abschnitt Steuerungsebene die IPv4-Adresse jedes Knotens der Steuerungsebene ein. Knoten der Steuerungsebene führen die Systemarbeitslast aus. In der Regel handelt es sich dabei entweder um eine einzelne Maschine für eine Mindestbereitstellung oder drei Maschinen für eine Bereitstellung mit Hochverfügbarkeit. Geben Sie eine ungerade Anzahl von Knoten an, um ein Mehrheitsquorum für Hochverfügbarkeit zu erhalten. Dieses Feld kann beim Aktualisieren oder Upgraden 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, der für den Cluster eingerichtet werden soll. 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 demselben 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 in einem dedizierten Pool von Worker-Knoten ausführen müssen. Alle Knoten im Knotenpool des Load-Balancers müssen sich im selben Layer-2-Subnetz befinden wie die virtuellen IP-Adressen (VIPs) des Load-Balancers, die Sie in den 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 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 ausgewählt und Diensten vom Typ LoadBalancer zugewiesen werden kann. Die virtuelle IP-Adresse für eingehenden Traffic, die im Abschnitt Virtuelle IP-Adressen angegeben werden, müssen in einem dieser Pools sein.

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

      2. Geben Sie einen IP-Adressbereich in einer CIDR-Notation (z. B. 192.0.2.0/26) oder einer Bereichsnotation (z. B. 192.0.2.64-192.0.2.72) ein. Verwenden Sie zum Angeben einer einzelnen IP-Adresse in einem Pool /32 in der CIDR-Notation (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 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 automatisch IP-Adressen aus dem Adresspool den Services vom Typ LoadBalancer 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 eigene Load-Balancing-Lösungen für den Traffic auf Steuerungsebene und Datenebene. Sie müssen die VIP der Steuerungsebene auf dem externen Load-Balancer konfigurieren, bevor Sie einen Cluster erstellen. Der Load-Balancer der externen Steuerungsebene kann auch für den Traffic der Datenebene verwendet werden oder Sie richten einen separaten Load Balancer für die Datenebene ein. Weitere Informationen finden Sie unter Manuelles Load-Balancing konfigurieren

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

    • Virtuelle IP-Adresse der Steuerungsebene: Ziel-IP-Adresse, die für den 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 Adresspools des Load-Balancers 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 IP-Adresse aus einem der Load-Balancer-Adresspools ein

  4. Geben Sie im Abschnitt Service- und Pod-CIDRs die Kubernetes-Dienst- und Pod-IP-Adressbereiche 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. Es empfiehlt sich, die privaten IP-Adressbereiche zu verwenden, definiert durch RFC 1918. Die Console bietet die folgenden Standardadressbereiche. Sie können sie jedoch ändern:

    • 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 bietet.

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

  5. Optional können Sie im Abschnitt Erweiterte Attribute Folgendes tun:

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

    • URLs: Eine durch Kommas getrennte Liste mit IP-Adressen, IP-Adressbereichen, Hostnamen und Domainnamen, die nicht durch 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 stellt Block- und Dateispeicherschnittstellen bereit. Standardoptionen sind enthalten, Sie können die Konfigurationen jedoch 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 von bereitgestellten Laufwerken unterstützt werden. Sie müssen diese Laufwerke formatieren und bereitstellen, was vor oder nach der Clustererstellung erfolgen kann.

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

  2. Klicken Sie auf Weiter.

Features

Zur Unterstützung bei Monitoring, Fehlerbehebung und Betrieb Ihres Clusters werden folgenden Funktionen 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 Knotengruppen.

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 den Cluster und fügen dem neu erstellten Cluster dann einen oder mehrere Knotenpools hinzu.

  1. Klicken Sie in der linken Navigationsleiste auf Standardpool.

  2. Geben Sie im Abschnitt Knotenpool-Standardeinstellungen den Knotenpoolnamen ein oder übernehmen Sie "default-pool" als Namen.

  3. Geben Sie im Abschnitt Worker-Knoten die IP-Adressen der Maschinen für den Cluster ein, auf dem sie ausgeführt werden sollen.

  4. Wenn Sie Labels und Markierungen von Kubernetes hinzufügen möchten, gehen Sie im Abschnitt Knotenpool-Metadaten (optional) 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 je nach Bedarf.
    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 je nach Bedarf.

  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 die Einstellungen geprüft und der Cluster in Ihrem Rechenzentrum erstellt wird.

    Wenn bei der Konfiguration ein Fehler auftritt, wird in der Console eine Fehlermeldung angezeigt, die klar genug sein sollte, um das Konfigurationsproblem zu beheben. Versuchen Sie danach noch einmal, den Cluster zu erstellen.

gcloud-CLI

Sie erstellen einen Nutzercluster mit dem folgenden Befehl:

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 den Nutzercluster. Um Ihnen den Einstieg zu erleichtern, können Sie den vollständigen Befehl im Abschnitt Beispiele testen. 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 sieben bis zehn Tage nach dem Release in der GKE On-Prem API verfügbar. Sie können einen gcloud-Befehl ausführen, um eine Liste von unterstützten Versionen zu erhalten, 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, bei dem 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 Flotten- und Connect-Dienste ausgeführt werden. Vor 1.28 erstellte Administratorcluster werden von der globalen Flotte und Connect-Diensten verwaltet. Ab 1.28 können Sie entweder global oder eine Google Cloud-Region angeben, wenn Sie den Administratorcluster erstellen. Sie geben die Region im Flag --admin-cluster-membership-location in den folgenden Beispielbefehelen 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, bei dem der Administratorcluster registriert ist.

    • ADMIN_CLUSTER_REGION: Die Region der Flottenmitgliedschaft für den Administratorcluster. Diese 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 möchten. Dies ist die Region, in der die GKE On-Prem API und die Flotten- 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 Fehlerkorrekturen 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 Load-Balancers ab, den Sie verwenden werden. Weitere Informationen finden Sie in der Übersicht über Load Balancer.

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

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:
    • 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 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. 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 auf den Namen des Administratorclusters setzen, wie im Beispielbefehl. 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 ermitteln möchten, 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. Mit dieser Einstellung wird die Region angegeben, in der Folgendes gespeichert ist:
    • Die Metadaten des Nutzerclusters, die die GKE On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
    • Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
    • Die von Cloud-Audit-Logs erstellten Administrator-Audit-Logs

    Anhand des Clusternamens, des Projekts und des Standorts 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 als Clusterersteller das Flag --admin-users nicht angeben, werden Ihnen standardmäßig Administratorberechtigungen für den Cluster gewährt. Wenn Sie jedoch --admin-users einfügen, um einen anderen Nutzer als Administrator festzulegen, überschreiben Sie den Standard und 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

    Wenn der Cluster erstellt wird, wendet die GKE On-Prem API die Kubernetes-RBAC-Richtlinien (Role-Based Access Control, rollenbasierte Zugriffssteuerung) 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.

MetalLB-Adresspools

  • --metal-lb-address-pools: Geben Sie die Konfiguration für Adresspools ein, 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 einzelnen Segmente durch Kommas.

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

  • avoid-buggy-ips: Wenn Sie diesen Wert auf True setzen, weist der MetalLB-Controller den Diensten keine IP-Adressen zu, die mit .0 oder .255 enden. Dadurch wird verhindert, dass fehlerhafte Endgeräte versehentlich Traffic löschen, der an diese speziellen IP-Adressen gesendet wird. Enthält standardmäßig den Wert False, wenn nichts anderes angegeben ist.

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

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

Beachten Sie die folgenden Syntaxregeln:

  • Schließen Sie den gesamten Wert in einfache Anführungszeichen ein.
  • 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 befinden wie die Load-Balancer-VIPs.

    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 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-Knotenool. Sie können nur eine node-ip pro Flag angeben. Wenn Sie mehr als einen Knoten angeben möchten, fügen Sie das Flag für jeden Knoten noch einmal hinzu.

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

    Beachten Sie die folgenden Syntaxregeln:

    • Schließen Sie den gesamten Wert in einfache Anführungszeichen ein.
    • 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 einfügen:

    • --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, der PreferNoSchedule, NoSchedule oder NoExecute sein muss.

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

    Im folgenden Beispiel werden drei Knoten zum Load-Balancer-Knotenpool 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 Hochverfügbarkeitsbereitstellung verwenden. Geben Sie eine ungerade Anzahl von Knoten an, um ein Mehrheitsquorum für Hochverfügbarkeit zu erhalten. Sie können diese Adressen beim Aktualisieren oder Upgraden 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 einzelnen Segmente durch Kommas.

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

    Beachten Sie die folgenden Syntaxregeln:

    • Schließen Sie den gesamten Wert in einfache Anführungszeichen ein.
    • 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: 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, auf dem der Load-Balancer den Kubernetes API-Server bereitstellt.

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

  • INGRESS_VIP: Die IP-Adresse, die Sie für den 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 werden soll. 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 werden soll. 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 PersistentVolume (PV) erstellt.
  2. --lvp-share-storage-class: Dies ist die Speicherklasse, die zum Erstellen von nichtflüchtigen Volumes verwendet werden soll. Die StorageClass wird während der Clustererstellung erstellt.
  3. --lvp-node-mounts-config-path: Dies ist der Pfad des Hostcomputers, in dem bereitgestellte Laufwerke erkannt werden können. Für jede Bereitstellung wird ein lokales PersistentVolume (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 eigene Load-Balancing-Lösungen für den Traffic auf Steuerungsebene und Datenebene. Sie müssen die VIP der Steuerungsebene auf dem externen Load-Balancer konfigurieren, bevor Sie einen Cluster erstellen. Der Load-Balancer der externen Steuerungsebene kann auch für den Traffic der Datenebene verwendet werden oder Sie richten einen separaten Load Balancer für die Datenebene ein. Weitere Informationen finden Sie unter Manuelles Load-Balancing konfigurieren

Scrollen Sie bei Bedarf weiter, 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:
    • 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 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. 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 auf den Namen des Administratorclusters setzen, wie im Beispielbefehl. 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 ermitteln möchten, 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. Mit dieser Einstellung wird die Region angegeben, in der Folgendes gespeichert ist:
    • Die Metadaten des Nutzerclusters, die die GKE On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
    • Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
    • Die von Cloud-Audit-Logs erstellten Administrator-Audit-Logs

    Anhand des Clusternamens, des Projekts und des Standorts 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 als Clusterersteller das Flag --admin-users nicht angeben, werden Ihnen standardmäßig Administratorberechtigungen für den Cluster gewährt. Wenn Sie jedoch --admin-users einfügen, um einen anderen Nutzer als Administrator festzulegen, überschreiben Sie den Standard und 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

    Wenn der Cluster erstellt wird, wendet die GKE On-Prem API die Kubernetes-RBAC-Richtlinien (Role-Based Access Control, rollenbasierte Zugriffssteuerung) 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.

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 Hochverfügbarkeitsbereitstellung verwenden. Geben Sie eine ungerade Anzahl von Knoten an, um ein Mehrheitsquorum für Hochverfügbarkeit zu erhalten. Sie können diese Adressen beim Aktualisieren oder Upgraden 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 einzelnen Segmente durch Kommas.

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

    Beachten Sie die folgenden Syntaxregeln:

    • Schließen Sie den gesamten Wert in einfache Anführungszeichen ein.
    • 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: 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, auf dem der Load-Balancer den Kubernetes API-Server bereitstellt.

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

  • INGRESS_VIP: Die IP-Adresse, die Sie für den 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 werden soll. 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 werden soll. 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 PersistentVolume (PV) erstellt.
  2. --lvp-share-storage-class: Dies ist die Speicherklasse, die zum Erstellen von nichtflüchtigen Volumes verwendet werden soll. Die StorageClass wird während der Clustererstellung erstellt.
  3. --lvp-node-mounts-config-path: Dies ist der Pfad des Hostcomputers, in dem bereitgestellte Laufwerke erkannt werden können. Für jede Bereitstellung wird ein lokales PersistentVolume (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, können Sie --validate-only einschließen, um die in den Flags für den Befehl gcloud angegebene Konfiguration zu validieren. 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 die 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 aufrufen.

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 den Cluster und fügen dem neu erstellten Cluster 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, bei dem 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 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 festlegen. Fügen Sie dieses Flag für jeden Knoten im Knotenpool noch einmal hinzu.

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

    Beachten Sie die folgenden Syntaxregeln:

    • Schließen Sie den gesamten Wert in einfache Anführungszeichen ein.
    • 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 eine der folgenden Optionen für EFFECT an: NoSchedule, PreferNoSchedule, NoExecute.

Im folgenden Beispiel wird ein Knotenpool namens default-pool für user-cluster- erstellt und dem Knotenpool werden zwei Knoten hinzugefügt. Beide Knoten erhalten das Label node-pool-key=node-pool-value 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 sieben bis zehn Tage nach dem Release in der GKE On-Prem API verfügbar. Sie können einen gcloud-Befehl ausführen, um eine Liste von unterstützten Versionen zu erhalten, 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, bei dem 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 Flotten- und Connect-Dienste ausgeführt werden. Vor 1.28 erstellte Administratorcluster werden von der globalen Flotte und Connect-Diensten verwaltet. Ab 1.28 können Sie entweder global oder eine Google Cloud-Region angeben, wenn Sie den Administratorcluster erstellen. Sie geben die Region im Flag --admin-cluster-membership-location in den folgenden Beispielbefehelen 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, bei dem der Administratorcluster registriert ist.

    • ADMIN_CLUSTER_REGION: Die Region der Flottenmitgliedschaft für den Administratorcluster. Diese 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 möchten. Dies ist die Region, in der die GKE On-Prem API und die Flotten- 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 Fehlerkorrekturen und Verbesserungen zu erhalten.

Beispiel

Mit dem folgenden grundlegenden Konfigurationsbeispiel können Sie einen Nutzercluster mit gebündeltem MetalLB-Load-Balancer erstellen. Weitere Informationen finden Sie in der google_gkeonprem_bare_metal_cluster-Referenzdokumentation.

Variablen in terraform.tfvars festlegen

Das Beispiel enthält eine Beispielvariablendatei, die an main.tf übergeben wird, um zu veranschaulichen, wie Sie den gebündelten MetalLB-Load-Balancer konfigurieren.

  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, 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 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. 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 ausgewählt wird. 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 die Version des Administratorclusters oder eine Version ein, die höchstens eine Nebenversion niedriger als die des Administratorclusters 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 Kubernetes-RBAC-Richtlinien (Role-Based Access Control, rollenbasierte Zugriffssteuerung) auf den Cluster an, um den Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren, die vollständigen Zugriff auf jede Ressource im Cluster in allen Namespaces bietet. So können sich Nutzer auch mit ihrer Google-Identität bei der Console anmelden.

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

      • 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 Hochverfügbarkeitsbereitstellung verwenden. Geben Sie eine ungerade Anzahl von Knoten an, um ein Mehrheitsquorum für Hochverfügbarkeit zu erhalten. Sie können diese Adressen beim Aktualisieren oder Upgraden eines Clusters ändern.

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

    • control_plane_vip: die virtuelle IP-Adresse (VIP), die Sie auf dem Load-Balancer für den Kubernetes API-Server des Nutzerclusters konfigurieren möchten.

    • 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 Adresspools definieren, die vom MetalLB-Load-Balancer verwendet werden sollen. Die Ingress-VIP 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. Prü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 aufrufen.

Verbindung zum Nutzercluster herstellen

Wenn Sie einen Nutzercluster in der Console erstellen, wird der Cluster mit Kubernetes-RBAC-Richtlinien (Role-Based Access Control, rollenbasierte Zugriffssteuerung) konfiguriert, damit 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 angeben. Wenn Sie --admin-users einfügen, 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 hinzufügen. 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 eine kubeconfig-Datei direkt generieren. Andernfalls können Sie das Connect-Gateway verwenden.

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

  • 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, das den Traffic in Ihrem Namen sicher an den privaten Endpunkt weiterleitet.

  • Erstellen Sie für den direkten Zugriff auf private Endpunkte eine kubeconfig-Datei auf Ihrer Administrator-Workstation und verwalten Sie den Cluster über Ihre Administrator-Workstation.

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

Connect-Gateway

  1. Initialisieren 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 Flotten-Hostprojekt als Standard festzulegen und die folgenden 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 des Clusters. In GKE on Bare Metal entspricht der Mitgliedschaftsname dem Clusternamen.

    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 Befehle mit kubectl wie gewohnt für einen Kubernetes-Cluster ausführen und müssen nicht den Namen der kubeconfig-Datei 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.

Eine kubeconfig mit den Anmeldedaten des Nutzerclusters wird in eine Datei geschrieben, bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig Der TIMESTAMP im Dateinamen gibt das Datum und die Uhrzeit der Dateierstellung an.

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