Almacenamiento persistente en Kubernetes con CSI 2026

El ecosistema de Kubernetes ha madurado hasta convertirse en el estándar de facto para la orquestación de contenedores. Sin embargo, la gestión de datos que deben sobrevivir al ciclo de vida de un Pod sigue siendo uno de los desafíos más críticos. En 2026, el Container Storage Interface (CSI) se ha consolidado como la única vía sensata para implementar almacenamiento persistente, ofreciendo un nivel de abstracción, automatización y rendimiento que los controladores in-tree legacy ya no pueden igualar.

Este artículo técnico desglosa el estado del arte del almacenamiento persistente en Kubernetes con CSI, centrándose en volúmenes dinámicos, estrategias de alta disponibilidad datos y las mejores prácticas para operar clusters en producción a mediados de la década. Prepárate para una inmersión profunda en YAML, drivers y políticas de replicación.

El estado del CSI en 2026: Madurez y ecosistema

En 2026, el CSI no es una opción, es el estándar. La API de almacenamiento in-tree (como kubernetes.io/gce-pd o kubernetes.io/aws-ebs) ha sido completamente deprecada y eliminada del código base de Kubernetes a partir de la versión 1.28. Todos los proveedores de nube pública y soluciones on-premise han migrado sus controladores a drivers CSI.

La versión actual del CSI spec (1.10) introduce capacidades avanzadas como:

• Volume Group Snapshots: Permite crear snapshots consistentes de múltiples volúmenes simultáneamente.
• Reclaim Policy granular: Control sobre qué ocurre con los datos subyacentes al eliminar un PVC (Retain, Delete o Recycle).
• Topology-aware provisioning: El scheduler de Kubernetes puede decidir en qué nodo ubicar un Pod basándose en la disponibilidad del volumen, evitando migraciones innecesarias.

[INFO] Aunque el spec CSI es independiente del proveedor, cada driver puede implementar funcionalidades opcionales. En 2026, se espera que al menos el 90% de los drivers de producción soporten ExpandPersistentVolumes, BlockVolume y VolumeHealth.

Volúmenes dinámicos: El corazón del aprovisionamiento moderno

La clave para escalar el almacenamiento en Kubernetes es el aprovisionamiento dinámico. Ya no tiene sentido crear PersistentVolumes (PV) manualmente. En su lugar, se definen StorageClass que actúan como plantillas de configuración.

Cómo funciona el aprovisionamiento dinámico con CSI

El flujo es el siguiente:

1. El usuario crea un PersistentVolumeClaim (PVC) que referencia una StorageClass.
2. El external-provisioner (sidecar del driver CSI) detecta el PVC y llama a la API del driver (CreateVolume).
3. El backend de almacenamiento (por ejemplo, un array NetApp, Ceph RBD o un disco en AWS) crea el volumen real.
4. Se genera un PV vinculado automáticamente al PVC.

Ejemplo de una StorageClass para un backend CSI de Ceph RBD (Rook):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-rbd-sc
provisioner: rook-ceph.rbd.csi.ceph.com
parameters:
  clusterID: rook-ceph
  pool: replicapool
  imageFormat: "2"
  imageFeatures: layering
  csi.storage.k8s.io/fstype: ext4
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

Características clave de esta StorageClass:

• allowVolumeExpansion: true: Permite redimensionar el volumen sin downtime.
• volumeBindingMode: WaitForFirstConsumer: El volumen se crea solo cuando un Pod lo solicita, optimizando la topología.
• reclaimPolicy: Delete: Al eliminar el PVC, el volumen subyacente se destruye automáticamente.

Beneficios de los volúmenes dinámicos en 2026

• Automatización total: Sin intervención manual para crear/eliminar volúmenes.
• Eficiencia de costes: Los volúmenes solo existen mientras los PVCs están activos.
• Integración con GitOps: Los manifiestos YAML definen el estado deseado del almacenamiento, y ArgoCD o Flux se encargan del resto.

[WARNING] Nunca uses reclaimPolicy: Retain en entornos de desarrollo a menos que tengas una política de limpieza automática. Los volúmenes huérfanos pueden disparar los costes en la nube.

