Nutzercluster erstellen (Controlplane V2)

In diesem Dokument wird gezeigt, wie Sie einen Nutzercluster mit aktivierter Controlplane V2 erstellen.

Mit Controlplane V2 wird die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten im Nutzercluster selbst ausgeführt. Controlplane V2 ist die empfohlene Standardeinstellung für die Clustererstellung.

Verfahrensübersicht

Dies sind die wichtigsten Schritte zum Erstellen eines Nutzerclusters:

  1. Verbindung zu Ihrer Administrator-Workstation herstellen
    Die Administrator-Workstation ist eine VM mit den erforderlichen Tools zum Erstellen eines Nutzerclusters.
  2. Ihre Konfigurationsdateien ausfüllen
    Geben Sie die Details für den neuen Cluster an. Füllen Sie dazu eine Nutzercluster-Konfigurationsdatei, eine Konfigurationsdatei für Anmeldedaten und möglicherweise eine IP-Blockdatei aus.
  3. (Optional) Importieren Sie Betriebssystem-Images in vSphere und übertragen Sie Container-Images per Push in den
    private Registry, falls zutreffend.
    Führen Sie gkectl prepare aus.
  4. Nutzercluster erstellen
    Führen Sie gkectl create cluster aus, um einen Cluster zu erstellen, wie in der Konfigurationsdatei angegeben.
  5. Prüfen Sie, ob Ihr Nutzercluster ausgeführt wird
    Rufen Sie mit kubectl die Clusterknoten auf.

Am Ende dieses Verfahrens haben Sie einen laufenden Nutzercluster, in dem Sie Ihre Arbeitslasten bereitstellen können.

Hinweise

  • Prüfen Sie, ob eine Administrator-Workstation und ein Administratorcluster erstellt wurden.

  • Lesen Sie das Dokument zur Planung der IP-Adressen. Achten Sie darauf, dass genügend IP-Adressen verfügbar sind, und prüfen Sie noch einmal, wie die Clusterknoten ihre IP-Adressen bestimmen sollen: über DHCP oder statisch. Wenn Sie statische IP-Adressen verwenden möchten, müssen Sie eine IP-Blockdatei ausfüllen, die die von Ihnen ausgewählten Adressen enthält.

  • Lesen Sie die Load-Balancing-Übersicht und überprüfen Sie noch einmal, welche Art von Load-Balancer Sie verwenden möchten. Sie können den gebündelten MetalLB-Load-Balancer verwenden oder manuell einen Load-Balancer Ihrer Wahl konfigurieren. Für das manuelle Load-Balancing müssen Sie den Load-Balancer einrichten, bevor Sie Ihren Nutzercluster erstellen.

  • Sehen Sie sich den Abschnitt vCenter an. Überlegen Sie, ob Sie separate vSphere-Cluster für Ihren Administratorcluster und Ihre Nutzercluster und auch separate Rechenzentren verwenden möchten. Überlegen Sie sich auch, ob Sie separate Instanzen von vCenter Server verwenden möchten.

  • Sehen Sie sich den Abschnitt nodePools an. Überlegen Sie sich, wie viele Knotenpools Sie benötigen und welches Betriebssystem Sie in jedem Ihrer Pools ausführen möchten.

1. Verbindung zu Ihrer Administrator-Workstation herstellen

SSH-Verbindung zu Ihrer Administrator-Workstation abrufen.

Denken Sie daran, dass gkeadm Ihr Dienstkonto für den Komponentenzugriff auf der Administrator-Workstation aktiviert hat.

Führen Sie alle verbleibenden Schritte in diesem Thema auf Ihrer Administrator-Workstation im Basisverzeichnis aus.

2. Konfigurationsdatei ausfüllen

Als gkeadm die Administrator-Workstation erstellt hat, wurde eine zweite Konfigurationsdatei mit dem Namen user-cluster.yaml erzeugt. Diese Konfigurationsdatei dient zum Erstellen Ihres Nutzerclusters.

