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 lo siguiente:
- 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 datastore de vSphere existente para los datos 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 una PersistentVolumeClaim, puedes especificar una StorageClass que proporcione información sobre cómo se aprovisionará el almacenamiento. Si no especificas un StorageClass, se usa el StorageClass predeterminada.
StorageClass del clúster de administrador
En los clústeres de administrador, hay una StorageClass llamada standard, que se designa como la StorageClass predeterminada. El 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 StorageClass 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 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 en el árbol dejaron de estar disponibles (incluido el complemento de volumen integrado en el árbol 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 en el árbol 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 dejó de estar disponible, y el controlador de CSI de vSphere es el aprovisionador de la StorageClass predeterminada en los clústeres de usuarios. Te recomendamos que uses el controlador CSI de vSphere en lugar del complemento de volumen de árbol.
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 en el árbol. Esto significa que, si una carga de trabajo usa un volumen de vSphere en el árbol, todas las llamadas a operaciones de almacenamiento internas se redireccionan automáticamente al controlador CSI de vSphere.
Por ejemplo, supongamos que un PersistentVolumeClaim especifica la StorageClass standard, que enumera el complemento de volumen en el árbol de vSphere, kubernetes.io/vsphere-volume, como el aprovisionador. Luego, cualquier carga de trabajo que use esa PersistentVolumeClaim tendrá sus llamadas de operaciones de almacenamiento redireccionadas al controlador de CSI de vSphere, csi.vsphere.vmware.com.
Verificaciones previas
Cuando creas un clúster nuevo o actualizas uno existente, hay verificaciones previas que se aseguran de que tu entorno sea adecuado para la migración de CSI.
Por ejemplo, las comprobaciones previas realizan las siguientes acciones:
- Verifica que las versiones de vCenter y ESXi sean adecuadas.
- Verifica que el controlador de CSI de vSphere esté habilitado si hay PersistentVolumes de vSphere en el árbol.
- Verifica que las clases de almacenamiento 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 de 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 vSphere de VMware.
Completa la migración a CSI
Con la función de migración de CSI de Kubernetes habilitada de forma predeterminada en 1.15, el PersistentVolume respaldado por el complemento de volumen de vSphere en el árbol sigue funcionando en un entorno de solo CSI, solo redirecciona las llamadas de operación del complemento 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 una herramienta automatizada para ayudar a migrar la carga 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.