Nutzercluster mit Anthos On-Prem API-Clients erstellen

Auf dieser Seite wird beschrieben, wie Sie mit der Google Cloud Console oder der Google Cloud CLI (gcloud-CLI) einen Nutzercluster erstellen. Beide Standard-Google Cloud-Clients verwenden die Anthos On-Prem API, um den Cluster zu erstellen.

Was ist die Anthos On-Prem-API?

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

Zum Verwalten des Lebenszyklus Ihrer Cluster muss die Anthos On-Prem API Metadaten zum Clusterstatus in Google Cloud speichern. Dabei muss die Google Cloud-Region verwendet werden, die Sie beim Erstellen des Clusters angegeben haben. Mit diesen Metadaten kann die API den Lebenszyklus des Nutzerclusters verwalten und keine arbeitslastspezifischen Daten enthalten.

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 den Lebenszyklus von Clustern, die mit bmctl erstellt wurden, über die Console oder die gcloud CLI verwalten möchten, finden Sie weitere Informationen unter Nutzercluster für die Verwaltung durch die Anthos On-Prem API konfigurieren.

Hinweis

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

IAM-Berechtigungen erteilen

Das Erstellen von Nutzerclustern in der Google Cloud Console wird durch die Identity and Access Management (IAM) gesteuert. Wenn Sie kein Projektinhaber sind, benötigen Sie zusätzlich zu den Rollen, die zum Aufrufen von Clustern und Containerressourcen in der Google Cloud Console erforderlich sind, mindestens die folgende Rolle:

  • roles/gkeonprem.admin. Weitere Informationen zu den in dieser Rolle enthaltenen Berechtigungen finden Sie in der IAM-Dokumentation unter GKE On-Prem-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.

Weitere Informationen zu den Berechtigungen in diesen Rollen finden Sie in der IAM-Dokumentation unter GKE-Hub-Rollen.

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

Voraussetzungen für Administratorcluster

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

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

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

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

Vorbereitung der Clusterknotenmaschinen

Prüfen Sie die Voraussetzungen für Clusterknotenmaschinen, um sicherzustellen, dass die Computer, 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 dieser Anleitung.

Nutzercluster erstellen

Sie können entweder die Google Cloud Console oder die Google Cloud CLI (gcloud-CLI) verwenden, um einen Nutzercluster zu erstellen, der von der Anthos On-Prem API verwaltet wird. Wenn Sie gerade erst anfangen, Anthos-Cluster auf Bare Metal zu installieren, ist die Konsole möglicherweise einfacher zu verwenden als die gcloud CLI.

Nachdem Sie sich mit den Informationen zum Erstellen von Clustern vertraut gemacht haben, ist die gcloud CLI möglicherweise einfacher, da Sie den Befehl mit seinen Argumenten in einer Textdatei speichern können. 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 Anthos-Seite Cluster auf.

    Zur Seite "Anthos-Cluster"

  2. Wählen Sie das 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.

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

gcloud-CLI

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

gcloud alpha container bare-metal clusters create

Nach dem Erstellen des Clusters müssen Sie mindestens einen Knotenpool mit dem folgenden Befehl erstellen:

gcloud alpha container bare-metal node-pools create

Die meisten Flags zum Erstellen des Clusters und des Knotenpools entsprechen den Feldern in der Konfigurationsdatei des Nutzerclusters. Für den Einstieg 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.

Hinweis

  1. Melden Sie sich mit Ihrem Google-Konto an.

    gcloud auth login

  2. Aktualisieren Sie die Komponenten:

    gcloud components update

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. In den Beispielen wird der Cluster ohne Knotenpools erstellt. Nachdem der Cluster ausgeführt wurde, müssen Sie einen Knotenpool hinzufügen, bevor Sie Arbeitslasten bereitstellen.

MetalLB

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

gcloud alpha 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

Manuell

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

gcloud alpha 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

