En esta página, se explican los conceptos de almacenamiento de Google Distributed Cloud (solo software) para VMware.
Resumen
Google Distributed Cloud se integra en sistemas de almacenamiento de archivos o bloques externos a través de los siguientes elementos:
- El controlador de Container Storage Interface (CSI) de vSphere
- Controladores de CSI de terceros
- Complementos de volumen de árbol de Kubernetes
Almacenes de datos de vSphere
Cuando creas un clúster de administrador, especificas un almacén de datos de vSphere existente para los datos de etcd del clúster.
Cuando creas un clúster de usuario, puedes usar el mismo almacén de datos que el clúster de administrador o especificar uno diferente. También puedes especificar almacenes de datos para grupos de nodos individuales.
Los almacenes de datos de vSphere que usan los clústeres de administrador y de usuario pueden estar respaldados por NFS, vSAN o VMFS en un dispositivo de almacenamiento en bloques, como un array de almacenamiento externo. En un entorno de varios hosts, cada dispositivo de almacenamiento en bloques se debe adjuntar a todos los hosts del entorno, y el almacén de datos debe configurarse en cada host a través de la opción Mount Datastore on Additional Hosts (Activar el almacén de datos en los hosts adicionales).
StorageClasses
Cuando creas un PersistentVolumeClaim, puedes especificar una StorageClass que proporcione información sobre cómo se aprovisionará el almacenamiento. Si no especificas una StorageClass, se usa la StorageClass predeterminada.
StorageClass del clúster de administrador
En los clústeres de administrador, hay una StorageClass llamada standard, y se designa como la StorageClass predeterminada. La StorageClass standard enumera el complemento de volumen en árbol de vSphere como el aprovisionador.
Para ver la StorageClass standard, haz lo siguiente:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get storageclass \
standard --output yaml
En el resultado, puedes ver que standard es la StorageClass predeterminada y que el aprovisionador es el complemento de volumen en árbol de vSphere, kubernetes.io/vsphere-volume. También puedes ver el nombre de un almacén de datos de vSphere.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
storageclass.kubernetes.io/is-default-class: "true"
...
labels:
bundle.gke.io/component-name: admin-storage-class
name: standard
...
parameters:
datastore: vsanDatastore
provisioner: kubernetes.io/vsphere-volume
...
StorageClasses de clústeres de usuario
En los clústeres de usuarios, hay una StorageClass llamada standard y otra llamada standard-rwo.
El StorageClass standard-rwo se designa como el StorageClass predeterminado y enumera el controlador de CSI de vSphere como el aprovisionador.
Para ver la StorageClass standard-rwo, haz lo siguiente:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get storageclass \
standard-rwo --output yaml
En el resultado, puedes ver que standard-rwo es el StorageClass predeterminado y que el aprovisionador es el controlador de CSI de vSphere, csi.vsphere.vmware.com. También puedes ver la URL de un almacén de datos de vSphere:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
storageclass.kubernetes.io/is-default-class: "true"
...
labels:
bundle.gke.io/component-name: user-vsphere-csi-driver-addon
...
name: standard-rwo
...
parameters:
datastoreURL: ds:///vmfs/volumes/vsan:52fb6ca22be2454e-e67f620175964a9f/
provisioner: csi.vsphere.vmware.com
...
Complementos de volumen de árbol de Kubernetes
Kubernetes se entrega con cierta cantidad de complementos de volumen en árbol. Sin embargo, la mayoría de estos complementos de volumen integrados están obsoletos (incluido el complemento de volumen integrado de vSphere). Para obtener más información, consulta el proyecto de migración de CSI.
Migración de CSI para el controlador de almacenamiento de vSphere
En el pasado, el complemento de volumen de vSphere integrado era el aprovisionador de la StorageClass predeterminada en los clústeres de usuarios. Sin embargo, ahora el complemento de volumen de vSphere en el árbol está en desuso, y el controlador de CSI de vSphere es el aprovisionador de la StorageClass predeterminada en los clústeres de usuario. Te recomendamos que uses el controlador CSI de vSphere en lugar del complemento de volumen integrado.
A partir de la versión 1.15 de Google Distributed Cloud, la función de migración de CSI de Kubernetes está habilitada de forma predeterminada para el complemento de volumen de vSphere integrado. Esto significa que, si una carga de trabajo usa un volumen de vSphere en el árbol, todas las llamadas internas a las operaciones de almacenamiento se redireccionan automáticamente al controlador de CSI de vSphere.
Por ejemplo, supongamos que un PersistentVolumeClaim especifica la StorageClass standard, que enumera el complemento de volumen integrado de vSphere, kubernetes.io/vsphere-volume, como el aprovisionador. Luego, cualquier carga de trabajo que use ese PersistentVolumeClaim tendrá sus llamadas de operaciones de almacenamiento redireccionadas al controlador de CSI de vSphere, csi.vsphere.vmware.com.
Verificaciones previas
Cuando creas o actualizas un clúster, se realizan verificaciones previas que garantizan que tu entorno sea adecuado para la migración de CSI.
Por ejemplo, las verificaciones de la solicitud preliminar hacen lo siguiente:
- Verifica que las versiones de vCenter y ESXI sean las adecuadas.
- Verifica que el controlador CSI de vSphere esté habilitado si hay PersistentVolumes de vSphere integrados en el árbol.
- Verifica que las StorageClasses de vSphere no tengan ciertos parámetros que se ignoran después de la migración de CSI.
- Verifica las anotaciones en los PersistentVolumes y PersistentVolumeClaims creados de forma estática en el árbol que se requieren para la migración a CSI.
- Verifica que el clúster pueda ejecutar correctamente una carga de trabajo con un volumen de CSI aprovisionado por el controlador de CSI de vSphere.
Para obtener más información, consulta Ejecuta verificaciones previas.
Problemas conocidos
Hay varios problemas conocidos relacionados con el controlador de CSI de vSphere. Para obtener información y soluciones alternativas, consulta la sección Problemas conocidos en las notas de la versión 3.0 del controlador de CSI de VMware vSphere.
Completa la migración a CSI
Con la función de migración de CSI de Kubernetes habilitada de forma predeterminada en la versión 1.15, el objeto PersistentVolume respaldado por el complemento de volumen de vSphere integrado en el árbol sigue funcionando en un entorno solo de CSI. Simplemente, redirecciona las llamadas de operación del complemento integrado en el árbol al complemento de CSI. Dado que la especificación PersistentVolume es inmutable, la especificación será la misma que la del complemento de volumen en árbol.
Debido a esto, el conjunto completo de atributos de CSI, como las funciones de expansión y de instantáneas de volumen, no está disponible para esos volúmenes. Para aprovechar estas funciones, la carga de trabajo con estado debe migrarse por completo a CSI. Para ello, se debe volver a crear la especificación de recursos de Kubernetes con campos de CSI. Desarrollamos herramientas automatizadas para ayudarte a migrar cargas de trabajo con estado a CSI sin tiempo de inactividad de la aplicación, lo que te permitirá usar el conjunto completo de funciones de CSI.
Usa controladores de terceros
Si deseas aprovisionar volúmenes de almacenamiento distintos de los almacenes de datos de vSphere, puedes crear una StorageClass nueva en un clúster que use un controlador de almacenamiento diferente. Luego, puedes establecer la StorageClass como la configuración predeterminada del clúster o configurar las cargas de trabajo para que usen la StorageClass (ejemplo de StatefulSet).
Soscios de almacenamiento
Nos asociamos con muchos proveedores de almacenamiento para calificar sus sistemas de almacenamiento con Google Distributed Cloud. Consulta la lista completa de socios de almacenamiento calificados.
Expansión de volumen
Puedes expandir el tamaño de un volumen persistente después de que se haya aprovisionado mediante la edición de la solicitud de capacidad en PersistentVolumeClaim. Puedes realizar una expansión en línea mientras un volumen está en uso mediante un pod, o una expansión sin conexión en la que el volumen no está en uso.
En el controlador de CSI de vSphere, la expansión sin conexión está disponible en las versiones 7.0 de vSphere y la expansión en línea está disponible en la actualización 2.0 de la versión 7.0.
La StorageClass standard-rwo establece allowVolumeExpansion como verdadero de forma predeterminada para los clústeres recién creados que se ejecutan en vSphere 7.0 o una versión posterior. Puedes usar la expansión en línea y sin conexión para los volúmenes que usan esta StorageClass. En un clúster actualizado, debido a que las StorageClass no se modifican en las actualizaciones de clústeres, cuando un clúster se actualiza de la versión 1.7 a la 1.8, el parámetro de configuración allowVolumeExpansion de standard-rwo permanece sin configurar, lo que significa que no se permite la expansión de volumen.
Para obtener más información sobre la expansión de volumen, consulta Usa la expansión de volumen.
Instantáneas del volumen de CSI
Puedes crear instantáneas de almacenamiento persistente con los recursos VolumeSnapshot y VolumeSnapshotClass. Para usar esta característica en un volumen de CSI, el controlador CSI debe admitir instantáneas de volumen, y el contenedor de archivo adicional external-snapshotter debe incluirse en la implementación del controlador CSI.
Para obtener más información sobre las instantáneas de volumen, consulta Usa instantáneas de volumen.
Los controladores de instantáneas CSI se implementan de forma automática cuando creas un clúster.
Limpieza de volumen
Cuando borras un clúster de usuario, no se borran los volúmenes aprovisionados por el controlador de CSI de vSphere. Debes borrar todos los volúmenes, PersistentVolumeClaims y StatefulSets antes de borrar el clúster.
Soluciona problemas
Consulta Soluciona problemas de almacenamiento.