Nutzercluster mit Anthos 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 Anthos On-Prem API?

Die Anthos On-Prem API ist eine von Google Cloud gehostete API, mit der Sie den Lebenszyklus Ihrer lokalen Cluster mithilfe von Terraform und Google Cloud-Standardanwendungen verwalten können. Die Anthos On-Prem API wird in der Infrastruktur von Google Cloud ausgeführt. Terraform, die Console und die gcloud CLI sind Clients der API und verwenden die API zum Erstellen von Clustern in Ihrem Rechenzentrum.

Zum Verwalten des Lebenszyklus Ihrer Cluster muss die Anthos 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 Arbeitslast-spezifischen Daten.

Wenn Sie einen Cluster mit einem Anthos On-Prem API-Client erstellen, geben Sie ein Google Cloud-Projekt an. Nachdem der Cluster erstellt wurde, wird er automatisch in der Flotte des angegebenen Projekts registriert. Dieses Projekt wird als Flotten-Hostprojekt bezeichnet. Das Flottenhostprojekt 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 konfigurieren, die von der Anthos On-Prem API verwaltet werden sollen.

Hinweise

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

IAM-Berechtigungen gewähren

Wenn Sie kein Projektinhaber sind, benötigen Sie die Berechtigung roles/gkeonprem.admin.

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, 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 über die gcloud CLI erstellen, müssen Sie die Anthos On-Prem API aktivieren. Wenn Sie den Cluster über die Console erstellen, wird die Anthos 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.

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

  • Sie müssen für eine Flotte registriert sein. Die Projekt-ID, die im Feld gkeConnect.projectID dieses Administratorclusters konfiguriert ist und als Flotten-Hostprojekt bezeichnet wird, muss mit dem Projekt identisch sein, in dem Sie den Nutzercluster erstellen.

Vorbereitung der Clusterknotenmaschinen

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

Befehlszeilenzugriff

Wenn Sie nach dem Erstellen des Clusters das Connect-Gateway verwenden möchten, um kubectl für den Nutzercluster auf anderen Computern als der Administratorworkstation auszuführen, installieren Sie die folgenden Befehlszeilentools auf dem Computer, den Sie verwenden möchten.

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

Nutzercluster erstellen

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

Wenn Sie mit den Informationen vertraut sind, die Sie zum Erstellen von Clustern bereitstellen müssen, finden Sie Terraform oder die gcloud CLI möglicherweise nützlicher, insbesondere wenn Sie mehr als einen Cluster erstellen möchten. 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 Google Cloud Console die Seite „GKE Enterprise-Cluster“ auf.

    Zur Seite „GKE Enterprise-Cluster“

  2. Wählen Sie das Google Cloud-Projekt aus, in dem Sie den Cluster erstellen möchten. Das ausgewählte Projekt wird auch als Flotten-Hostprojekt verwendet. 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 Cluster erstellen.

  4. Klicken Sie im Dialogfeld auf Lokal.

  5. Klicken Sie neben Bare Metal auf Konfigurieren.

  6. Prüfen Sie die Voraussetzungen und die Beispielarchitektur. Wenn Sie bereit sind, klicken Sie auf Weiter, um mit der Konfiguration des Clusters zu beginnen.

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

Clustergrundlagen

Geben Sie grundlegende Informationen zum Cluster ein.

  1. Geben Sie einen Namen für den Nutzercluster ein.
  2. Wählen Sie unter Administratorcluster den Administratorcluster aus der Liste aus.

  3. Wählen Sie im Feld Google Cloud API-Standort die Google Cloud-Region aus der Liste aus. Diese Einstellung gibt die Region an, in der die Anthos On-Prem API ausgeführt wird, und die Region, in der Folgendes gespeichert ist:

    • Die Nutzerclustermetadaten, die die Anthos On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
    • Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
    • Das von Cloud-Audit-Logs erstellte Administrator-Audit-Log

    Der Clustername, das Projekt und der Standort identifizieren den Cluster in Google Cloud gemeinsam 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 niedrigere Version als der Administratorcluster haben.

  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 Anthos On-Prem API die Richtlinien für die rollenbasierte Zugriffssteuerung von Kubernetes auf den Cluster an, um Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren. Diese Rolle bietet vollständigen Zugriff auf jede Ressource im Cluster in allen Namespaces.

  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. Zulässige Werte liegen im Bereich von 32 bis 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 Ihren Cluster.

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