Die folgenden Abschnitte enthalten Informationen zu den Flags zum Erstellen eines Clusters. Die Informationen zu den Flags sind nach Ihren Vorstellungen in den entsprechenden Einstellungen in der Console gruppiert. Eine vollständige Liste der Flags und ihrer Beschreibungen finden Sie in der Referenz zur gcloud CLI. Beispiele für Befehle mit Flag-Werten finden Sie unter Beispiele für die Verwendung der gcloud CLI zum Erstellen eines Nutzerclusters.

Nachdem Sie den Cluster erstellt haben, können Sie mit dem Knotenpoolbefehl einen Knotenpool für den neu erstellten Cluster erstellen.

Clustergrundlagen

Geben Sie grundlegende Informationen zum Cluster ein.

Console

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

    • Die Nutzercluster-Metadaten, 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 eindeutig.

  4. Wählen Sie die Anthos 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.

  1. 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 zwischen 32 und 250. Kubernetes weist jedem Knoten einen CIDR-Block (Classless Inter-Domain Routing) zu, sodass jeder Pod eine eindeutige IP-Adresse haben kann. Die Größe des CIDR-Blocks entspricht der maximalen Anzahl von Pods pro Knoten. Weitere Informationen zum Festlegen der maximalen Anzahl von Pods pro Knoten finden Sie unter Pod-Netzwerke.

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

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

gcloud-CLI

Die grundlegenden Clusterinformationen geben Sie mit den folgenden Flags an:

gcloud alpha 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 \
  --NETWORKING_FLAGS \
  --STORAGE_FLAGS

Dabei gilt:

  • USER_CLUSTER_NAME: Ein Name Ihrer Wahl für Ihren Nutzercluster. Der Name kann nach dem Erstellen des Clusters nicht mehr geändert werden. Der Name muss:
    • darf höchstens 40 Zeichen enthalten.
    • darf nur kleingeschriebene, alphanumerische Zeichen und einen Bindestrich - enthalten.
    • Er muss mit einem Buchstaben beginnen.
    • Er muss mit einem alphanumerischen Zeichen enden.
  • FLEET_HOST_PROJECT_ID: Die ID des Projekts, in dem Sie den Cluster erstellen möchten. Das angegebene Projekt wird auch als Flotten-Hostprojekt verwendet. Dies muss das Projekt sein, für das der Administratorcluster registriert ist. Nachdem der Nutzercluster erstellt wurde, wird er automatisch in 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. Der Name des Administratorclusters ist das letzte Segment des vollständig angegebenen 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. Gib 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 Nutzercluster-Metadaten, 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 eindeutig.

  • VERSION: Die Anthos-Cluster on Bare Metal-Version für Ihren Nutzercluster.
  • YOUR_EMAIL_ADDRESS und ANOTHER_EMAIL_ADDRESS: Wenn Sie das Flag --admin-users nicht als Clusterersteller angeben, erhalten Sie standardmäßig Clusteradministratorberechtigungen. 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 rollenbasierte Zugriffssteuerung von Kubernetes (Role-based Access Control, RBAC) auf den Cluster an, um Ihnen und anderen Administratoren die Kubernetes-Rolle clusterrole/cluster-admin zu gewähren, die uneingeschränkten Zugriff auf alle Ressourcen im Cluster in allen Namespaces bietet.

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

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

