Almacenamiento dinámico

En este tema se explica cómo utilizar las clases de almacenamiento y los volúmenes persistentes para implementar almacenamiento dinámico para clústeres de carga de trabajo de Tanzu Kubernetes Grid (TKG).

Descripción general: PersistentVolume, PersistentVolumeClaim y StorageClass

Dentro de un clúster de Kubernetes, los objetos PersistentVolume (PV) proporcionan almacenamiento compartido para los pods de clúster que no se ven afectados por los ciclos de vida de los pods. El almacenamiento se aprovisiona al PV a través de un objeto PersistentVolumeClaim (PVC), que define cuánto y cómo el pod accede al almacenamiento subyacente. Para obtener más información, consulte Volúmenes persistentes en la documentación de Kubernetes.

Los administradores de clústeres pueden definir objetos StorageClass que permiten a los usuarios del clúster crear de forma dinámica objetos de PVC y PV con diferentes tipos y reglas de almacenamiento. Tanzu Kubernetes Grid también proporciona objetos StorageClass predeterminados que permiten a los usuarios aprovisionar almacenamiento persistente en un entorno llave en mano.

Los objetos StorageClass incluyen un campo provisioner que identifica el complemento de servicio interno o externo que aprovisiona PV y un campo parameters que asocia la clase de almacenamiento de Kubernetes con las opciones de almacenamiento definidas en el nivel de infraestructura, como las directivas de almacenamiento de máquina virtual en vSphere. Para obtener más información, consulte Clases de almacenamiento en la documentación de Kubernetes.

Tipos de almacenamientos compatibles

Tanzu Kubernetes Grid admite objetos StorageClass para diferentes tipos de almacenamiento, aprovisionados por complementos de Kubernetes internos ("en el árbol") o externos ("fuera del árbol").

Tipos de almacenamiento

Almacenamiento nativo en la nube de vSphere (CNS)
Amazon EBS
Disco de Azure
Archivo de Azure
iSCSI
NFS

Nota
vSphere CSI no admite la DRS de almacenamiento y admite el almacenamiento de vMotion con las condiciones descritas en Funcionalidad de vSphere compatible con el complemento de almacenamiento de contenedores de vSphere en la documentación de vSphere CSI.

vSphere CSI es compatible con Storage vMotion con condiciones, lea el documento de CSI para obtener más información.

Consulte Clases de almacenamiento predeterminadas para obtener vSphere CNS, Amazon EBS y clases de almacenamiento predeterminadas de disco de Azure.

Aprovisionamiento externo

En TKG v2.1, todas las clases de almacenamiento predeterminadas utilizan el aprovisionamiento de almacenamiento externo ("fuera del árbol"), no el aprovisionamiento "en el árbol".

Las clases de almacenamiento no incluyen Kubernetes principal.
Los valores del objeto StorageClass provisioner no tienen el prefijo kubernetes.io.
Los aprovisionadores siguen el estándar de la interfaz de almacenamiento de contenedor (CSI) para el almacenamiento externo.
Los clústeres de carga de trabajo con clases de almacenamiento predeterminadas implementadas por versiones anteriores de TKG pueden tener aprovisionamiento de almacenamiento en el árbol. Consulte Crear volúmenes persistentes con clases de almacenamiento.

Clases de almacenamiento predeterminadas

Tanzu Kubernetes Grid proporciona objetos StorageClass predeterminados que permiten a los usuarios de clústeres de carga de trabajo aprovisionar almacenamiento persistente en su infraestructura en un entorno llave en mano, sin necesidad de objetos StorageClass creados por un administrador de clústeres.

La variable ENABLE_DEFAULT_STORAGE_CLASS se establece en true de forma predeterminada en el archivo de configuración del clúster que se pasa a la opción --file de tanzu cluster create para habilitar la clase de almacenamiento predeterminada para un clúster de carga de trabajo.

Importante
No modifique las definiciones de clases de almacenamiento predeterminadas. Para personalizar una clase de almacenamiento, cree una nueva definición de StorageClass con un name diferente en lugar de modificar el objeto predeterminado creado por TKG.

Las definiciones de clase de almacenamiento predeterminadas de Tanzu Kubernetes Grid son las siguientes:

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