Netzwerk

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

  1. Geben Sie im Abschnitt Knoten der Steuerungsebene die IPv4-Adressen der einzelnen Knoten der Steuerungsebene ein. Knoten der Steuerungsebene führen die Systemarbeitslast aus. In der Regel ist dies entweder eine einzelne Maschine, wenn eine Mindestbereitstellung verwendet wird, oder drei Maschinen, wenn eine Bereitstellung mit Hochverfügbarkeit verwendet wird. Geben Sie eine ungerade Anzahl von Knoten an, um ein Mehrheitsquorum für Hochverfügbarkeit zu haben. Dieses Feld kann bei jedem Update oder Upgrade 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 aus der Liste Modus den Load-Balancer 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 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 Load-Balancer-Adresspools einen oder mehrere Adresspools hinzu, aus denen der MetalLB-Controller Dienste vom Typ LoadBalancer auswählen und diesen zuweisen kann. Die virtuelle IP-Adresse für eingehenden Traffic, die Sie im Abschnitt Virtuelle IP-Adressen angeben, muss sich in einem dieser Pools befinden.

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

      2. Geben Sie einen IP-Adressbereich in CIDR-Notation (z. B. 192.0.2.0/26) oder in Bereichsnotation (z. B. 192.0.2.64-192.0.2.72) ein. Wenn Sie eine einzelne IP-Adresse in einem Pool angeben möchten, verwenden Sie /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 anderen 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 IP-Adressen aus dem Adresspool automatisch Diensten 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 Dienste vom Typ LoadBalancer manuell anzugeben.
      5. Klicken Sie auf Fehlerhafte IP-Adressen vermeiden, wenn der MetalLB-Controller keine Adressen aus dem Pool verwenden soll, die auf .0 oder .255 enden. Dadurch wird verhindert, dass fehlerhafte Geräte versehentlich Traffic löschen, der an diese speziellen IP-Adressen gesendet wird.

      6. Klicken Sie zum Schluss auf Fertig.

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

    Manueller Load-Balancer

    Beim manuellen Load-Balancing konfigurieren Sie Ihre eigenen Load-Balancing-Lösungen für 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 auf 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 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 Adresse aus einem der Load-Balancer-Adresspools ein.

  4. Geben Sie im Abschnitt Dienst- und Pod-CIDRs die IP-Adressbereiche für Kubernetes-Dienste und 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 Verwendung der privaten IP-Adressbereiche, die durch RFC 1918 definiert sind. Die Console bietet die folgenden Standardadressbereiche, die Sie jedoch ändern können:

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

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

  5. Geben Sie im Abschnitt zu den Attributen unter Erweiterte Attribute optional Folgendes an:

    • 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 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 Next (Weiter).

Speicher

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

  1. Optional können Sie Folgendes konfigurieren:

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

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

  2. Klicken Sie auf Next (Weiter).

Features

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

Knotenpool erstellen

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

In der Console konfigurieren Sie mindestens einen Knotenpool (oder übernehmen die Standardwerte) und erstellen dann den Cluster. Sie können weitere Knotenpools hinzufügen, nachdem der Cluster erstellt wurde. Mit der gcloud CLI erstellen Sie zuerst den Cluster und fügen dem neu erstellten Cluster 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. Gehen Sie im Bereich Knotenpoolmetadaten (optional) so vor, wenn Sie Labels und Markierungen von Kubernetes hinzufügen möchten:

    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 verständlich ist, 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 Anthos On-Prem API verfügbar. Sie können einen gcloud-Befehl ausführen, um eine Liste der unterstützten Versionen abzurufen, die Sie auf dem Nutzercluster installieren können.

  1. Aktualisieren Sie die Komponenten:

    gcloud components update
    
  2. 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=global \
      --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.

    • REGION: Die Google Cloud-Region, die Sie bei der Registrierung des Clusters in der Anthos On-Prem API angegeben haben.

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. Welche Informationen Sie angeben, hängt vom Typ des zu verwendenden Load-Balancers ab. 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 vor dem Bereitstellen von Arbeitslasten einen Knotenpool hinzufügen.

MetalLB

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

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --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 Flottenhostprojekt 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 Flottenhostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.
  • ADMIN_CLUSTER_NAME: Der Name des Administratorclusters, der den Nutzercluster verwaltet. Der Name des Administratorclusters ist das letzte Segment des vollständigen Clusternamens, der den Cluster in Google Cloud eindeutig identifiziert: projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME
  • REGION: Die Google Cloud-Region, in der die Anthos On-Prem API ausgeführt wird. Geben Sie us-west1 oder eine andere unterstützte Region an. Die Region kann nach dem Erstellen des Clusters nicht mehr geändert werden. Diese Einstellung gibt die Region an, in der Folgendes gespeichert wird:
    • Die Nutzerclustermetadaten, die die Anthos On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
    • Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
    • Das von Cloud-Audit-Logs erstellte Administrator-Audit-Log

    Der Clustername, das Projekt und der Standort 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 als Clusterersteller nicht das Flag --admin-users angegeben haben, werden Ihnen standardmäßig Administratorberechtigungen für den Cluster gewährt. Wenn Sie jedoch --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, wird die Standardeinstellung überschrieben und Sie müssen sowohl Ihre E-Mail-Adresse als auch die E-Mail-Adresse des anderen Administrators angeben. So fügen Sie beispielsweise zwei Administratoren hinzu:
        --admin-users=sara@example.com \
        --admin-users=amal@example.com

    Wenn der Cluster erstellt wird, wendet die Anthos On-Prem API die Richtlinien für die rollenbasierte Zugriffssteuerung von Kubernetes auf den Cluster an, um Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren. Diese Rolle bietet 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;...' \