Console

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

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

  2. Wählen Sie im Abschnitt Load-Balancer den Load-Balancer aus der Liste Modus aus, um ihn für Ihren Cluster einzurichten. Weitere Informationen finden Sie unter Load-Balancer.

    Gebündelt mit MetalLB

    Konfigurieren Sie das Load-Balancing mit dem gebündelten MetalLB-Load-Balancer. Mit dieser Option werden Anthos-Cluster auf Bare-Metal-Load-Balancern bereitgestellt, die entweder auf einem dedizierten Pool von Worker-Knoten oder auf denselben Knoten wie die Steuerungsebene ausgeführt werden.

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

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

      • Load-Balancer-Knotenpool erstellen: Wählen Sie diese erweiterte Option aus, wenn Sie die Load-Balancer auf einem dedizierten Pool von Worker-Knoten ausführen möchten. 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 Load-Balancer-Knotenpool-IP 1 eine IPv4-Adresse für einen Knoten im Load-Balancer-Knotenpool ein.

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

    2. Fügen Sie im Abschnitt Load-Balancer-Adresspools einen oder mehrere Adresspools für den MetalLB-Controller hinzu und wählen Sie Dienste vom Typ LoadBalancer aus. 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 einen Bereich (z. B. 192.0.2.64-192.0.2.72) ein. Verwenden Sie /32 in der CIDR-Notation (z. B. 192.0.2.1/32), um eine einzelne IP-Adresse in einem Pool anzugeben.

      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 jedem Pool 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

    Mit dem manuellen Load-Balancing konfigurieren Sie Ihre eigenen Load-Balancing-Lösungen für Traffic auf Steuerungsebene und auf Datenebene. Sie müssen die virtuelle IP-Adresse der Steuerungsebene auf dem externen Load-Balancer konfigurieren, bevor Sie einen Cluster erstellen. Der Load-Balancer der externen Steuerungsebene kann auch für Traffic auf 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:

    • VIP der Steuerungsebene: Die 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 für die Load-Balancer-Adresspools verwendeten Adressbereiche befinden.

    • Port: Der Zielport für den Traffic, 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 Adresspools des Load-Balancers ein.

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

    • Dienst-CIDR: 172.26.232.0/16 Wenn Sie die Standardeinstellung nicht akzeptieren, geben Sie einen CIDR-Bereich zwischen /24 und /12 ein, wobei /12 die meisten IP-Adressen bietet.

    • Pod-CIDR: 10.240.0.0/13 Wenn Sie die Standardeinstellung nicht akzeptieren, geben Sie einen CIDR-Bereich zwischen /18 und /8 ein, wobei /8 die meisten IP-Adressen bietet.

  5. Geben Sie im Abschnitt 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 Anthos on Bare Metal-Cluster eine Anfrage an eine dieser Adressen, Hosts oder Domains senden, wird die Anfrage direkt gesendet.

  6. Klicken Sie auf Weiter.

gcloud-CLI

Welche Informationen Sie angeben, hängt vom Typ des verwendeten Load-Balancers ab. Weitere Informationen finden Sie unter Load-Balancer.

MetalLB

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

gcloud alpha container bare-metal clusters create USER_CLUSTER_NAME \
  --CLUSTER_BASICS_FLAGS \
  --metal-lb-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --metal-lb-load-balancer-node-configs='node-ip=LB_IP_ADDRESS_1,labels=LB_KEY_1.1=LB_VALUE_1.1;LB_KEY_1.2=LB_VALUE_1.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 \
  --STORAGE_FLAGS

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 das folgende Format:

    'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

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

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

    • avoid-buggy-ips: Wenn Sie diesen Wert auf True festlegen, weist der MetalLB-Controller Diensten keine IP-Adressen zu, die auf .0 oder .255 enden. So wird vermieden, dass fehlerhafte Geräte, die versehentlich an diese speziellen IP-Adressen gesendet werden, ausfallen. Wenn nicht angegeben, wird standardmäßig False verwendet.

    • manual-assign: Wenn Sie nicht möchten, dass der MetalLB-Controller IP-Adressen aus diesem Pool automatisch Diensten zuweist, legen Sie dafür True fest. Dann 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 gesetzt.

    • In der addresses-Liste: Jede Adresse muss ein Bereich sein, entweder im Format CIDR oder im Bindestrichbereich. Verwenden Sie /32 in CIDR-Notation (z. B. 192.0.2.1/32).

    Beachten Sie die folgenden Syntaxregeln:

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

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

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