Alta disponibilidad de datos con CSI: Estrategias probadas

La alta disponibilidad datos en Kubernetes no es trivial. Un Pod puede morir, un nodo puede fallar o una zona de disponibilidad completa puede caer. CSI, combinado con las características de Kubernetes, ofrece varias estrategias para garantizar que los datos sobrevivan y sigan accesibles.

1. Replicación a nivel de backend

La mayoría de los drivers CSI modernos (como Rook/Ceph, Longhorn, Portworx o NetApp Trident) soportan replicación síncrona o asíncrona directamente en el backend.

Ejemplo con Rook Ceph (pool replicado):

# Crear un pool con replicación 3x
ceph osd pool create replicapool 128 128 replicated
ceph osd pool set replicapool size 3
ceph osd pool set replicapool min_size 2

El driver CSI de Rook expone este pool como una StorageClass. Si un OSD (disco) falla, los datos siguen disponibles en las otras dos réplicas.

2. Topology Constraints y Failure Domains

Kubernetes permite etiquetar nodos con topology.kubernetes.io/zone y topology.kubernetes.io/region. Los drivers CSI pueden usar estas etiquetas para distribuir las réplicas entre diferentes zonas.

Para habilitarlo, la StorageClass debe incluir:

allowedTopologies:
- matchLabelExpressions:
  - key: topology.kubernetes.io/zone
    values:
    - us-east-1a
    - us-east-1b
    - us-east-1c

De esta forma, si falla toda una zona de disponibilidad, el volumen sigue siendo accesible desde las otras zonas.

3. ReadWriteMany (RWX) con CSI

Históricamente, el acceso RWX era complejo y requería NFS o soluciones propietarias. En 2026, los drivers CSI han madurado para ofrecer RWX nativo.

• CephFS: Soporta RWX de forma nativa a través del driver CSI de Ceph.
• Longhorn: Ofrece RWX mediante un bloque compartido con NFSv4.
• Portworx: Proporciona RWX con consistencia distribuida.

Ejemplo de PVC RWX con CephFS:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-data-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi
  storageClassName: csi-cephfs-sc

4. Snapshot y Restore para DR

Los snapshots son la base de cualquier plan de recuperación ante desastres. CSI permite crear VolumeSnapshot y VolumeSnapshotContent de forma estándar.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: db-snapshot-2026
spec:
  volumeSnapshotClassName: csi-rbd-snapclass
  source:
    persistentVolumeClaimName: postgres-data-pvc

Luego, se puede restaurar creando un PVC a partir del snapshot:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-restore-pvc
spec:
  dataSource:
    name: db-snapshot-2026
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  storageClassName: csi-rbd-sc

[TIP] Programa snapshots periódicos con VolumeSnapshotClass y un cronJob de Kubernetes. Herramientas como Velero pueden orquestar snapshots a nivel de aplicación.

Drivers CSI recomendados para 2026

No todos los drivers son iguales. Aquí tienes una comparativa de los más robustos para producción:

Driver	Tipo	Replicación	RWX	Ideal para
Rook/Ceph (RBD + CephFS)	Bloque y Fichero	Síncrona (3x)	Sí (CephFS)	On-premise, clouds híbridas
Longhorn	Bloque distribuido	Síncrona (3x)	Sí (NFS)	Edge, clusters pequeños
Portworx	Bloque y Fichero	Síncrona/Asíncrona	Sí	Enterprise, bases de datos
AWS EBS CSI	Bloque	Snapshots cross-AZ	No	AWS nativo
Azure Disk CSI	Bloque	LRS/ZRS	No	Azure nativo
GCE Persistent Disk CSI	Bloque	Regional PD	No	GCP nativo
NetApp Trident	Bloque y Fichero	SnapVault	Sí	Entornos SAN/NAS existentes

Criterios de selección para 2026

1. Soporte de la comunidad: Prefiere drivers con más de 5000 estrellas en GitHub y releases estables.
2. Rendimiento: Prueba con fio dentro del Pod para validar IOPS y latencia.
3. Seguridad: El driver debe soportar encriptación en reposo y en tránsito.
4. Integración con Kubernetes: Compatibilidad con la última versión de Kubernetes (1.30+).