Machen Sie sich mit der Konfigurationsdatei vertraut, indem Sie sich das Dokument zur Nutzercluster-Konfigurationsdatei ansehen. Möglicherweise möchten Sie dieses Dokument in einem separaten Tab oder Fenster geöffnet lassen, da Sie sich beim Ausführen der folgenden Schritte darauf beziehen.

name

Geben Sie für das Feld name einen Namen Ihrer Wahl für den Nutzercluster an.

gkeOnPremVersion

Dieses Feld ist bereits für Sie ausgefüllt. Damit wird die Version von GKE on VMware angegeben. Beispiel: 1.15.0-gke.581

enableControlplaneV2

Legen Sie enableControlplaneV2 auf true fest.

enableDataplaneV2

Legen Sie enableDataplaneV2 auf true fest.

vCenter

Die im Abschnitt vCenter Ihrer Administratorcluster-Konfigurationsdatei festgelegten Werte sind global. Das heißt, sie gelten für Ihren Administratorcluster und die zugehörigen Nutzercluster.

Für jeden von Ihnen erstellten Nutzercluster haben Sie die Möglichkeit, einige der globalen vCenter-Werte zu überschreiben.

Wenn Sie einen oder mehrere der globalen vCenter-Werte überschreiben möchten, füllen Sie die relevanten Felder im Abschnitt vCenter der Konfigurationsdatei des Nutzerclusters aus.

Insbesondere möchten Sie separate vSphere-Cluster für Ihren Administratorcluster und Ihre Nutzercluster sowie separate Rechenzentren für Ihren Administratorcluster und Ihre Nutzercluster verwenden.

Ein Rechenzentrum und einen vSphere-Cluster verwenden

Die Standardoption besteht darin, ein Rechenzentrum und einen vSphere-Cluster für den Administratorcluster und den Nutzercluster zu verwenden. Legen Sie für diese Option in der Konfigurationsdatei des Nutzerclusters keine vCenter-Werte fest. Die vCenter-Werte werden vom Administratorcluster übernommen.

Separate vSphere-Cluster verwenden

Wenn Sie einen Nutzercluster erstellen möchten, der sich in seinem eigenen vSphere-Cluster befindet, geben Sie in der Konfigurationsdatei des Nutzerclusters einen Wert für vCenter.cluster an.

Wenn sich Ihr Administratorcluster und Ihr Nutzercluster in separaten vSphere-Clustern befinden, können sie sich im selben Rechenzentrum oder in verschiedenen Rechenzentren befinden.

Separate vSphere-Rechenzentren verwenden

Der Nutzer- und der Administratorcluster können sich in verschiedenen Rechenzentren befinden. In diesem Fall befinden sie sich auch in separaten vSphere-Clustern.

Wenn Sie vCenter.datacenter in der Konfigurationsdatei des Nutzerclusters angeben, müssen Sie auch Folgendes angeben:

  • vCenter.networkName
  • vCenter.datastore oder vCenter.storagePolicyName.
  • vCenter.cluster oder vCenter.resourcePool.

Separate vCenter-Konten verwenden

Ein Nutzercluster kann ein anderes vCenter-Konto mit anderen vCenter.credentials als der Administratorcluster verwenden. Das vCenter-Konto für den Administratorcluster benötigt Zugriff auf das Rechenzentrum des Administratorclusters, während das vCenter-Konto für den Nutzercluster nur Zugriff auf das Rechenzentrum des Nutzerclusters benötigt.

Separate Instanzen von vCenter Server verwenden

In bestimmten Situationen ist es sinnvoll, einen Nutzercluster zu erstellen, der eine eigene Instanz von vCenter Server verwendet. Das heißt, der Administratorcluster und ein zugehöriger Nutzercluster verwenden unterschiedliche Instanzen von vCenter Server.

An einem Edge-Standort möchten Sie vielleicht eine physische Maschine, auf der vCenter Server ausgeführt wird, und eine oder mehrere physische Maschinen, auf denen ESXi ausgeführt wird. Sie können dann Ihre lokale Instanz von vCenter Server verwenden, um eine vSphere-Objekthierarchie zu erstellen, die Rechenzentren, Cluster, Ressourcenpools, Datenspeicher und Ordner umfasst.