Consulte los parámetros de clase de almacenamiento de vSphere CSI en la documentación de Kubernetes.

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

Consulte los parámetros de clase de almacenamiento del Controlador CSI de Amazon EBS en la documentación de AWS.

Disco de Azure

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

Consulte los parámetros de clase de almacenamiento del Controlador CSI de discos de Azure en la documentación de Azure.

Archivo de Azure

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

Consulte los parámetros de clase de almacenamiento del Archivo de Azure en la documentación de Kubernetes.

Configurar CNS y crear una directiva de almacenamiento (vSphere)

Los administradores de vSphere pueden configurar vSphere CNS y crear directivas de almacenamiento para el almacenamiento de disco virtual (Virtual Disk, VMDK), según las necesidades de los usuarios del clúster de Tanzu Kubernetes Grid.

Puede utilizar vSAN o VMFS (sistema de archivos de máquina virtual [Virtual Machine File System]) local para el almacenamiento persistente en un clúster de Kubernetes, de la siguiente manera:

Almacenamiento de vSAN:

Si desea crear una directiva de almacenamiento para el almacenamiento de vSAN en vSphere Client, desplácese hasta Inicio (Home) > Directivas y perfiles (Policies and Profiles) > Directivas de almacenamiento de máquina virtual (VM Storage Policies) y haga clic en Crear (Create) para iniciar el asistente Crear directiva de almacenamiento de máquina virtual (Create Vm Storage Policy).

Siga las instrucciones en Crear una directiva de almacenamiento en la documentación de vSphere. Asegúrese de:

En el panel Estructura de directiva (Policy structure), en Reglas específicas de almacenes de datos (Datastore specific rules), seleccione Habilitar reglas para el almacenamiento de “vSAN” (Enable rules for “vSAN” storage).
Configure otros paneles o acepte los valores predeterminados según sea necesario.
Registre el nombre de la directiva de almacenamiento para referencia como el valor storagePolicyName en objetos StorageClass.

Almacenamiento de VMFS local (Local VMFS Storage):

Para crear una directiva de almacenamiento para el almacenamiento local, aplique una etiqueta al almacenamiento y cree una directiva de almacenamiento basada en la etiqueta de la siguiente manera:

En el menú de nivel superior de vSphere, seleccione Etiquetas y atributos personalizados (Tags & Custom Attributes)
En el panel Etiquetas (Tags), seleccione Categorías (Categories) y haga clic en Nueva (New).
Introduzca un nombre de categoría, como tkg-storage. Utilice las casillas de verificación para asociarlo con Centro de datos (Datacenter) y los objetos de almacenamiento, Carpeta (Folder) y Almacén de datos (Datastore). Haga clic en Crear (Create).
En la vista Almacenamiento (Storage) de nivel superior, seleccione el volumen VMFS y, en su panel Resumen (Summary), haga clic en Etiquetas (Tags) > Asignar (Assign)….
En el cuadro emergente Asignar etiqueta (Assign Tag), haga clic en Añadir etiqueta (Add Tag).
En la ventana emergente Crear etiqueta (Create Tag), asigne un nombre a la etiqueta (por ejemplo, tkg-storage-ds1 y asígnele la Categoría (Category) que creó. Haga clic en Aceptar (OK).
En Asignar etiqueta (Assign Tag), seleccione la etiqueta y haga clic en Asignar (Assign).
En vSphere de nivel superior, seleccione Directivas de almacenamiento de máquina virtual (VM Storage Policies) > Cree una directiva de almacenamiento (Create a Storage Policy). Se inicia un asistente de configuración.
En el panel Nombre y descripción (Name and description), introduzca un nombre para la política de almacenamiento. Registre el nombre de la directiva de almacenamiento para referencia como el valor storagePolicyName en objetos StorageClass.
En el panel Estructura de directiva (Policy structure) en Reglas específicas del almacén de datos (Datastore specific rules), seleccione Habilitar reglas de ubicación basadas en etiquetas (Enable tag-based placement rules).
En el panel Ubicación basada en etiquetas (Tag based placement), haga clic en Añadir regla de etiqueta (Add Tag Rule) y configure:
- Categoría de etiqueta (Tag category): Seleccione el nombre de la categoría
- Opción de uso (Usage option): Use storage tagged with
- Etiquetas (Tags): Examinar y seleccionar el nombre de la etiqueta
Confirme y configure otros paneles o acepte los valores predeterminados según sea necesario y haga clic en Ver y finalizar (Review and finish). Seleccione Finalizar (Finish) para crear la directiva de almacenamiento.

Crear una clase de almacenamiento personalizada

Los administradores de clústeres pueden crear una nueva clase de almacenamiento de la siguiente manera:

En vSphere, seleccione o cree la directiva de almacenamiento de máquina virtual que se utilizará como base para la StorageClass de Kubernetes.
- Los administradores de vSphere pueden crear una directiva de almacenamiento siguiendo la sección anterior Crear una directiva de almacenamiento (vSphere).
Cree una configuración de StorageClass .yaml con provisioner, parameters y otras opciones.
- En vSphere, asocie una clase de almacenamiento de Kubernetes con una directiva de almacenamiento vSphere estableciendo su parámetro storagePolicyName en el nombre de la directiva de almacenamiento de vSphere, como una cadena de comillas dobles.
Pasar el archivo a kubectl create -f
Compruebe la clase de almacenamiento ejecutando kubectl describe storageclass <storageclass metadata.name>.

Por ejemplo, consulte Habilitar aprovisionamiento dinámico en la documentación de Kubernetes.

Para obtener recursos e información de vSphere CSI, consulte Documentación del complemento de almacenamiento de contenedores de VMware vSphere.

Usar una clase de almacenamiento personalizada en un clúster

Para aprovisionar el almacenamiento persistente para los nodos del clúster que no utilizan una de las Clases de almacenamiento predeterminadas descritas anteriormente, los usuarios del clúster incluyen una clase de almacenamiento personalizada en una configuración de pod de la siguiente manera:

Establezca el contexto de kubectl en el clúster. Por ejemplo:
```
kubectl config use-context my-cluster-admin@my-cluster
```
Seleccione o cree una clase de almacenamiento.
- Seleccionar:
  - Para ver una lista de las clases de almacenamiento disponibles, ejecute kubectl get storageclass.
- Crear
  - Los administradores de clústeres pueden crear clases de almacenamiento siguiendo la sección anterior Crear una clase de almacenamiento personalizada.
Cree una PVC y su PV:
1. Cree una configuración PersistentVolumeClaim .yaml con spec.storageClassName establecido en el valor metadata.name del objeto StorageClass. Por ejemplo, consulte Habilitar aprovisionamiento dinámico en la documentación de Kubernetes.
2. Pasar el archivo a kubectl create -f
3. Ejecute kubectl describe pvc <pvc metadata.name> para comprobar la PVC.
4. Un PV se crea automáticamente con la PVC. Registre su nombre, que aparece en los resultados de kubectl describe pvc después de Successfully provisioned volume.
5. Ejecute kubectl describe pv <pv unique name> para comprobar el PV.
Cree un pod mediante la PVC:
1. Cree una configuración Pod .yaml que establezca spec.volumes para incluir la PVC en persistentVolumeClaim.claimName. Para ver un ejemplo, consulte Aprovisionar dinámicamente un volumen en bloque con el complemento de almacenamiento de contenedores de vSphere en la documentación del complemento de almacenamiento de contenedores de vSphere.
2. Pasar el archivo a kubectl create -f
3. Ejecute kubectl get pod <pod metadata.name> para comprobar el pod.

Habilitar la expansión de volumen para vSphere CSI (vSphere 7)

Para habilitar la expansión de volumen para el almacenamiento vSphere CSI que usan los clústeres de carga de trabajo, debe agregar un pod sidecar csi-resizer a los procesos CSI del clúster.

La configuración de CSI para los clústeres de carga de trabajo se codifica como un secreto de Kubernetes. Este procedimiento agrega el proceso csi-resizer revisando el secreto de configuración de CSI. Agrega al secreto una definición de stringData que combina dos cadenas de datos de configuración codificadas: una cadena values.yaml que contiene los datos de configuración CSI anteriores del secreto y una nueva cadena overlays.yaml que implementa el pod csi-resizer.

Nota
La expansión de volumen conectado es compatible con vSphere 7.0 a partir de la actualización 2; consulte Expansión de volumen en vSphere with Tanzu.

Inicie sesión en el clúster de administración del clúster de carga de trabajo que va a cambiar y ejecute tanzu cluster list si necesita recuperar el nombre del clúster de carga de trabajo.

Recupere el nombre del secreto de CSI para el clúster de carga de trabajo, mediante los selectores de etiquetas vsphere-csi y el nombre del clúster:

$ 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

Guarde una copia de seguridad del contenido del secreto, en formato YAML, en vsphere-csi-secret.yaml:
```
kubectl get secret my-wc-vsphere-csi-secret -o yaml > vsphere-csi-secret.yaml
```

Vuelva a generar el contenido actual del secreto con los valores de data.values base64 descodificados en YAML sin formato.

$ 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>

Abra vsphere-csi-secret.yaml en un editor y realice lo siguiente para que se vea como el siguiente código:

Elimine la definición existente de values.yaml, que es una cadena larga.
Después de la primera línea, agregue una línea que defina stringData y aplique sangría en values.yaml para convertirlo en el primer elemento.
Copie los resultados de data.values del paso anterior.
Después de la tercera línea, pegue los resultados de data.values y aplique sangría como el valor de values.yaml.
Inmediatamente debajo de la definición de values.yaml, agregue otra definición de stringData para overlays.yaml como se muestra a continuación. No modifique otras definiciones del archivo.

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

Ejecute kubectl apply para actualizar el secreto del clúster con las definiciones revisadas y volver a crear el pod csi-controller:
```
kubectl apply -f vsphere-csi-secret.yaml
```

Para comprobar que el vsphere-csi-controller y el cambio de tamaño externo funcionan en el clúster:

Confirme que vsphere-csi-controller se esté ejecutando en el clúster de carga de trabajo con seis pods en buen estado:

$ 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

Compruebe los registros de vsphere-csi-controller para ver que se inició el cambio de tamaño externo.

$ 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

Para obtener más información sobre cómo expandir los volúmenes de almacenamiento de vSphere CSI en modo conectado o sin conexión, consulte Expandir un volumen persistente en modo conectado y Expandir un volumen persistente en modo sin conexión.

Aprovisionamiento de volúmenes con reconocimiento de topología (vSphere)

Para los clústeres de carga de trabajo creados a partir de un clúster de administración independiente, puede configurar el aprovisionamiento de volúmenes de almacenamiento local con reconocimiento de topología. El aprovisionamiento de volúmenes con reconocimiento de topología permite a Kubernetes tomar decisiones inteligentes al aprovisionar volúmenes de forma dinámica. Kubernetes obtiene la entrada del programador en el mejor lugar para aprovisionar un volumen para un pod.

Cree una zona de disponibilidad (AZ):

Siga las instrucciones en Implementar clústeres de carga de trabajo en varias zonas de disponibilidad (vista previa técnica de vSphere) para crear lo siguiente en vSphere:
1. Agregue un grupo de hosts y un grupo de máquinas virtuales.
2. Agregue reglas para limitar el grupo de máquinas virtuales en el grupo de hosts.
  
  Se utiliza un grupo de máquinas virtuales y un grupo de hosts para ejecutar la AZ en el clúster de carga de trabajo.
  
  Nota
  Las reglas de límite son solo para configuraciones de volúmenes locales. No es necesario crear reglas de límite si va a implementar en varias zonas de disponibilidad.
3. Implemente las definiciones de recursos personalizados (CRD) VSphereFailureDomain y VSphereDeploymentZone en el clúster de administración independiente.
  
  La zona de disponibilidad se asignará a una VSphereDeploymentZone y, a continuación, a un grupo de hosts en vSphere.

Agregar una nueva AZ. Puede agregar una nueva AZ mediante una configuración de superposición ytt o mediante la CLI de Tanzu.

ytt

A continuación, se muestra una configuración de superposición ytt en un clúster heredado y un clúster con clases.

Clúster heredado

#@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

Clúster con clases

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)

CLI de Tanzu

Puede crear una nueva AZ para admitir el aprovisionamiento de almacenamiento local con reconocimiento de topología mediante la CLI de Tanzu.

Clúster heredado

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"

Clúster con clases

Consulte Establecer (Crear) (Set [Create]) en la configuración de grupos de nodos para clústeres basados en ClusterClass.