This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

Dynamischer Speicher

In diesem Thema wird erläutert, wie Sie persistente Volumes und Speicherklassen verwenden, um dynamischen Speicher für Arbeitslastcluster von Tanzu Kubernetes Grid (TKG) zu implementieren.

Überblick: PersistentVolume, PersistentVolumeClaim und StorageClass

Innerhalb eines Kubernetes-Clusters stellen PV-Objekte PersistentVolume(PV) gemeinsam genutzten Speicher für Cluster-Pods bereit, die von Pod-Lebenszyklen nicht betroffen sind. Speicher wird dem PV über ein PVC-Objekt (PersistentVolumeClaim) bereitgestellt, das definiert, wie viel und wie der Pod auf den zugrunde liegenden Speicher zugreift. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Persistent Volumes.

Clusteradministratoren können StorageClass-Objekte definieren, mit denen Clusterbenutzer dynamisch PVC- und PV-Objekte mit unterschiedlichen Speichertypen und Regeln erstellen können. Tanzu Kubernetes Grid bietet auch Standardobjekte StorageClass, mit denen Benutzer persistenten Speicher in einer schlüsselfertigen Umgebung bereitstellen können.

StorageClass-Objekte enthalten ein Feld provisioner, das das interne oder externe Dienst-Plug-In identifiziert, das PVs bereitstellt, sowie ein Feld parameters, das die Kubernetes-Speicherklasse mit auf Infrastrukturebene definierten Speicheroptionen verknüpft, wie z. B. VM-Speicherrichtlinien in vSphere. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Storage Classes.

Unterstützte Speichertypen

Tanzu Kubernetes Grid unterstützt StorageClass-Objekte für verschiedene Speichertypen, die von Kubernetes-internen („In-Tree“)- oder externen Plug-Ins („Out-of-Tree“) bereitgestellt werden.

Speichertypen

  • vSphere Cloudnativer Speicher (CNS)
  • Amazon EBS
  • Azure-Festplatte
  • Azure-Datei
  • iSCSI
  • NFS
Hinweis

vSphere CSI bietet keine Unterstützung für Storage DRS und unterstützt Storage vMotion mit Bedingungen, die in der vSphere CSI-Dokumentation unter vSphere Functionality Supported by vSphere Container Storage Plug-in beschrieben sind.

vSphere CSI unterstützt Storage vMotion mit Bedingungen. Weitere Einzelheiten finden Sie im CSI-Dokument.

Informationen zu vSphere CNS-, Amazon EBS- und Azure Disk-Standardspeicherklassen finden Sie unter Standardspeicherklassen.

Externe Bereitstellung

In TKG v2.3 verwenden alle Standardspeicherklassen die externe Speicherbereitstellung („Out-of-Tree“) und nicht die Bereitstellung in der Struktur („In-Tree“).

  • Die Speicherklassen werden nicht mit Kern-Kubernetes geliefert.
  • provisioner-Werte des StorageClass-Objekts werden nicht kubernetes.io vorangestellt.
  • Bereitsteller folgen dem CSI-Standard (Container Storage Interface) für externen Speicher.
  • Arbeitslastcluster mit Standardspeicherklassen, die von früheren TKG-Versionen bereitgestellt wurden, verfügen möglicherweise über eine in der Struktur eingebettete Speicherbereitstellung. Informationen dazu finden Sie unter Create Persistent Volumes with Storage Classes.

Standardspeicherklassen

Tanzu Kubernetes Grid stellt StorageClass-Standardobjekte bereit, mit denen Benutzer von Arbeitslastclustern persistenten Speicher in ihrer Infrastruktur in einer schlüsselfertigen Umgebung bereitstellen können, ohne dass StorageClass-Objekte, die von einem Clusteradministrator erstellt wurden, benötigt werden.

Die Variable ENABLE_DEFAULT_STORAGE_CLASS ist in der Clusterkonfigurationsdatei, die an die --file-Option von tanzu cluster create übergeben wurde, standardmäßig auf true gesetzt, um die Standardspeicherklasse für einen Arbeitslastcluster zu aktivieren.

Wichtig