Die Segmente des Werts beginnen mit den Keywords pool, avoid-buggy-ip, manual-assign und addresses. 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 Traffic abbrechen, der an diese speziellen IP-Adressen gesendet wird. Wenn keine Angabe erfolgt, wird standardmäßig False verwendet.

  • manual-assign: Wenn Sie nicht möchten, dass der MetalLB-Controller IP-Adressen aus diesem Pool Diensten automatisch zuweist, 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 nicht angegeben, wird manual-assign auf False festgelegt.

  • 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 mehrere Instanzen 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: Der Load-Balancer wird standardmäßig 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 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;...' \
    

    Die Segmente des Werts beginnen mit den Keywords node-ip und labels. Trennen Sie die einzelnen Segmente durch Kommas.

    • node-ip: Die IP-Adresse eines Knotens im Knotenpool des Load-Balancers. 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 ein.

    • 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 Segment labels 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 ändern, wenn Sie einen Cluster aktualisieren oder upgraden.

    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;...' \

    Die Segmente des Werts beginnen mit den Keywords node-ip und labels. 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 für jeden Knoten wieder 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 Segment labels 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, der einer der folgenden sein muss: 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 IP-Adressbereich 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 IP-Adressbereich 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: 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 StorageClass, die zum Erstellen nichtflüchtiger Volumes verwendet werden soll. Die StorageClass wird während der Clustererstellung erstellt.
  3. --lvp-node-mounts-config-path: Pfad zum Hostcomputer, in dem bereitgestellte Laufwerke erkannt werden. 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 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 auf 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 gegebenenfalls nach unten, um den Platzhalter ADMIN_CLUSTER_NAME für das Flag --admin-cluster-membership auszufüllen.

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --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 Flottenhostprojekt 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 Flottenhostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.
  • ADMIN_CLUSTER_NAME: Der Name des Administratorclusters, der den Nutzercluster verwaltet. Der Name des Administratorclusters ist das letzte Segment des vollständigen Clusternamens, der den Cluster in Google Cloud eindeutig identifiziert: projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME
  • REGION: Die Google Cloud-Region, in der die Anthos On-Prem API ausgeführt wird. Geben Sie us-west1 oder eine andere unterstützte Region an. Die Region kann nach dem Erstellen des Clusters nicht mehr geändert werden. Diese Einstellung gibt die Region an, in der Folgendes gespeichert wird:
    • Die Nutzerclustermetadaten, die die Anthos On-Prem API zum Verwalten des Clusterlebenszyklus benötigt
    • Cloud Logging- und Cloud Monitoring-Daten von Systemkomponenten
    • Das von Cloud-Audit-Logs erstellte Administrator-Audit-Log

    Der Clustername, das Projekt und der Standort 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 als Clusterersteller nicht das Flag --admin-users angegeben haben, werden Ihnen standardmäßig Administratorberechtigungen für den Cluster gewährt. Wenn Sie jedoch --admin-users angeben, um einen anderen Nutzer als Administrator festzulegen, wird die Standardeinstellung überschrieben und Sie müssen sowohl Ihre E-Mail-Adresse als auch die E-Mail-Adresse des anderen Administrators angeben. So fügen Sie beispielsweise zwei Administratoren hinzu:
        --admin-users=sara@example.com \
        --admin-users=amal@example.com

    Wenn der Cluster erstellt wird, wendet die Anthos On-Prem API die Richtlinien für die rollenbasierte Zugriffssteuerung von Kubernetes auf den Cluster an, um Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren. Diese Rolle bietet 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 ändern, wenn Sie einen Cluster aktualisieren oder upgraden.

    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;...' \

    Die Segmente des Werts beginnen mit den Keywords node-ip und labels. 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 für jeden Knoten wieder 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 Segment labels 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, der einer der folgenden sein muss: 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 IP-Adressbereich 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 IP-Adressbereich 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: 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 StorageClass, die zum Erstellen nichtflüchtiger Volumes verwendet werden soll. Die StorageClass wird während der Clustererstellung erstellt.
  3. --lvp-node-mounts-config-path: Pfad zum Hostcomputer, in dem bereitgestellte Laufwerke erkannt werden. 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, sollten Sie --validate-only einbeziehen, um die Konfiguration zu validieren, die Sie in den Flags für den Befehl gcloud angegeben haben. Wenn Sie bereit sind, den Cluster zu erstellen, entfernen Sie dieses Flag und führen den Befehl aus.