Füllen Sie den gesamten vCenter-Abschnitt der Konfigurationsdatei des Nutzerclusters aus. Geben Sie insbesondere einen Wert für vCenter.address an, der sich von der vCenter Server-Adresse unterscheidet, die Sie in der Konfigurationsdatei des Administratorclusters angegeben haben. Beispiel:

vCenter:
  address: "vc-edge.example"
  datacenter: "vc-edge"
  cluster: "vc-edge-workloads"
  resourcePool: "vc-edge-pool
  datastore: "vc-edge-datastore
  caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter-edge"
  folder: "edge-vm-folder"

Füllen Sie außerdem das Feld network.vCenter.networkName aus.

network

Legen Sie fest, wie die Worker-Knoten ihre IP-Adressen erhalten sollen. Folgende Optionen sind verfügbar:

  • Von einem DHCP-Server, den Sie im Voraus eingerichtet haben. Legen Sie network.ipMode.type auf "dhcp" fest.

  • Aus einer Liste der von Ihnen angegebenen statischen IP-Adressen. Legen Sie network.ipMode.type auf "static" fest und erstellen Sie eine IP-Blockdatei, die die statischen IP-Adressen bereitstellt. Ein Beispiel für eine IP-Blockdatei finden Sie unter Beispiel für ausgefüllte Konfigurationsdateien.

Wenn Sie statische IP-Adressen für Ihre Worker-Knoten verwenden möchten, füllen Sie das Feld network.ipMode.ipBlockFilePath aus.

Die IP-Adressen der Knoten der Steuerungsebene für Ihren Nutzercluster müssen aus einer Liste statischer Adressen abgerufen werden, die Sie bereitstellen. Dies ist auch dann der Fall, wenn Ihre Worker-Knoten ihre Adressen von einem DHCP-Server erhalten. Füllen Sie den Abschnitt network.controlPlaneIPBlock aus, um statische IP-Adressen für die Knoten der Steuerungsebene anzugeben. Wenn Sie einen Hochverfügbarkeits-Nutzercluster wünschen, geben Sie drei IP-Adressen an. Geben Sie andernfalls eine IP-Adresse an.

Geben Sie die DNS- und NTP-Server an, indem Sie den Abschnitt hostConfig ausfüllen. Diese DNS- und NTP-Server sind für die Knoten der Steuerungsebene vorgesehen. Wenn Sie für Ihre Worker-Knoten statische IP-Adressen verwenden, gelten diese DNS- und NTP-Server auch für die Worker-Knoten.

network.podCIDR und network.serviceCIDR haben bereits ausgefüllte Werte, die Sie unverändert lassen können, sofern sie nicht mit Adressen in Konflikt stehen, die bereits in Ihrem Netzwerk verwendet werden. Kubernetes verwendet diese Bereiche, um den Pods und Services in Ihrem Cluster IP-Adressen zuzuweisen.

Unabhängig davon, ob Sie einen DHCP-Server verwenden oder eine Liste statischer IP-Adressen angeben, müssen Sie für Ihren Nutzercluster genügend IP-Adressen haben. Informationen zur Anzahl der erforderlichen IP-Adressen finden Sie unter IP-Adressen planen.

loadBalancer

Legen Sie eine VIP für den Kubernetes API-Server Ihres Nutzerclusters fest. Legen Sie eine andere VIP für den Ingress-Dienst Ihres Nutzerclusters fest. Geben Sie Ihre VIPs als Werte für loadBalancer.vips.controlPlaneVIP und loadBalancer.vips.ingressVIP an.

Entscheiden Sie, welche Art von Load-Balancing Sie verwenden möchten. Folgende Optionen sind verfügbar:

Weitere Informationen zu den Load-Balancing-Optionen finden Sie unter Load-Balancing – Übersicht.

advancedNetworking

Wenn Sie ein NAT-Gateway für ausgehenden Traffic erstellen möchten, legen Sie für advancedNetworking den Wert true fest.