Ändern Sie die standardmäßigen Speicherklassendefinitionen nicht. Um eine Speicherklasse anzupassen, erstellen Sie eine neue StorageClass-Definition mit einem anderen name, anstatt das von TKG erstellte Standardobjekt zu ändern.

Die Standarddefinitionen von Tanzu Kubernetes Grid für Speicherklassen sind:

vSphere CNS

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: default
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: csi.vsphere.vmware.com
parameters:
  storagePolicyName: optional

Weitere Informationen finden Sie in den vSphere CSI-Speicherklassenparametern in der Kubernetes-Dokumentation.

Amazon EBS

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: default
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.aws.com

Weitere Informationen finden Sie in den Speicherklassenparametern unter Amazon-EBS-CSI-Treiber in der AWS-Dokumentation.

Azure-Festplatte

apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
  name: default
  annotations:
    storageclass.beta.kubernetes.io/is-default-class: "true"
  labels:
    kubernetes.io/cluster-service: "true"
provisioner: disk.csi.azure.com
parameters:
  kind: Managed
  storageaccounttype: Standard_LRS
  cachingmode: ReadOnly
volumeBindingMode: WaitForFirstConsumer

Weitere Informationen finden Sie in den Speicherklassenparametern unter CSI-Treiber für Azure-Datenträger in der Azure-Dokumentation.

Azure-Datei

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azure-file
  labels:
    kubernetes.io/cluster-service: "true"
provisioner: file.csi.azure.com
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict
  - actimeo=30
allowVolumeExpansion: true
parameters:
  skuName: Premium_LRS

Weitere Informationen finden Sie in den Speicherklassenparametern unter Azure-Datei in der Kubernetes-Dokumentation.

Einrichten von CNS und Erstellen einer Speicherrichtlinie (vSphere)

vSphere-Administratoren können vSphere CNS einrichten und Speicherrichtlinien für VMDK-Speicher (Virtual Disk Storage) basierend auf den Anforderungen von Tanzu Kubernetes Grid-Clusterbenutzern erstellen.

Sie können entweder vSAN oder lokales VMFS (Virtual Machine File System) für persistenten Speicher in einem Kubernetes-Cluster wie folgt verwenden:

vSAN-Speicher:

Um eine Speicherrichtlinie für vSAN-Speicher im vSphere Client zu erstellen, navigieren Sie zu Startseite (Home) > Richtlinien und Profile (Policies and Profiles) > VM-Speicherrichtlinien (VM Storage Policies) und klicken Sie auf Erstellen (Create), um den Assistenten VM-Speicherrichtlinie erstellen (Create VM Storage Policy) zu starten.

Befolgen Sie die Anweisungen unter Erstellen einer Speicherrichtlinie für Kubernetes in der vSphere-Dokumentation. Stellen Sie Folgendes sicher:

  • Aktivieren Sie auf der Seite Richtlinienstruktur (Policy structure) unter Datenspeicherspezifische Regeln (Datastore specific rules) Regeln für die Platzierung des „vSAN-Speichers“ aktivieren (Enable rules for “vSAN” storage).
  • Konfigurieren Sie nach Bedarf andere Fensterbereiche oder akzeptieren Sie die Standardeinstellungen.
  • Notieren Sie sich den Namen der Speicherrichtlinie zu Referenzzwecken als storagePolicyName-Wert in StorageClass-Objekten.

Lokaler VMFS-Speicher:

