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).
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.
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
NotavSphere 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.4, todas las clases de almacenamiento predeterminadas utilizan el aprovisionamiento de almacenamiento externo ("fuera del árbol"), no el aprovisionamiento "en el árbol".
StorageClass
provisioner
no tienen el prefijo kubernetes.io
.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.
ImportanteNo modifique las definiciones de clases de almacenamiento predeterminadas. Para personalizar una clase de almacenamiento, cree una nueva definición de
StorageClass
con unname
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.
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:
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:
Use storage tagged with
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.
Los administradores de clústeres pueden crear una nueva clase de almacenamiento de la siguiente manera:
StorageClass
de Kubernetes.
StorageClass
.yaml
con provisioner
, parameters
y otras opciones.
storagePolicyName
en el nombre de la directiva de almacenamiento de vSphere, como una cadena de comillas dobles.kubectl create -f
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.
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.
kubectl get storageclass
.Cree una PVC y su PV:
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.kubectl create -f
kubectl describe pvc <pvc metadata.name>
para comprobar la PVC.kubectl describe pvc
después de Successfully provisioned volume
.kubectl describe pv <pv unique name>
para comprobar el PV.Cree un pod mediante la PVC:
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.kubectl create -f
kubectl get pod <pod metadata.name>
para comprobar el pod.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
.
NotaLa 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:
values.yaml
, que es una cadena larga.stringData
y aplique sangría en values.yaml
para convertirlo en el primer elemento.data.values
del paso anterior.data.values
y aplique sangría como el valor de values.yaml
.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 volúmenes de almacenamiento vSphere CSI en modo en línea o sin conexión, consulte Expansión de volumen en vSphere with Tanzu.
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 de Ejecutar clústeres en varias zonas de disponibilidad para crear lo siguiente en vSphere:
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.
NotaLas 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.
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
ytt
en un clúster heredado y un clúster con clases. Para obtener información sobre cómo descargar e instalar
ytt
, consulte
Instalar Carvel Tools.
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)
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.