multipleNetworkInterfaces

Entscheiden Sie, ob Sie mehrere Netzwerkschnittstellen für Pods konfigurieren möchten, und legen Sie multipleNetworkInterfaces entsprechend fest.

storage

Wenn Sie die Bereitstellung von vSphere-CSI-Komponenten deaktivieren möchten, setzen Sie storage.vSphereCSIDisabled auf true.

masterNode

Im Abschnitt masterNode können Sie angeben, wie viele Knoten der Steuerungsebene Sie für Ihren Nutzercluster haben möchten: ein oder drei Knoten. Sie können auch einen Datenspeicher für die Knoten der Steuerungsebene angeben und angeben, ob Sie die automatische Größenanpassung für die Knoten der Steuerungsebene aktivieren möchten.

Denken Sie daran, dass Sie im Abschnitt network.controlPlaneIPBlock IP-Adressen für die Knoten der Steuerungsebene angegeben haben.

nodePools

Ein Knotenpool besteht aus einer Gruppe von Knoten in einem Cluster, die alle dieselbe Konfiguration haben. Beispielsweise kann auf den Knoten in einem Pool Windows und auf den Knoten in einem anderen Pool Linux ausgeführt werden.

Sie müssen mindestens einen Knotenpool angeben, indem Sie den Abschnitt nodePools ausfüllen.

Weitere Informationen finden Sie unter Knotenpools und Knotenpools erstellen und verwalten.

antiAffinityGroups

Legen Sie antiAffinityGroups.enabled auf true oder false fest.

Dieses Feld gibt an, ob GKE on VMware DRS-Anti-Affinitätsregeln (Distributed Resource Scheduler) für Ihre Worker-Knoten erstellt, wodurch sie auf mindestens drei physische Hosts in Ihrem Rechenzentrum verteilt werden.

stackdriver

Wenn Sie Cloud Logging und Cloud Monitoring für Ihren Cluster aktivieren möchten, füllen Sie den Abschnitt stackdriver aus.

Dieser Bereich ist standardmäßig erforderlich. Wenn Sie diesen Abschnitt nicht ausfüllen, müssen Sie das Flag --skip-validation-stackdriver angeben, wenn Sie gkectl create cluster ausführen.

Beachten Sie die folgenden Anforderungen für neue Cluster:

  • Die ID in stackdriver.projectID muss mit der ID in gkeConnect.projectID und cloudAuditLogging.projectID übereinstimmen.

  • Die in stackdriver.clusterLocation festgelegte Google Cloud-Region muss mit der in cloudAuditLogging.clusterLocation festgelegten Region übereinstimmen. Wenn gkeOnPremAPI.enabled den Wert true hat, muss dieselbe Region außerdem in gkeOnPremAPI.location festgelegt werden.

Wenn die Projekt-IDs und Regionen nicht identisch sind, schlägt die Clustererstellung fehl.

gkeConnect

Ihr Nutzercluster muss bei einer Google Cloud-Flotte registriert sein.

Füllen Sie den Abschnitt gkeConnect aus, um ein Flotten-Hostprojekt und ein zugehöriges Dienstkonto anzugeben.

Wenn Sie die Abschnitte stackdriver und cloudAuditLogging in die Konfigurationsdatei aufnehmen, muss die ID in gkeConnect.projectID mit der in stackdriver.projectID und cloudAuditLogging.projectID festgelegten ID übereinstimmen. Wenn die Projekt-IDs nicht identisch sind, schlägt die Clustererstellung fehl.

gkeOnPremAPI