Das Erstellen des Nutzerclusters dauert mindestens 15 Minuten. Sie können sich den Cluster in der Google Cloud Console auf der Seite Anthos-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 können. 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 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: Name des neu erstellten Nutzerclusters.

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

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

  • --node-configs: Die IPv4-Adresse einer Maschine mit Worker-Knoten. 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;...' \
    

    Die Segmente des Werts beginnen mit den Keywords node-ip und labels. 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 die einzelnen Schlüssel/Wert-Paare im Segment labels 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 mit einem Effekt verknüpft 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 namens default-pool in user-cluster- erstellt und dem Knotenpool werden 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 Anthos On-Prem API verfügbar. Sie können einen gcloud-Befehl ausführen, um eine Liste der unterstützten Versionen abzurufen, die Sie auf dem Nutzercluster installieren können.

  1. Aktualisieren Sie die Komponenten:

    gcloud components update
    
  2. 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=global \
      --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.

    • REGION: Die Google Cloud-Region, die Sie bei der Registrierung des Clusters in der Anthos On-Prem API angegeben haben.

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.

  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 Beispieldatei mit Variablen, die an main.tf übergeben werden soll.

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

    cp terraform.tfvars.sample terraform.tfvars
    
    
    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"] }
    ]
    
  3. Ändern Sie die Parameterwerte in terraform.tfvars und speichern Sie die Datei.

    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 Flottenhostprojekt 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 Flottenhostprojekt kann nach dem Erstellen des Clusters nicht mehr geändert werden.

    • region: Die Google Cloud-Region, in der die Anthos On-Prem API ausgeführt wird. Geben Sie us-west1 oder eine andere unterstützte Region an.

    • admin_cluster_name: Der Name des Administratorclusters, der den Nutzercluster verwaltet.

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

    • 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 ändern, wenn Sie einen Cluster aktualisieren oder upgraden.

    • 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 Adresspools definieren, die vom MetalLB-Load-Balancer verwendet werden sollen. Die virtuelle IP-Adresse für eingehenden Traffic muss sich in einem dieser Pools befinden.

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

    Wenn der Cluster erstellt wird, wendet die Anthos On-Prem API die Richtlinien für die rollenbasierte Zugriffssteuerung von Kubernetes auf den Cluster an, um den Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren. Diese Rolle bietet 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.

  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 sich den Cluster in der Google Cloud Console auf der Seite Anthos-Cluster ansehen.

Verbindung zum Nutzercluster herstellen

Wenn Sie einen Nutzercluster in der Console erstellen, wird der Cluster mit den Kubernetes-Richtlinien für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) konfiguriert, sodass Sie sich mit Ihrer Google Cloud Identity im Cluster anmelden können. Wenn Sie einen Nutzercluster mit der gcloud CLI erstellen, werden Ihnen diese RBAC-Richtlinien standardmäßig gewährt, wenn Sie das Flag --admin-users nicht angeben. Wenn Sie --admin-users einbeziehen, um einen anderen Nutzer als Administrator festzulegen, wird die Standardeinstellung überschrieben und Sie 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 Ihres 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.

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

  • Verwenden Sie das Connect-Gateway, um von einem Computer mit installierter Google Cloud CLI aus auf den Cluster zuzugreifen. In diesem Fall verwendet kubectl den kubeconfig des Connect-Gateways, der 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 Administratorworkstation und verwalten Sie den Cluster über Ihre Administratorworkstation.

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 Flotten-Hostprojekt als Standard festzulegen und die Komponenten zu aktualisieren:

    gcloud auth login
    gcloud config set project PROJECT_ID
    gcloud components update
    
  2. Rufen Sie die Clusteranmeldedaten ab, die für die Interaktion mit dem Connect-Gateway verwendet werden. Ersetzen Sie im folgenden Befehl MEMBERSHIP_NAME durch den Namen Ihres Clusters. In GKE on Bare Metal ist der Name der Mitgliedschaft der gleiche wie der Clustername.

    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 ausführen, wie Sie es normalerweise für jeden Kubernetes-Cluster tun würden, ohne den Namen der Datei kubeconfig anzugeben. Beispiel:

kubectl get namespaces

Administratorworkstation

Rufen Sie mit dem Befehl bmctl get credentials eine kubeconfig-Datei für den neu erstellten Nutzercluster ab.

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