Volúmenes persistentes y aprovisionamiento dinámico

En esta página, se proporciona una descripción general de las reclamaciones y los volúmenes persistentes en Kubernetes y su uso con Google Kubernetes Engine (GKE). Esta página se centra en el almacenamiento respaldado por los Discos persistentes de Compute Engine.

Volúmenes persistentes

Los recursos PersistentVolume se usan para administrar el almacenamiento duradero en un clúster. En GKE, un PersistentVolume suele estar respaldado por un disco persistente. También puedes usar otras soluciones de almacenamiento, como NFS. Filestore es una solución de NFS en Google Cloud. Si deseas obtener información sobre cómo configurar una instancia de Filestore como una solución de NFS PV para tus clústeres de GKE, consulta Accede a instancias de Filestore con el controlador de la CSI de Filestore en la documentación de Filestore.

Otra opción de almacenamiento es Cloud Volumes Service. Este producto es un servicio de almacenamiento de datos completamente administrado basado en la nube que proporciona capacidades avanzadas de administración de datos y un rendimiento altamente escalable.

Kubernetes administra el ciclo de vida de PersistentVolume. Un PersistentVolume se puede aprovisionar de forma dinámica. No necesitas crear y borrar manualmente el almacenamiento de copia de seguridad.

Los recursos PersistentVolume son recursos de clúster que existen de forma independiente de los pods. Esto significa que el disco y los datos representados por un PersistentVolume continúan existiendo a medida que el clúster cambia y los pods se borran y se vuelven a crear. Los recursos PersistentVolume se pueden aprovisionar de manera dinámica a través de PersistentVolumeClaims, o el administrador del clúster puede crearlos de manera explícita.

Para obtener más información sobre los recursos PersistentVolume, consulta la documentación de volúmenes persistentes de Kubernetes y la referencia de la API de volúmenes persistentes.

PersistentVolumeClaims

Una PersistentVolumeClaim es una solicitud y una reclamación de un recurso PersistentVolume. Los objetos PersistentVolumeClaim solicitan un tamaño específico, un modo de acceso y una StorageClass para PersistentVolume. Si existe un PersistentVolume que satisface la solicitud o se puede aprovisionar, PersistentVolumeClaim se vincula a ese PersistentVolume.

Los pods usan reclamaciones como volúmenes. El clúster inspecciona la reclamación a fin de encontrar el volumen vinculado y lo activa para el pod.

La portabilidad es otra ventaja de usar PersistentVolumes y PersistentVolumeClaims. Puedes usar la misma especificación de pod con facilidad en diferentes clústeres y entornos porque PersistentVolume es una interfaz para el almacenamiento de copia de seguridad real.

StorageClasses

Las implementaciones de volúmenes, como el controlador de la interfaz de almacenamiento de contenedores de discos persistentes (CSI) de Compute Engine, se configuran a través de los recursos StorageClass.

GKE crea un recurso StorageClass predeterminado para ti, que usa el tipo de disco persistente balanceado (ext4). El StorageClass predeterminado se usa cuando un PersistentVolumeClaim no especifica un StorageClassName. Puedes reemplazar el StorageClass predeterminado proporcionado por uno tuyo. Para obtener instrucciones, consulta Cambia el recurso StorageClass predeterminado.

Puedes crear tus propios recursos StorageClass para describir diferentes clases de almacenamiento. Por ejemplo, las clases pueden asignarse a niveles de calidad de servicio o a políticas de copia de seguridad. Este concepto a veces se llama "perfiles" en otros sistemas de almacenamiento.

Si usas un clúster con grupos de nodos de Windows, debes crear un StorageClass y especificar un StorageClassName en PersistentVolumeClaim porque el fstype predeterminado (ext4) no es compatible con Windows. Si usas un disco persistente de Compute Engine, debes usar NTFS como el tipo de almacenamiento de archivos.

Cuando defines un StorageClass, debes enumerar un aprovisionador. En GKE, te recomendamos que uses uno de los siguientes aprovisionadores:

Aprovisiona de forma dinámica los PersistentVolumes

La mayoría de las veces, no necesitas configurar directamente objetos PersistentVolume ni crear discos persistentes de Compute Engine. En su lugar, puedes crear un PersistentVolumeClaim, y Kubernetes aprovisionará automáticamente un disco persistente para ti.

En el siguiente manifiesto, se describe una solicitud de un disco con 30 gibibytes (GiB) de almacenamiento cuyo modo de acceso permite que un solo nodo lo active como de lectura y escritura. También crea un Pod que consume PersistentVolumeClaim como un volumen.

# pvc-pod-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
  storageClassName: standard-rwo
---
kind: Pod
apiVersion: v1
metadata:
  name: pod-demo