MetalLB-Knoten

  • Optional: --metal-lb-load-balancer-node-configs: Standardmäßig wird der Load-Balancer auf denselben Knoten ausgeführt wie die Steuerungsebene. 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 Load-Balancer-Knotenpool müssen sich im selben Layer-2-Subnetz wie die virtuellen IP-Adressen (VIPs) des Load-Balancers befinden.

    Der Wert für das Flag hat das folgende Format:

    'node-ip=LB_IP_ADDRESS_1,labels=LB_KEY_1.1=LB_VALUE_1.1;LB_KEY_1.2=LB_VALUE_1.2;...' \

    Der Wert hat Segmente, die mit den Keywords node-ip und labels beginnen. Trennen Sie die einzelnen Segmente durch Kommas.

    • node-ip: Die IP-Adresse eines Knotens im Knotenpool des Load-Balancers. Sie können nur ein node-ip pro Flag angeben. Wenn Sie mehr als einen Knoten angeben müssen, fügen Sie das Flag 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:

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

    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 Knotenpool des Load-Balancers Labels hinzuzufügen. Trennen Sie die Liste der Schlüssel/Wert-Paare durch ein Komma.

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

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

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

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

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

Manuell

Mit dem manuellen Load-Balancing konfigurieren Sie Ihre eigenen Load-Balancing-Lösungen für Traffic auf Steuerungsebene und auf Datenebene. Sie müssen die virtuelle IP-Adresse der Steuerungsebene auf dem externen Load-Balancer konfigurieren, bevor Sie einen Cluster erstellen. Der Load-Balancer der externen Steuerungsebene kann auch für Traffic auf 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.

gcloud alpha container bare-metal clusters create USER_CLUSTER_NAME \
    --CLUSTER_BASICS_FLAGS \
    --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 \
    --STORAGE_FLAGS

Knoten der Steuerungsebene

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

    Der Wert für das Flag hat das folgende Format:

    'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \

    Der Wert hat Segmente, die mit den Keywords node-ip und labels beginnen. Trennen Sie die einzelnen Segmente durch Kommas.

    • node-ip: Die IP-Adresse eines Knotens auf der Steuerungsebene. Sie können nur ein node-ip pro Flag angeben. Wenn Sie mehr als einen Knoten angeben müssen, fügen Sie das Flag für jeden Knoten noch einmal 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 jedes Schlüssel/Wert-Paar 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. Es muss einer der folgenden Werte sein: PreferNoSchedule, NoSchedule oder NoExecute.

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

    --control-plane-node-configs='node-ip=192.0.2.1' \
--control-plane-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
--control-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
--control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
--control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

Virtuelle IP-Adressen

  • CONTROL_PLANE_VIP: Die virtuelle IP-Adresse (VIP), 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 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=203.0.113.4

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=92.168.0.0/16

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

Speicher

Anthos-Cluster auf Bare Metal stellen Schnittstellen für Block- und Dateispeicher bereit. Sie haben Standardoptionen, die Sie jedoch anpassen können. Weitere Informationen finden Sie unter Lokalen Speicher konfigurieren.

Console

  1. Optional können Sie Folgendes konfigurieren:

    • Bereitstellungen von lokalen Volume-Bereitstellern: 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.

    • Lokaler Volume-Bereitsteller: Gibt die Konfiguration für das lokale PersistentVolumes an, die durch Unterverzeichnissen in einem freigegebenen Dateisystem unterstützt wird. Diese Unterverzeichnisse werden während der Clustererstellung automatisch erstellt.

  2. Klicken Sie auf Weiter.

gcloud-CLI

Anthos-Cluster auf Bare Metal stellen Schnittstellen für Block- und Dateispeicher bereit. Sie müssen diese Flags angeben, um den Speicher zu konfigurieren. Sie können jedoch die folgenden Werte verwenden:

gcloud alpha container bare-metal clusters create USER_CLUSTER_NAME \
  --CLUSTER_BASICS_FLAGS \
  --NETWORKING_FLAGS \
  --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

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

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

  • --lvp-node-mounts-config-path: Dies ist der Pfad zum Hostcomputer, auf dem bereitgestellte Laufwerke erkannt werden können. Für jede Bereitstellung wird ein lokales PersistentVolume (PV) erstellt.

  • --lvp-node-mounts-config-storage: Die Speicherklasse, mit der PVs bei der Clustererstellung erstellt werden.

