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 PV de NFS para tus clústeres de GKE, consulta Accede a archivos compartidos desde los clústeres de Google Kubernetes Engine 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. Si deseas ver ejemplos, consulta Cloud Volumes Service para Google Cloud.

A diferencia de lo que sucede con los volúmenes, el ciclo de vida de PersistentVolume es administrado por Kubernetes. 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 Kubernetes.

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 gcePersistentDisk, se configuran a través de recursos StorageClass.

GKE crea un recurso StorageClass predeterminado para ti, que usa el tipo de disco persistente estándar (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:

Aprovisionamiento dinámico de 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 de 30 gigabytes (GiB) cuyo modo de acceso permite que un solo nodo lo active como de lectura y escritura:

# pvc-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi

Cuando creas este objeto PersistentVolumeClaim con kubectl apply -f pvc-demo.yaml, Kubernetes crea de forma dinámica un objeto PersistentVolume correspondiente. En el siguiente ejemplo, se muestra el PersistentVolume creado.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pvc-cd3fd5e9-695a-11ea-a3da-42010a800003
  uid: ced478c1-695a-11ea-a3da-42010a800003
  annotations:
    kubernetes.io/createdby: gce-pd-dynamic-provisioner
    pv.kubernetes.io/bound-by-controller: "yes"
    pv.kubernetes.io/provisioned-by: kubernetes.io/gce-pd
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 30Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: pvc-demo
    uid: cd3fd5e9-695a-11ea-a3da-42010a800003
  gcePersistentDisk:
    fsType: ext4
    pdName: gke-cluster-1-pvc-cd3fd5e9-695a-11ea-a3da-42010a800003
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.kubernetes.io/zone
          operator: In
          values:
          - us-central1-c
        - key: topology.kubernetes.io/region
          operator: In
          values:
          - us-central1
  persistentVolumeReclaimPolicy: Delete
  storageClassName: standard
  volumeMode: Filesystem
status:
  phase: Bound

Si no reemplazaste la clase de almacenamiento predeterminada de GKE, este PersistentVolume está respaldado por un nuevo disco persistente de Compute Engine que está vacío. Debes usar este disco en un pod mediante el uso de la reclamación como un volumen. Cuando borras una reclamación, también se borran el objeto PersistentVolume correspondiente y el disco persistente de Compute Engine aprovisionado.

Si deseas evitar la eliminación de discos persistentes aprovisionados de forma dinámica, establece la política de recuperación del recurso PersistentVolume o su recurso StorageClass en Retain. En este caso, se te cobrará por el disco persistente durante el tiempo que exista, incluso si no hay PersistentVolumeClaim que lo consuma. Para ver ejemplos sobre cómo cambiar la política de reclamo, consulta Cambia la política de reclamo de un PersistentVolume. y Recurso StorageClass.

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.

Consulta este artículo a fin de obtener instrucciones sobre cómo crear discos persistentes para varios 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.

Deployments 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 modos ReadOnlyMany o 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.

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: kubernetes.io/gce-pd
parameters:
  type: pd-standard
  fstype: ext4
volumeBindingMode: WaitForFirstConsumer

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

¿Qué sigue?