Um eine Speicherrichtlinie für den lokalen Speicher zu erstellen, wenden Sie ein Tag auf den Speicher an und erstellen Sie wie folgt eine Speicherrichtlinie basierend auf dem Tag:

  1. Wählen Sie aus dem vSphere-Menü ganz oben Tags und benutzerdefinierte Attribute (Tags & Custom Attributes).

  2. Wählen Sie im Fensterbereich Tags die Option Kategorien (Categories) aus und klicken Sie auf Neu (New).

  3. Geben Sie einen Kategorienamen ein, z. B. tkg-storage. Verwenden Sie die Kontrollkästchen, um ihn mit Datencenter (Datacenter) und den Speicherobjekten Ordner (Folder) und Datenspeicher (Datastore) zu verknüpfen. Klicken Sie auf Erstellen.

  4. Wählen Sie in der Ansicht Speicher (Storage) ganz oben Ihr VMFS-Volume aus und klicken Sie im Fensterbereich Übersicht (Summary) auf Tags > Zuweisen (Assign)….

  5. Klicken Sie im Popup-Fenster Tag zuweisen (Assign Tag) auf Tag hinzufügen (Add Tag).

  6. Geben Sie im Popup-Fenster Tag erstellen (Create Tag) einen Namen für das Tag ein, z. B. tkg-storage-ds1, und weisen Sie ihm die von Ihnen erstellte Kategorie unter Kategorie (Category) zu. Klicken Sie auf OK.

  7. Wählen Sie unter Tag zuweisen (Assign Tag) das Tag aus und klicken Sie auf Zuweisen (Assign).

  8. Wählen Sie in vSphere ganz oben VM-Speicherrichtlinien (VM Storage Policies) > Speicherrichtlinie erstellen (Create a Storage Policy) aus. Es wird ein Konfigurationsassistent gestartet.

  9. Geben Sie im Fensterbereich Name und Beschreibung (Name and description) einen Namen für Ihre Speicherrichtlinie ein. Notieren Sie sich den Namen der Speicherrichtlinie zu Referenzzwecken als storagePolicyName-Wert in StorageClass-Objekten.

  10. Aktivieren Sie im Fensterbereich Richtlinienstruktur (Policy structure) unter Datenspeicherspezifische Regeln (Datastore specific rules) die Option Tag-basierte Platzierungsregeln aktivieren (Enable tag-based placement rules).

  11. Klicken Sie im Fensterbereich Tag-basierte Platzierung (Tag based placement) auf Tag-Regel hinzufügen (Add Tag Rule) und konfigurieren Sie Folgendes:

    • Tag-Kategorie (Tag category): Wählen Sie Ihren Kategorienamen aus.
    • Verwendungsoption (Usage option): Use storage tagged with
    • Tags: Suchen und wählen Sie Ihren Tag-Namen aus.

  12. Bestätigen und konfigurieren Sie andere Fensterbereiche oder übernehmen Sie nach Bedarf Standardeinstellungen und klicken Sie dann auf Überprüfen und fertig stellen (Review and finish). Beenden Sie über Fertigstellen (Finish) den Vorgang, um die Speicherrichtlinie zu erstellen.

Erstellen einer benutzerdefinierten Speicherklasse

Clusteradministratoren können eine neue Speicherklasse wie folgt erstellen:

  1. Wählen oder erstellen Sie in vSphere die VM-Speicherrichtlinie, die als Basis für die Kubernetes-StorageClass verwendet werden soll.
  2. Erstellen Sie eine StorageClass-Konfiguration als .yaml-Datei mit provisioner, parameters und anderen Optionen.
    • Verknüpfen Sie in vSphere eine Kubernetes-Speicherklasse mit einer vSphere-Speicherrichtlinie, indem Sie den Parameter storagePolicyName auf den Namen der vSphere Speicherrichtlinie als Zeichenfolge mit doppelten Anführungszeichen setzen.
  3. Übergeben Sie die Datei an kubectl create -f.
  4. Überprüfen Sie die Speicherklasse, indem Sie kubectl describe storageclass <storageclass metadata.name> ausführen.

Ein Beispiel finden Sie unter Enabling Dynamic Provisioning in der Kubernetes-Dokumentation.

Informationen und Ressourcen zu vSphere CSI finden Sie in der Dokumentation zum VMware vSphere Container Storage Plug-In.

Verwenden einer benutzerdefinierten Speicherklasse in einem Cluster

