¿Cómo se distribuye el volumen persistente en diferentes zonas para garantizar el acceso al almacenamiento para diferentes dominios y zonas?

Al usar Kubernetes y nubes públicas (por ejemplo, AWS, GCP, Azure), la distribución de volúmenes persistentes (PV) por zonas se realiza a nivel del proveedor de la nube y la vinculación de PV a nodos:

1. Creación de PV: El volumen persistente (PersistentVolume) se crea por el administrador o automáticamente a través de StorageClass. Al crearlo, se especifican los parámetros de almacenamiento: tipo (EBS, GCE Persistent Disk, Azure Disk), tamaño, modo de acceso.
2. Conciencia de Zona/Región: StorageClass para ciertos tipos de almacenamiento en la nube puede configurarse con soporte para zonas de disponibilidad. Al crear un PV mediante tal StorageClass, el proveedor de la nube puede ubicar el recurso físico de almacenamiento (por ejemplo, un disco) en una zona específica o hacerlo redundante en zonas (dependiendo del tipo de almacenamiento y configuraciones). El uso de StorageClass con el parámetro volumeBindingMode: WaitForFirstConsumer permite retrasar la vinculación del PV al PVR hasta que el primer pod que use ese PVR esté programado en un nodo en una zona específica.
3. PersistentVolumeClaim (PVC): El usuario crea un PersistentVolumeClaim (PVC) solicitando un volumen y características específicas.
4. Vinculación de PV a PVC: Kubernetes enlaza el PVC con un PV adecuado. Si se usó WaitForFirstConsumer, la vinculación ocurre cuando el primer pod que usa ese PVC está programado en un nodo.
5. Ubicación del Pod en el Nodo: El planificador de Kubernetes (Scheduler) determina en qué nodo se ejecutará el pod. Se consideran diversos criterios, incluyendo requisitos de recursos, afinidad/anti-afinidad, Taints/Tolerations.
6. Vinculación de PV al Nodo: Si el pod que usa el PVC (que a su vez está vinculado al PV) está programado en un nodo en una zona específica, Kubernetes (más precisamente, el Controlador de Volumen y el proveedor de la nube) garantiza que el PV esté disponible (montado) en ese nodo. Los discos en la nube generalmente se vinculan a máquinas virtuales en la misma zona. Kubernetes considera la zonalidad del PV al planificar los pods para evitar intentar montar un PV de una zona en un nodo de otra.

Ejemplo de StorageClass con modo de zona:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: regional-storage
provisioner: kubernetes.io/aws-ebs # o gce-pd, microsoft.com/azure-disk, etc.
parameters:
 type: gp2 # o ssd, pd-standard, etc.
 fsType: ext4
 volumeBindingMode: WaitForFirstConsumer # Parámetro importante para planificación zonal
reclaimPolicy: Retain
allowVolumeExpansion: true

Al usar volumeBindingMode: WaitForFirstConsumer, Kubernetes espera a que el pod esté programado en un nodo en una zona específica (por ejemplo, us-east-1a) antes de vincular definitivamente el PVC al PV y crear el disco en la misma zona.

La distribución por dominios (en un sentido amplio, como separación lógica de aplicaciones o equipos) se logra no mediante la distribución de PV físicos, sino a través del mecanismo RBAC (Control de Acceso Basado en Roles), cuotas de recursos (Resource Quotas) y aislamiento en espacios de nombres (Namespaces):

• Namespaces: Diferentes dominios/equipos pueden usar sus propios espacios de nombres para aislar recursos, incluyendo PVC y pods.
• RBAC: Define qué usuarios o grupos tienen derecho a crear, leer, actualizar o eliminar PVC y otros recursos en ciertos espacios de nombres.
• Cuotas de Recursos: Limitan la cantidad total de recursos (incluyendo volumen de almacenamiento persistente) que se pueden usar en cada espacio de nombres, asegurando un uso justo entre "dominios".