Wenn in Version 1.16 und höher die GKE On-Prem API in Ihrem Google Cloud-Projekt aktiviert ist, werden alle Cluster im Projekt automatisch in der in stackdriver.clusterLocation konfigurierten Region in der GKE On-Prem API registriert.

  • Wenn Sie alle Cluster im Projekt in der GKE On-Prem API registrieren möchten, führen Sie die Schritte unter Vorbereitung aus, um die GKE On-Prem API im Projekt zu aktivieren und zu verwenden.

  • Wenn Sie den Cluster nicht in der GKE On-Prem API registrieren möchten, fügen Sie diesen Abschnitt ein und legen Sie gkeOnPremAPI.enabled auf false fest. Wenn Sie im Projekt keine Cluster registrieren möchten, deaktivieren Sie gkeonprem.googleapis.com (den Dienstnamen für die GKE On-Prem API) im Projekt. Eine Anleitung dazu finden Sie unter Dienste deaktivieren.

usageMetering

Wenn Sie die Nutzungsmessung für Ihren Cluster aktivieren möchten, füllen Sie den Abschnitt usageMetering aus.

cloudAuditLogging

Wenn Sie die Audit-Logs vom Kubernetes API-Server des Clusters in Cloud-Audit-Logs einbinden möchten, füllen Sie den Abschnitt cloudAuditLogging aus.

Beachten Sie die folgenden Anforderungen für neue Cluster:

  • Die ID in cloudAuditLogging.projectID muss mit der ID in gkeConnect.projectID und stackdriver.projectID übereinstimmen.

  • Die in cloudAuditLogging.clusterLocation festgelegte Google Cloud-Region muss mit der in stackdriver.clusterLocation festgelegten Region übereinstimmen. Wenn gkeOnPremAPI.enabled den Wert true hat, muss dieselbe Region außerdem in gkeOnPremAPI.location festgelegt werden.

Wenn die Projekt-IDs und Regionen nicht identisch sind, schlägt die Clustererstellung fehl.

Beispiel für ausgefüllte Konfigurationsdateien

Hier sehen Sie ein Beispiel für eine IP-Blockdatei und eine Nutzercluster-Konfigurationsdatei:

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4

user-cluster.yaml

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.15.0-gke.581
enableControlplaneV2: true
enableDataplaneV2: true
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.21.30-172.16.21.39"
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  enableLoadBalancer: true
antiAffinityGroups:
  enabled: true
gkeConnect:
  projectID: "my-project-123"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true

Dies sind die wichtigen Punkte aus dem vorherigen Beispiel:

  • Die statischen IP-Adressen für die Worker-Knoten werden in einer IP-Blockdatei angegeben. Die IP-Blockdatei hat vier Adressen, obwohl nur drei Worker-Knoten vorhanden sind. Die zusätzliche IP-Adresse wird während des Clusterupgrades, der Aktualisierung und der automatischen Reparatur benötigt.

  • DNS- und NTP-Server werden im Abschnitt hostConfig angegeben. In diesem Beispiel sind diese DNS- und NTP-Server für die Knoten der Steuerungsebene und die Worker-Knoten vorgesehen. Das liegt daran, dass die Worker-Knoten statische IP-Adressen haben. Würden die Worker-Knoten ihre IP-Adressen von einem DHCP-Server beziehen, wären diese DNS- und NTP-Server nur für die Knoten der Steuerungsebene vorgesehen.

  • Die statischen IP-Adressen für die drei Knoten der Steuerungsebene werden im Abschnitt network.controlPlaneIPBlock der Konfigurationsdatei des Nutzerclusters angegeben. Es ist keine zusätzliche IP-Adresse in diesem Block erforderlich.

  • Das Feld masterNode.replicas ist auf 3 gesetzt.

  • Die virtuelle IP-Adresse der Steuerungsebene und die virtuelle IP-Adresse für eingehenden Traffic befinden sich beide im selben VLAN wie die Worker-Knoten und die Knoten der Steuerungsebene.

  • Die VIPs, die für Dienste vom Typ LoadBalancer reserviert sind, werden im Abschnitt loadBalancer.metalLB.addressPools der Konfigurationsdatei des Nutzerclusters angegeben. Diese VIPs befinden sich im selben VLAN wie die Worker-Knoten und die Knoten der Steuerungsebene. Die in diesem Abschnitt angegebene Gruppe von VIPs muss die virtuelle IP-Adresse für eingehenden Traffic enthalten, darf jedoch nicht die virtuelle IP-Adresse der Steuerungsebene enthalten.

  • Die Konfigurationsdatei des Nutzerclusters enthält keinen vCenter-Abschnitt. Daher verwendet der Nutzercluster dieselben vSphere-Ressourcen wie der Administratorcluster.