Um persistenten Speicher für ihre Clusterknoten bereitzustellen, der keine der oben beschriebenen Standardspeicherklassen verwendet, fügen Clusterbenutzer wie folgt eine benutzerdefinierte Speicherklasse in eine Pod-Konfiguration ein:

  1. Legen Sie den Kontext von kubectl auf den Cluster fest. Beispiel:

    kubectl config use-context my-cluster-admin@my-cluster

  2. Wählen Sie eine Speicherklasse aus oder erstellen Sie sie.

    • Auswählen:
      • Um die verfügbaren Speicherklassen aufzulisten, führen Sie kubectl get storageclass aus.
    • Erstellen

  3. Erstellen Sie einen PVC und das zugehörige PV:

    1. Erstellen Sie eine PersistentVolumeClaim-Konfiguration als .yaml-Datei mit spec.storageClassName-Option, die auf den Wert metadata.name Ihres StorageClass-Objekt gesetzt ist. Ein Beispiel finden Sie unter Enabling Dynamic Provisioning in der Kubernetes-Dokumentation.
    2. Übergeben Sie die Datei an kubectl create -f.
    3. Führen Sie kubectl describe pvc <pvc metadata.name> aus, um den PVC zu überprüfen.
    4. Mit dem PVC wird automatisch ein PV erstellt. Notieren Sie sich den Namen, der in der Ausgabe von kubectl describe pvc nach der Meldung Successfully provisioned volume aufgeführt wird.
    5. Führen Sie kubectl describe pv <pv unique name> aus, um den PV zu überprüfen.

  4. Erstellen Sie einen Pod mithilfe des PVC:

    1. Erstellen Sie eine Pod-Konfiguration als .yaml-Datei, die spec.volumes so festlegt, dass Ihr PVC unter persistentVolumeClaim.claimName enthalten ist. Ein Beispiel finden Sie unter Dynamically Provision a Block Volume with vSphere Container Storage Plug-In in der Dokumentation zum vSphere Container Storage Plug-In.
    2. Übergeben Sie die Datei an kubectl create -f.
    3. Führen Sie kubectl get pod <pod metadata.name> aus, um den Pod zu überprüfen.

Aktivieren der Volumeerweiterung für vSphere CSI (vSphere 7)

Um die Volumeerweiterung für vSphere CSI-Speicher, der von Arbeitslastclustern verwendet wird, zu aktivieren, müssen Sie einen csi-resizer-Sidecar-Pod zu den CSI-Prozessen des Clusters hinzufügen.

Die CSI-Konfiguration für Arbeitslastcluster ist als geheimer Kubernetes-Schlüssel codiert. Bei diesem Verfahren wird der Prozess csi-resizer hinzugefügt, indem der geheime CSI-Konfigurationsschlüssel überarbeitet wird. Dabei wird dem geheimen Schlüssel eine stringData-Definition hinzugefügt, die zwei codierte Konfigurationsdatenzeichenfolgen kombiniert: eine values.yaml-Zeichenfolge, die die vorherigen CSI-Konfigurationsdaten des geheimen Schlüssels enthält, und eine neue overlays.yaml-Zeichenfolge, die den csi-resizer-Pod bereitstellt.

Hinweis

Die Online-Erweiterung von Volumes wird in vSphere 7.0 ab Update 2 unterstützt. Weitere Informationen finden Sie unter Volume-Erweiterung in vSphere with Tanzu.

  1. Melden Sie sich beim Verwaltungscluster für den Arbeitslastcluster an, den Sie ändern, und führen Sie tanzu cluster list aus, wenn Sie den Namen des Arbeitslastclusters abrufen müssen.

  2. Rufen Sie den Namen des geheimen CSI-Schlüssels für den Arbeitslastcluster ab, indem Sie Bezeichnungsselektoren vsphere-csi und den Clusternamen verwenden:

    $ kubectl get secret \
  -l tkg.tanzu.vmware.com/cluster-name=NAME_OF_WORKLOAD_CLUSTER \
  -l tkg.tanzu.vmware.com/addon-name=vsphere-csi
my-wc-vsphere-csi-secret

  3. Speichern Sie eine Sicherung des Inhalts des geheimen Schlüssels im YAML-Format unter vsphere-csi-secret.yaml:

    kubectl get secret my-wc-vsphere-csi-secret -o yaml > vsphere-csi-secret.yaml

  4. Geben Sie den aktuellen Inhalt des geheimen Schlüssels erneut aus, wobei die Werte data.values mit base64 als einfache YAML-Datei dekodiert werden.

    $ kubectl get secret my-wc-vsphere-csi-secret -o jsonpath={.data.values\\.yaml} | base64 -d