Operaciones avanzadas: Resizing, snapshots y backups

Redimensionar volúmenes en caliente

Con allowVolumeExpansion: true en la StorageClass, puedes aumentar el tamaño de un PVC editando el manifest:

kubectl edit pvc postgres-data-pvc
# Cambiar spec.resources.requests.storage de 100Gi a 200Gi

El driver CSI redimensionará el volumen subyacente y el sistema de ficheros se expandirá automáticamente (si el filesystem lo soporta).

Clonación de volúmenes

CSI permite clonar un PVC existente sin pasar por snapshots intermedios:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: clone-of-pvc
spec:
  dataSource:
    name: original-pvc
    kind: PersistentVolumeClaim
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  storageClassName: csi-rbd-sc

Esto es útil para crear entornos de staging a partir de producción.

Backup consistente con Velero

Velero (ahora parte de la CNCF) se integra nativamente con CSI para hacer backups de volúmenes sin agente dentro del Pod:

velero backup create app-backup --include-namespaces production --snapshot-volumes --use-volume-snapshots=true

En 2026, Velero soporta CSI Data Movers, que permiten mover los datos del snapshot a un bucket S3 sin necesidad de un volumen intermedio.

Resolución de problemas comunes con CSI en 2026

A pesar de la madurez, siempre surgen problemas. Aquí los más frecuentes y cómo solucionarlos:

El PVC se queda en estado Pending

kubectl describe pvc <nombre>

Causas comunes:

• La StorageClass no existe o está mal escrita.
• El driver CSI no está desplegado o no responde.
• No hay nodos que cumplan con las allowedTopologies.
• Cuota de almacenamiento excedida en el backend.

Solución: Verifica los logs del provisioner:

kubectl logs -n csi-driver <pod-del-provisioner> --tail=50

El Pod no arranca por problemas de montaje

kubectl describe pod <nombre>

Causas:

• El nodo no tiene el driver CSI instalado (módulo del kernel o paquete).
• El volumen está siendo usado por otro Pod en modo ReadWriteOnce.
• El filesystem está corrupto.

Solución: Verifica los logs del node-driver-registrar y del CSI node plugin:

kubectl logs -n csi-driver <pod-del-node-plugin> --tail=50

[WARNING] No ignores los eventos de VolumeFailedMount. Pueden indicar problemas de red entre el nodo y el backend de almacenamiento.

El futuro inmediato: CSI y Kubernetes en 2027

Mirando hacia adelante, el CSI seguirá evolucionando. Las tendencias para 2027 incluyen:

• CSI Ephemeral Volumes: Volúmenes que se crean y destruyen con el Pod, ideales para datos de caché o temporales.
• Integración con Service Mesh: Control de acceso a volúmenes basado en identidad de Pod (SPIFFE).
• Machine Learning nativo: Volúmenes optimizados para GPUs y acceso paralelo (RWX con alta IOPS).

El almacenamiento persistente ya no es un punto débil en Kubernetes. Con CSI, los administradores de sistemas tienen un control total sobre la alta disponibilidad datos, la automatización y el rendimiento. La clave está en elegir el driver adecuado, diseñar StorageClasses con criterio y monitorizar constantemente la salud del backend.

Conclusión

El año 2026 marca la consolidación definitiva de CSI como el estándar para el almacenamiento persistente en Kubernetes. Los días de los controladores in-tree han quedado atrás, y la flexibilidad de los volúmenes dinámicos, junto con las capacidades de replicación y snapshots, permiten construir sistemas de almacenamiento con una alta disponibilidad datos que antes solo era posible con hardware enterprise.

Para cualquier SysAdmin que gestione clusters en producción, dominar CSI ya no es opcional: es una habilidad fundamental. Desde la definición de una StorageClass hasta la depuración de un montaje fallido, cada aspecto del ciclo de vida del almacenamiento está ahora en manos del operador de Kubernetes.

¿Tu cluster ya está usando drivers CSI en 2026? Si no, estás perdiendo automatización, resiliencia y rendimiento.