spec:
  volumes:
    - name: pvc-demo-vol
      persistentVolumeClaim:
       claimName: pvc-demo
  containers:
    - name: pod-demo
      image: nginx
      resources:
        limits:
          cpu: 10m
          memory: 80Mi
        requests:
          cpu: 10m
          memory: 80Mi
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: pvc-demo-vol

Cuando creas este objeto PersistentVolumeClaim con kubectl apply -f pvc-pod-demo.yaml, Kubernetes crea de forma dinámica un objeto PersistentVolume correspondiente.

Debido a que la clase de almacenamiento standard-rwo usa el modo de vinculación de volumen WaitForFirstConsumer, el PersistentVolume no se creará hasta que se programe un Pod para consumir el volumen.

En el siguiente ejemplo, se muestra el PersistentVolume creado.

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: pd.csi.storage.gke.io
  finalizers:
  - kubernetes.io/pv-protection
  - external-attacher/pd-csi-storage-gke-io
  name: pvc-c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  uid: d52af557-edf5-4f96-8e89-42a3008209e6
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 30Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: pvc-demo
    namespace: default
    uid: c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  csi:
    driver: pd.csi.storage.gke.io
    csi.storage.k8s.io/fstype: ext4
    volumeAttributes:
      storage.kubernetes.io/csiProvisionerIdentity: 1660085000920-8081-pd.csi.storage.gke.io
    volumeHandle: projects/xxx/zones/us-central1-c/disks/pvc-c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.gke.io/zone
          operator: In
          values:
          - us-central1-c
  persistentVolumeReclaimPolicy: Delete
  storageClassName: standard-rwo
  volumeMode: Filesystem
status:
  phase: Bound

Si no reemplazaste la clase de almacenamiento standard-rwo, este PersistentVolume está respaldado por un nuevo disco persistente de Compute Engine que está vacío.

Borra el almacenamiento persistente

De forma predeterminada, si borras una PersistentVolumeClaim para volúmenes aprovisionados de forma dinámica, como los discos persistentes de Compute Engine, se borrará el objeto PersistentVolume y el disco de respaldo real. La política de recuperación controla este comportamiento en StorageClass y PersistentVolume, que se puede establecer en el valor predeterminado de Delete o Retain. Para obtener más información, consulta la documentación de Kubernetes sobre Reclamaciones.

Para evitar o mitigar la pérdida de datos cuando borras el almacenamiento persistente, te recomendamos habilitar la Copia de seguridad para GKE y programar copias de seguridad periódicas del clúster de GKE. incluidas las cargas de trabajo implementadas y sus datos.

Administra el almacenamiento persistente durante la eliminación del clúster

Cuando se borra un clúster de GKE, GKE retiene recursos PersistentVolume con la política de reclamación Delete o Retain.

Para quitar los recursos PersistentVolume cuando borras un clúster, puedes borrar de forma manual el espacio de nombres de los recursos PersistentVolumeClaim, lo que activará la eliminación de los objetos PersistentVolume con la política Delete. También puedes borrar recursos individuales PersistentVolumeClaim. Sin embargo, GKE no espera antes de que se completen estas actividades de eliminación antes de comenzar a borrar el clúster. Por lo tanto, si borras un espacio de nombres y borras el clúster de inmediato, es posible que los recursos PersistentVolume con políticas Delete no se borren.

Después de borrar el clúster, puedes ver los recursos PersistentVolume restantes en la consola de Google Cloud.

Para ver los recursos que no se usan, como los recursos PersistentVolume sin usar, puedes ver las recomendaciones de los recursos inactivos.

Modos de acceso

Los recursos PersistentVolume admiten los siguientes modos de acceso:

  • ReadWriteOnce: Un solo nodo puede activar el volumen como de lectura y escritura.
  • ReadOnlyMany: Muchos nodos pueden activar el volumen como de solo lectura.
  • ReadWriteMany: Muchos nodos pueden activar el volumen como de lectura y escritura. Los recursos PersistentVolume respaldados por discos persistentes de Compute Engine no son compatibles con este modo de acceso.

Usa los discos persistentes de Compute Engine como ReadOnlyMany

ReadWriteOnce es el caso práctico más habitual de discos persistentes y funciona como modo de acceso predeterminado para la mayoría de las aplicaciones. Los discos persistentes de Compute Engine también admiten el modo ReadOnlyMany para que muchas aplicaciones o muchas réplicas de la misma aplicación puedan consumir el mismo disco al mismo tiempo. Un caso práctico de ejemplo es la entrega de contenido estático en varias réplicas.

Para obtener instrucciones, consulta Usa discos persistentes con múltiples lectores.

Usa discos persistentes preexistentes como PersistentVolumes