#@data/values
#@overlay/match-child-defaults missing_ok=True
---
vsphereCSI:
CSIAttacherImage:
  repository: projects.registry.vmware.com/tkg
  path: csi/csi-attacher
  tag: v3.0.0_vmware.1
  pullPolicy: IfNotPresent
vsphereCSIControllerImage:
  repository: projects.registry.vmware.com/tkg
  path: csi/vsphere-block-csi-driver
  tag: v2.1.1_vmware.1
  pullPolicy: IfNotPresent
livenessProbeImage:
  repository: projects.registry.vmware.com/tkg
  path: csi/csi-livenessprobe
  tag: v2.1.1_vmware.1
  pullPolicy: IfNotPresent
vsphereSyncerImage:
  repository: projects.registry.vmware.com/tkg
  path: csi/volume-metadata-syncer
  tag: v2.1.1_vmware.1
  pullPolicy: IfNotPresent
CSIProvisionerImage:
  repository: projects.registry.vmware.com/tkg
  path: csi/csi-provisioner
  tag: v2.0.0_vmware.1
  pullPolicy: IfNotPresent
CSINodeDriverRegistrarImage:
  repository: projects.registry.vmware.com/tkg
  path: csi/csi-node-driver-registrar
  tag: v2.0.1_vmware.1
  pullPolicy: IfNotPresent
namespace: kube-system
clusterName: wc-1
server: 10.170.104.114
datacenter: /dc0
publicNetwork: VM Network
username: <MY-VSPHERE-USERNAME>
password: <MY-VSPHERE-PASSWORD>

  5. Öffnen Sie vsphere-csi-secret.yaml in einem Editor und führen Sie die folgenden Schritte aus, damit der Inhalt wie der folgende Code aussieht:

    1. Löschen Sie die vorhandene Definition für values.yaml, bei der es sich um eine lange Zeichenfolge handelt.
    2. Fügen Sie nach der ersten Zeile eine Zeile hinzu, die stringData definiert und rücken Sie values.yaml ein, damit sie zum ersten Element wird.
    3. Kopieren Sie die Ausgabe von data.values aus dem vorherigen Schritt.
    4. Fügen Sie nach der dritten Zeile die Ausgabe von data.values ein und rücken Sie sie als Wert von values.yaml ein.
    5. Fügen Sie direkt unter der Definition values.yaml eine weitere stringData-Definition für overlays.yaml hinzu, wie unten gezeigt. Ändern Sie keine anderen Definitionen in der Datei.
    apiVersion: v1
stringData:
  values.yaml: |
    #@data/values
    #@overlay/match-child-defaults missing_ok=True
    ---
    vsphereCSI:
      CSIAttacherImage:
        repository: projects.registry.vmware.com/tkg
        path: csi/csi-attacher
        tag: v3.0.0_vmware.1
        pullPolicy: IfNotPresent
      vsphereCSIControllerImage:
        repository: projects.registry.vmware.com/tkg
        path: csi/vsphere-block-csi-driver
        tag: v2.1.1_vmware.1
        pullPolicy: IfNotPresent
      livenessProbeImage:
        repository: projects.registry.vmware.com/tkg
        path: csi/csi-livenessprobe
        tag: v2.1.1_vmware.1
        pullPolicy: IfNotPresent
      vsphereSyncerImage:
        repository: projects.registry.vmware.com/tkg
        path: csi/volume-metadata-syncer
        tag: v2.1.1_vmware.1
        pullPolicy: IfNotPresent
      CSIProvisionerImage:
        repository: projects.registry.vmware.com/tkg
        path: csi/csi-provisioner
        tag: v2.0.0_vmware.1
        pullPolicy: IfNotPresent
      CSINodeDriverRegistrarImage:
        repository: projects.registry.vmware.com/tkg
        path: csi/csi-node-driver-registrar
        tag: v2.0.1_vmware.1
        pullPolicy: IfNotPresent
      namespace: kube-system
      clusterName: wc-1
      server: 10.170.104.114
      datacenter: /dc0
      publicNetwork: VM Network
      username: <MY-VSPHERE-USERNAME>
      password: <MY-VSPHERE-PASSWORD>
  overlays.yaml: |
    #@ load("@ytt:overlay", "overlay")
    #@overlay/match by=overlay.subset({"kind": "Deployment", "metadata": {"name": "vsphere-csi-controller"}})
    ---
    spec:
      template:
        spec:
          containers:
          #@overlay/append
            - name: csi-resizer
              image: projects.registry.vmware.com/tkg/kubernetes-csi_external-resizer:v1.0.0_vmware.1
              args:
                - "--v=4"
                - "--timeout=300s"
                - "--csi-address=$(ADDRESS)"
                - "--leader-election"
              env:
                - name: ADDRESS
                  value: /csi/csi.sock
              volumeMounts:
                - mountPath: /csi
                  name: socket-dir