Konfigurationsdatei validieren

Nachdem Sie die Konfigurationsdatei des Nutzerclusters ausgefüllt haben, führen Sie gkectl check-config aus, um zu prüfen, ob die Datei gültig ist:

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Ersetzen Sie Folgendes:

  • ADMIN_CLUSTER_KUBECONFIG: Pfad der kubeconfig-Datei für Ihren Administratorcluster

  • USER_CLUSTER_CONFIG: Pfad Ihrer Nutzercluster-Konfigurationsdatei

Wenn der Befehl Fehlermeldungen zurückgibt, beheben Sie die Probleme und validieren Sie die Datei noch einmal.

Wenn Sie die zeitaufwendigeren Validierungen überspringen möchten, übergeben Sie das Flag --fast. Verwenden Sie die Flags --skip-validation-xxx, um einzelne Validierungen zu überspringen. Weitere Informationen zum Befehl check-config finden Sie unter Vorabprüfungen ausführen.

3. (Optional) Betriebssystem-Images in vSphere importieren und Container-Images in eine private Registry übertragen

Führen Sie gkectl prepare aus, wenn eine der folgenden Bedingungen zutrifft:

  • Der Nutzercluster befindet sich in einem anderen vSphere-Rechenzentrum als Ihr Administratorcluster.

  • Ihr Nutzercluster hat einen anderen vCenter Server als Ihr Administratorcluster.

  • Ihr Nutzercluster verwendet eine private Container-Registry, die sich von der privaten Registry unterscheidet, die von Ihrem Administratorcluster verwendet wird.

gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path BUNDLE \
    --user-cluster-config USER_CLUSTER_CONFIG

Ersetzen Sie Folgendes:

  • ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei Ihres Administratorclusters

  • BUNDLE: der Pfad der Bundle-Datei. Diese Datei befindet sich auf Ihrer Administrator-Workstation in /var/lib/gke/bundles/. Beispiel:

    /var/lib/gke/bundles/gke-onprem-vsphere-1.14.0-gke.421-full.tgz

  • USER_CLUSTER_CONFIG: Pfad Ihrer Nutzercluster-Konfigurationsdatei

4. Nutzercluster erstellen

Erstellen Sie einen Nutzercluster:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Suchen Sie die kubeconfig-Datei des Nutzerclusters.

Mit dem Befehl gkectl create cluster wird im aktuellen Verzeichnis die kubeconfig-Datei USER_CLUSTER_NAME-kubeconfig erstellt. Sie benötigen diese kubeconfig-Datei später, um mit Ihrem Nutzercluster zu interagieren.

Die kubeconfig-Datei enthält den Namen Ihres Nutzerclusters. Führen Sie folgenden Befehl aus, um den Clusternamen anzusehen:

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

Die Ausgabe zeigt den Namen des Clusters. Beispiel:

NAME
my-user-cluster

Wenn Sie möchten, können Sie den Namen und den Speicherort der kubeconfig-Datei ändern.

5. Prüfen Sie, ob Ihr Nutzercluster ausgeführt wird

Prüfen Sie, ob Ihr Nutzercluster ausgeführt wird:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

Die Ausgabe zeigt die Knoten des Nutzerclusters. Beispiel:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Nutzercluster aktualisieren

Folgen Sie der Anleitung unter Upgrade von Anthos Clusters on VMware.

Cluster löschen

Folgen Sie der Anleitung unter Nutzercluster löschen, um einen Nutzercluster zu löschen, für den Controlplane V2 aktiviert ist.

Wenn Sie einen Nutzercluster löschen, für den Controlplane V2 aktiviert ist, wird das Datenlaufwerk automatisch gelöscht.

Fehlerbehebung

Siehe Fehlerbehebung beim Erstellen und Upgraden von Clustern.

Nächste Schritte