Weitere Informationen zum Speicher finden Sie unter Lokalen Speicher konfigurieren.

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

Cluster und Knotenpools erstellen

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

In der Console konfigurieren Sie mindestens einen Knotenpool oder akzeptieren die Standardwerte und erstellen dann den Cluster. Sie können zusätzliche Knotenpools hinzufügen, nachdem der Cluster erstellt wurde. Erstellen Sie mit der gcloud CLI zuerst den Cluster und fügen dann dem neu erstellten Cluster einen oder mehrere Knotenpools hinzu.

Console

  1. Geben Sie im Abschnitt Standardeinstellungen für Knotenpools den Knotenpoolnamen ein oder akzeptieren Sie den Standardpool.

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

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

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

  4. Klicken Sie auf Prüfen und abschließen, um den Nutzercluster zu erstellen. Das Erstellen des Nutzerclusters dauert 15 Minuten oder länger. In der Console werden Statusmeldungen angezeigt, während sie die Einstellungen prüfen und den Cluster in Ihrem Rechenzentrum erstellen.

    Wenn bei der Konfiguration ein Problem auftritt, wird in der Console eine Fehlermeldung angezeigt, die klar genug ist, um das Konfigurationsproblem zu beheben und den Cluster noch einmal zu erstellen.

gcloud-CLI 

gcloud alpha 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;...'

Dabei gilt:

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

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

  • USER_CLUSTER_NAME: Der Name des neu erstellten Nutzerclusters.

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

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

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

    'node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...' \

    Der Wert hat 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 ein node-ip pro Flag angeben. 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:

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

    Optional können Sie Folgendes angeben:

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

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

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

gcloud alpha 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.

Verbindung zum Nutzercluster herstellen

Wenn Sie einen Nutzercluster in der Console erstellen, wird der Cluster mit den Richtlinien für die rollenbasierte Zugriffssteuerung (Role-based Access Control, RBAC) von Kubernetes konfiguriert, sodass Sie sich mit Ihrer Google Cloud-Identität im Cluster anmelden können. Wenn Sie einen Nutzercluster mit der gcloud CLI erstellen, erhalten Sie standardmäßig diese RBAC-Richtlinien, wenn Sie das Flag --admin-users nicht einfügen. Wenn Sie --admin-users verwenden, 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 des Clusters haben, können Sie eine direkte Verbindung zum privaten Endpunkt herstellen und eine kubeconfig-Datei direkt 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 die kubeconfig des Connect-Gateways, die den Traffic in Ihrem Namen sicher an den privaten Endpunkt weiterleitet.

  • Für den direkten Zugriff auf private Endpunkte erstellen Sie eine kubeconfig-Datei auf Ihrer Administratorworkstation und verwalten den Cluster über Ihre Administratorworkstation.

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

Connect-Gateway

  1. Initialisieren Sie die gcloud CLI für das Flottenhostprojekt oder führen Sie die folgenden Befehle aus, um sich mit Ihrem Google-Konto anzumelden, Ihr Flottenhostprojekt als Standard festzulegen und die Komponenten zu aktualisieren:

    gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update

  2. Rufen Sie die Clusteranmeldedaten ab, die für die Interaktion mit dem Connect-Gateway verwendet werden. Ersetzen Sie im folgenden Befehl MEMBERSHIP_NAME durch den Namen Ihres Clusters. In Anthos-Clustern auf Bare Metal ist der Mitgliedschaftsname derselbe 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 wie gewohnt für jeden Kubernetes-Cluster ausführen. Sie müssen den Namen der Datei kubeconfig nicht angeben. Beispiel:

kubectl get namespaces

Administratorworkstation

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

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

Dabei gilt:

  • CLUSTER_NAME gibt den Namen des Zielnutzerclusters an.

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

Ein kubeconfig mit den Anmeldedaten des Nutzerclusters wird in die Datei bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig geschrieben. Das TIMESTAMP im Dateinamen gibt das Datum und die Uhrzeit 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