kind: Secret
...

  6. Führen Sie kubectl apply aus, um den geheimen Schlüssel des Clusters mit den überarbeiteten Definitionen zu aktualisieren und erstellen Sie den Pod csi-controller neu:

    kubectl apply -f vsphere-csi-secret.yaml

  7. So überprüfen Sie, ob der vsphere-csi-controller und der externe Resizer auf dem Cluster funktionieren:

    1. Bestätigen Sie, dass vsphere-csi-controller auf dem Arbeitslastcluster mit sechs fehlerfreien Pods ausgeführt wird:

      $ kubectl get pods -n kube-system -l app=vsphere-csi-controller
NAME                                     READY   STATUS    RESTARTS   AGE
vsphere-csi-controller-<ID-HASH>   6/6     Running   0          6m49s

    2. Überprüfen Sie die Protokolle der vsphere-csi-controller, um zu sehen, ob der externe Resizer gestartet wurde.

      $ kubectl logs vsphere-csi-controller-<ID-HASH> -n kube-system -c csi-resizer
I0308 23:44:45.035254       1 main.go:79] Version : v1.0.0-0-gb22717d
I0308 23:44:45.037856       1 connection.go:153] Connecting to unix:///csi/csi.sock
I0308 23:44:45.038572       1 common.go:111] Probing CSI driver for readiness
I0308 23:44:45.040579       1 csi_resizer.go:77] CSI driver name: "csi.vsphere.vmware.com"
W0308 23:44:45.040612       1 metrics.go:142] metrics endpoint will not be started because `metrics-address` was not specified.
I0308 23:44:45.042184       1 controller.go:117] Register Pod informer for resizer csi.vsphere.vmware.com
I0308 23:44:45.043182       1 leaderelection.go:243] attempting to acquire leader lease  kube-system/external-resizer-csi-vsphere-vmware-com...
I0308 23:44:45.073383       1 leaderelection.go:253] successfully acquired lease kube-system/external-resizer-csi-vsphere-vmware-com
I0308 23:44:45.076028       1 leader_election.go:172] new leader detected, current leader: vsphere-csi-controller-87d7dcf48-jcht2
I0308 23:44:45.079332       1 leader_election.go:165] became leader, starting
I0308 23:44:45.079638       1 controller.go:241] Starting external resizer csi.vsphere.vmware.com

Weitere Informationen zum Erweitern von vSphere CSI-Speichervolumes im Online- oder Offlinemodus finden Sie unter Volume-Erweiterung in vSphere with Tanzu.

Topologiefähige Volumebereitstellung (vSphere)

Für Arbeitslastcluster, die aus einem eigenständigen Verwaltungscluster erstellt wurden, können Sie die topologiefähige Bereitstellung von lokalen Speichervolumes konfigurieren. Topologiefähige Volumebereitstellung ermöglicht Kubernetes, intelligente Entscheidungen bei der dynamischen Bereitstellung von Volumes zu treffen. Kubernetes erhält die Scheduler-Eingabe an der besten Stelle, an der ein Volume für einen Pod bereitgestellt werden kann.