Los recursos PersistentVolume aprovisionados de manera dinámica están vacíos cuando se crean. Si tienes un disco persistente de Compute Engine existente propagado con datos, puedes ingresarlo en tu clúster mediante la creación manual de un recurso PersistentVolume correspondiente. El disco persistente debe estar en la misma zona que los nodos del clúster.

Consulta este ejemplo de cómo crear un Persistent Volume respaldado por un disco persistente preexistente.

Comparación entre implementaciones y StatefulSets

Puedes usar PersistentVolumeClaim o plantillas de VolumeClaim en controladores de nivel superior, como objetos Deployment o StatefulSet, respectivamente.

Los objetos Deployment están diseñados para aplicaciones sin estado , por lo que todas las réplicas de un Deployment comparten el mismo PersistentVolumeClaim. Dado que los pods de réplica que se crean son idénticos, solo los volúmenes con el modo ReadWriteMany pueden funcionar en esta configuración.

Incluso los objetos Deployment con una réplica que usan un volumen en modo ReadWriteOnce no son recomendables. Esto se debe a que la estrategia de Deployment predeterminada crea un segundo pod antes de reducir el primer pod en una recreación. El proceso de Deployment puede fallar en un interbloqueo, ya que el segundo pod no puede iniciarse porque el volumen en modo ReadWriteOnce ya está en uso, y el primer pod no se quitará porque el segundo pod aún no se inició. En su lugar, usa un StatefulSet con volúmenes en modo ReadWriteOnce.

Los StatefulSets son el método recomendado para implementar aplicaciones con estado que requieren un solo volumen por réplica. Cuando usas StatefulSets con las plantillas de PersistentVolumeClaim, puedes tener aplicaciones que se pueden escalar verticalmente de forma automática con un solo objeto PersistentVolumesClaim asociado a cada pod de réplica.

Discos persistentes regionales

Los discos persistentes regionales son recursos multizonales que replican datos entre dos zonas en la misma región y se pueden usar de manera similar a los discos persistentes zonales. En el caso de una interrupción zonal o si los nodos de clúster en una zona se vuelven no programables, Kubernetes puede conmutar por error las cargas de trabajo con el volumen en la otra zona. Puedes usar discos persistentes regionales a fin de crear soluciones con alta disponibilidad para cargas de trabajo con estado en GKE. Debes asegurarte de que la zona principal y la de conmutación por error estén configuradas con suficiente capacidad de recursos para ejecutar la carga de trabajo.

Los discos persistentes SSD regionales son una opción para aplicaciones como las bases de datos que requieren alta disponibilidad y alto rendimiento. Para obtener más detalles, consulta la Comparación de rendimiento de almacenamiento en bloque.

Al igual que sucede con los discos persistentes zonales, los discos persistentes regionales se pueden aprovisionar de manera dinámica según sea necesario, o bien el administrador del clúster puede aprovisionarlos de forma manual por adelantado. Para obtener información sobre cómo agregar discos persistentes regionales, consulta Aprovisiona discos persistentes regionales.

Zonas en discos persistentes

Los discos persistentes zonales son recursos zonales y los discos persistentes regionales son recursos multizonales. Cuando agregas almacenamiento continuo a tu clúster, GKE asigna el disco a una zona de forma automática, a menos que especifiques una. GKE selecciona la zona de forma aleatoria. Cuando se aprovisiona un disco persistente, los pods que hagan referencia a él se programan en la misma zona donde este se encuentre. Sin embargo, los Pods o las implementaciones no reconocen de manera inherente la zona de los discos persistentes preexistentes. Para asegurarte de que los Pods se programen de forma correcta con discos persistentes preexistentes, usa métodos de ubicación zonal, como nodeAffinity en tu Pod o Deployment. las especificaciones para orientar las zonas adecuadas.

Modo de vinculación de volumen waitForFirstConsumer

Si aprovisionas de forma dinámica un disco persistente en tu clúster, te recomendamos configurar el modo de vinculación de volumen WaitForFirstConsumer en tu StorageClass. Esta configuración le indica a Kubernetes que aprovisione un disco persistente en la misma zona en la que se programa el pod. Se respetan las restricciones de programación de pods, como la antiafinidad y los selectores de nodos. La antiafinidad en las zonas permite que los pods de StatefulSet se distribuyan entre las zonas junto con los discos correspondientes.

A continuación, se muestra un StorageClass de ejemplo para aprovisionar discos persistentes zonales en el que se configura WaitForFirstConsumer:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  csi.storage.k8s.io/fstype: ext4
volumeBindingMode: WaitForFirstConsumer

Para ver un ejemplo con discos persistentes regionales, consulta Aprovisiona discos persistentes regionales.

¿Qué sigue?