Introducción
Microsoft ha anunciado la disponibilidad de Azure Container Storage v2.1.0, una versión centrada en mejorar el uso de almacenamiento persistente para cargas de trabajo en contenedores sobre Azure.
Las dos novedades más relevantes del anuncio son:
- Soporte para Azure Elastic SAN como opción de almacenamiento en bloque.
- Almacenamiento bajo demanda, orientado a reducir la necesidad de preaprovisionar capacidad de forma manual antes de que las aplicaciones la necesiten.
Azure Container Storage está pensado para escenarios de Kubernetes, especialmente en entornos donde los equipos necesitan gestionar volúmenes persistentes para aplicaciones stateful con una experiencia más integrada en Azure.
Conviene, no obstante, separar el mensaje comercial de las decisiones de arquitectura: estas capacidades pueden ser muy útiles, pero no sustituyen automáticamente a otras opciones como Azure Disks, Azure Files o soluciones de almacenamiento gestionadas específicas para bases de datos. La elección debe depender del patrón de acceso, los requisitos de rendimiento, la disponibilidad regional, el coste y el modelo operativo del equipo.
Qué es Azure Container Storage
Azure Container Storage es un servicio de Azure orientado a la administración, aprovisionamiento y orquestación de almacenamiento para contenedores. Su objetivo es facilitar el uso de almacenamiento persistente en clústeres de Kubernetes, integrándose con los mecanismos habituales del ecosistema, como StorageClass, PersistentVolume y PersistentVolumeClaim.
En términos prácticos, ayuda a los equipos de plataforma a proporcionar almacenamiento a las aplicaciones sin que cada equipo de desarrollo tenga que gestionar manualmente todos los detalles de infraestructura subyacente.
Los casos habituales incluyen:
- Aplicaciones stateful desplegadas en Kubernetes.
- Bases de datos o motores de mensajería ejecutados dentro del clúster, cuando ese patrón sea apropiado.
- Procesamiento de datos con necesidad de volúmenes persistentes.
- Plataformas internas que requieren aprovisionamiento repetible de almacenamiento para múltiples equipos.
Novedad principal: soporte para Azure Elastic SAN
Azure Elastic SAN es un servicio de almacenamiento en bloque de Azure diseñado para ofrecer capacidad y rendimiento de forma agregada a través de una SAN gestionada. Su integración con Azure Container Storage permite utilizar Elastic SAN como backend para volúmenes persistentes en escenarios de contenedores.
Esto resulta especialmente relevante para organizaciones que buscan una alternativa más centralizada para administrar almacenamiento en bloque en cargas Kubernetes.
Qué aporta Elastic SAN en este contexto
El soporte de Elastic SAN en Azure Container Storage puede aportar ventajas en varios frentes:
-
Gestión centralizada de capacidad
Elastic SAN permite agrupar capacidad de almacenamiento en una entidad gestionada. Para equipos de plataforma, esto puede simplificar la administración frente a modelos donde cada volumen se trata de forma completamente aislada.
-
Almacenamiento en bloque para cargas stateful
Muchas aplicaciones stateful requieren almacenamiento en bloque con semánticas predecibles. Elastic SAN se posiciona como una opción para este tipo de necesidades dentro del ecosistema Azure.
-
Escalabilidad operativa
En entornos con múltiples aplicaciones o namespaces que requieren volúmenes persistentes, disponer de una capa de almacenamiento más centralizada puede facilitar la operación, siempre que el diseño de cuotas, rendimiento y aislamiento esté bien definido.
-
Alineación con patrones empresariales
Organizaciones acostumbradas a modelos SAN en entornos tradicionales pueden encontrar en Elastic SAN un punto de transición más natural hacia Kubernetes, manteniendo un enfoque de almacenamiento en bloque gestionado.
Almacenamiento bajo demanda
La segunda novedad destacada es el almacenamiento bajo demanda. La idea es permitir que el almacenamiento se aprovisione de forma más dinámica cuando las aplicaciones lo solicitan, en lugar de requerir que toda la capacidad se defina de antemano.
En Kubernetes, este patrón suele estar asociado al uso de PersistentVolumeClaim: una aplicación declara que necesita un volumen con determinadas características y el plano de almacenamiento se encarga de aprovisionarlo según la clase de almacenamiento configurada.
Con Azure Container Storage v2.1.0, Microsoft refuerza este modelo para facilitar escenarios donde la demanda de almacenamiento cambia con el tiempo.
Qué problemas ayuda a resolver
El almacenamiento bajo demanda puede ser útil cuando:
- La capacidad necesaria no se conoce con precisión al desplegar la aplicación.
- Existen múltiples equipos creando entornos de forma frecuente.
- Se necesita reducir el trabajo manual del equipo de plataforma.
- Las cargas stateful crecen de forma progresiva.
- Se quiere evitar el sobredimensionamiento inicial de capacidad.
Esto no significa que el coste desaparezca ni que no sea necesario planificar. La capacidad, el rendimiento, las operaciones de entrada/salida y la replicación siguen teniendo impacto económico y técnico. Lo que cambia es el modelo operativo: el aprovisionamiento puede adaptarse mejor al ciclo de vida real de las aplicaciones.
Diferencia entre aprovisionamiento dinámico y diseño de almacenamiento
Es importante no confundir dos conceptos:
- Aprovisionamiento dinámico: Kubernetes crea volúmenes en respuesta a solicitudes de las aplicaciones.
- Diseño de almacenamiento: decisiones sobre rendimiento, disponibilidad, aislamiento, backup, seguridad, cifrado, cuotas y coste.
Azure Container Storage v2.1.0 puede facilitar el primer punto, pero el segundo sigue siendo responsabilidad de arquitectura.
Antes de adoptar Elastic SAN o almacenamiento bajo demanda en producción, conviene revisar:
- Regiones disponibles.
- Compatibilidad con la versión del clúster.
- Límites de capacidad y rendimiento.
- Requisitos de red.
- Modelo de identidad y permisos.
- Estrategia de backup y recuperación.
- Comportamiento ante escalado, reinicios y actualizaciones.
- Coste total, incluyendo capacidad provisionada y operaciones asociadas.
Escenarios donde puede encajar
1. Plataformas Kubernetes multi-equipo
En organizaciones donde varios equipos despliegan aplicaciones stateful sobre AKS, Azure Container Storage puede ayudar a estandarizar el aprovisionamiento de volúmenes persistentes.
Elastic SAN puede actuar como una opción de almacenamiento en bloque para esos equipos, mientras que el aprovisionamiento bajo demanda reduce la fricción operativa.
2. Procesamiento de datos
Workloads de procesamiento de datos, pipelines internos o sistemas que generan volúmenes intermedios pueden beneficiarse de un modelo donde el almacenamiento se aprovisiona cuando la aplicación lo solicita.
En estos escenarios, la decisión debe validar cuidadosamente el rendimiento esperado: throughput, IOPS, latencia y concurrencia real de acceso.
3. Aplicaciones stateful en contenedores
Aunque no todas las bases de datos deberían ejecutarse dentro de Kubernetes, hay casos donde tiene sentido: entornos controlados, plataformas internas, productos empaquetados o workloads con requisitos específicos.
Para este tipo de aplicaciones, contar con una opción de almacenamiento en bloque gestionado puede simplificar parte de la operación.
4. Entornos de desarrollo y pruebas
El almacenamiento bajo demanda es especialmente atractivo en entornos donde se crean y destruyen recursos con frecuencia. Permite reducir tareas manuales y alinear mejor el ciclo de vida del almacenamiento con el de los despliegues.
Aun así, es recomendable aplicar políticas de limpieza y control de costes para evitar volúmenes huérfanos o capacidad no utilizada.
Recomendaciones de adopción
Antes de llevar Azure Container Storage v2.1.0 con Elastic SAN a producción, es recomendable seguir una adopción progresiva.
1. Validar compatibilidad
Comprueba que la región, la versión del clúster y la configuración de AKS son compatibles con las capacidades que quieres usar. No todas las características de Azure están disponibles en todas las regiones ni en todas las combinaciones de versión.
2. Probar con una carga representativa
No basta con crear un volumen y comprobar que monta correctamente. La prueba debe incluir:
- Escrituras sostenidas.
- Lecturas concurrentes.
- Reinicio de pods.
- Reprogramación de pods en otros nodos.
- Escalado de réplicas, si aplica.
- Comportamiento ante fallos.
- Limpieza de volúmenes al eliminar la aplicación.
3. Definir clases de almacenamiento por perfil
En lugar de ofrecer una única opción genérica, suele ser mejor definir perfiles de almacenamiento según necesidad:
- Desarrollo y pruebas.
- Producción estándar.
- Producción con mayor rendimiento.
- Cargas sensibles a latencia.
- Cargas con requisitos específicos de retención o recuperación.
Esto ayuda a evitar que todos los equipos consuman el mismo tipo de almacenamiento aunque sus aplicaciones tengan necesidades muy distintas.
4. Controlar costes desde el inicio
El aprovisionamiento bajo demanda facilita crear recursos, pero también puede aumentar el riesgo de consumo no controlado si no existen límites.
Medidas recomendables:
- Cuotas por namespace o equipo.
- Etiquetado consistente.
- Revisiones periódicas de volúmenes no utilizados.
- Políticas de retención claras.
- Alertas de coste y capacidad.
5. Documentar el modelo operativo
El equipo de plataforma debería documentar:
- Qué clases de almacenamiento están disponibles.
- Qué garantías ofrece cada una.
- Qué límites aplican.
- Cómo solicitar más capacidad.
- Cómo se gestionan incidencias.
- Qué responsabilidad tiene el equipo de aplicación y qué responsabilidad tiene el equipo de plataforma.
Consideraciones de arquitectura
Azure Container Storage v2.1.0 con Elastic SAN puede simplificar ciertos escenarios, pero no elimina decisiones críticas.
Disponibilidad
El almacenamiento persistente es una pieza central de cualquier aplicación stateful. Antes de adoptar una nueva opción, revisa cómo se comporta ante fallos de nodo, mantenimiento del clúster y eventos de infraestructura.
Rendimiento
Elastic SAN está orientado a almacenamiento en bloque con requisitos de rendimiento, pero el resultado final depende de varios factores:
- Configuración del recurso de almacenamiento.
- Tipo y tamaño de los nodos de AKS.
- Red.
- Patrón de lectura y escritura de la aplicación.
- Número de volúmenes y consumidores.
- Límites del servicio en la región seleccionada.
No conviene asumir que una mejora en la capa de almacenamiento resolverá automáticamente cuellos de botella de aplicación.
Seguridad
El almacenamiento persistente debe evaluarse con los mismos criterios que cualquier otro recurso crítico:
- Cifrado.
- Control de acceso.
- Identidad gestionada o permisos asignados.
- Separación entre entornos.
- Auditoría.
- Protección frente a borrado accidental.
Recuperación
El hecho de que un volumen sea persistente no equivale a tener una estrategia de recuperación. Para producción, define explícitamente:
- Backups.
- Restauración probada.
- Objetivos RPO y RTO.
- Procedimientos ante eliminación accidental.
- Dependencias con otros servicios.
Cuándo no usarlo
Azure Container Storage con Elastic SAN no tiene por qué ser la mejor opción para todos los casos.
Puede que debas considerar alternativas si:
- La aplicación encaja mejor con almacenamiento compartido de archivos.
- El servicio gestionado de base de datos cubre mejor tus requisitos.
- La carga es completamente stateless.
- El equipo no está preparado para operar aplicaciones stateful en Kubernetes.
- Los requisitos de disponibilidad o recuperación exceden lo que el diseño actual puede garantizar.
- El coste de la solución no compensa frente a opciones más simples.
Kubernetes ofrece flexibilidad, pero ejecutar estado dentro del clúster añade complejidad. La decisión debe justificarse por requisitos técnicos claros.
Conclusión
Azure Container Storage v2.1.0 refuerza la propuesta de Azure para cargas stateful en Kubernetes al incorporar soporte para Azure Elastic SAN y mejorar el modelo de almacenamiento bajo demanda.
La novedad es especialmente interesante para equipos de plataforma que gestionan AKS y necesitan ofrecer almacenamiento persistente de forma más estandarizada, dinámica y alineada con servicios gestionados de Azure.
Aun así, la adopción debe hacerse con criterio: validar compatibilidad, medir rendimiento, controlar costes, definir responsabilidades operativas y diseñar una estrategia real de backup y recuperación. El almacenamiento bajo demanda reduce fricción, pero no sustituye a una buena arquitectura.