Erstellen Sie eine Verfügbarkeitszone (Availability Zone, AZ):

  1. Folgen Sie den Anweisungen unter Ausführen von Clustern in mehreren Verfügbarkeitszonen, um Folgendes in vSphere zu erstellen:

    1. Fügen Sie eine Hostgruppe und eine VM-Gruppe hinzu.

    2. Fügen Sie Regeln hinzu, um die VM-Gruppe in der Hostgruppe einzuschränken.

      Eine VM-Gruppe und Hostgruppe wird verwendet, um die Verfügbarkeitsbereiche im Arbeitslastcluster auszuführen.

      Hinweis

      Die Grenzwertregeln gelten nur für Konfigurationen von lokalen Volumes. Sie müssen keine Grenzwertregeln erstellen, wenn Sie die Bereitstellung in mehreren Verfügbarkeitszonen durchführen.

    3. Stellen Sie die benutzerdefinierten Ressourcendefinitionen (CRDs) VSphereFailureDomain und VSphereDeploymentZone im eigenständigen Verwaltungscluster bereit.

      Die Verfügbarkeitszone verweist auf eine VSphereDeploymentZone und dann auf eine Hostgruppe in vSphere.

  2. Fügen Sie eine neue Verfügbarkeitszone hinzu. Sie können eine neue Verfügbarkeitszone hinzufügen, indem Sie eine ytt-Overlay-Konfiguration oder die Tanzu CLI verwenden.

    ytt
    Nachfolgend sehen Sie Beispiele für eine ytt-Overlay-Konfiguration in einem Legacy-Cluster und in einem klassischen Cluster. Informationen zum Herunterladen und Installieren von ytt finden Sie unter Installieren der Carvel-Tools.

    Legacy-Cluster

    #@overlay/match by=overlay.subset({"kind":"MachineDeployment", "metadata":{"name": "${CLUSTER_NAME}-md-0"}})
  ---
  apiVersion: cluster.x-k8s.io/v1beta1
  kind: MachineDeployment
  metadata:
    name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
  spec:
    clusterName: #@ data.values.CLUSTER_NAME
    replicas: #@ data.values.WORKER_MACHINE_COUNT_0
    selector:
      matchLabels: null
    strategy:
      type: #@ verify_and_configure_machine_deployment_rollout_strategy(data.values.WORKER_ROLLOUT_STRATEGY)
    template:
      metadata:
        labels:
          node-pool: #@ "{}-worker-pool".format(data.values.CLUSTER_NAME)
      spec:
        clusterName: #@ data.values.CLUSTER_NAME
        version: #@ data.values.KUBERNETES_VERSION
        bootstrap:
          configRef:
            name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
            apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
            kind: KubeadmConfigTemplate
        infrastructureRef:
          name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
          apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
          kind: AWSMachineTemplate
        failureDomain: #@ default_az_0

    Klassischer Cluster

    workers:
  machineDeployments:
  #@overlay/match by=overlay.index(0)
  - class: tkg-worker
    name: md-0
    replicas: #@ data.values.WORKER_MACHINE_COUNT_0
    #@overlay/match missing_ok=True
    failureDomain: #@ default_az_0
    metadata:
      annotations:
        run.tanzu.vmware.com/resolve-os-image: #@ "ami-region={},os-name={},os-arch={}".format(data.values.AWS_REGION, data.values.OS_NAME, data.values.OS_ARCH)
    Tanzu CLI
    Sie können eine neue Verfügbarkeitszone erstellen, um die topologiefähige lokale Speicherbereitstellung mithilfe der Tanzu CLI zu unterstützen.

    Legacy-Cluster

    tanzu cl node-pool set cl-name -f node-pool.yaml

# node-pool.yaml
name: vsphere-wc-1-manual-node-pool
replicas: 1
az: "rack4"

    Klassischer Cluster

    Weitere Informationen finden Sie im Abschnitt zum „set“-Befehl (Erstellen) unter Konfiguration von Knotenpools für ClusterClass-basierte Cluster.

check-circle-line exclamation-circle-line close-line
Scroll to top icon