Compartir volúmenes entre pods y zonas en AKS

Artículo

Ricardo Paiva · 7 hr atrás Lectura de 6 min

#Azure #Kubernetes #Mirroring #Nube #InterSystems IRIS #InterSystems Kubernetes Operator (IKO)

Contexto

Por una variedad de razones, los usuarios pueden desear montar un volumen persistente en dos o más pods que abarquen varias zonas de disponibilidad. Un caso de uso de este tipo es poner a disposición de ambos miembros del espejo los datos almacenados fuera de IRIS en caso de una conmutación por error.

Desafortunadamente, las clases de almacenamiento integradas en la mayoría de las implementaciones de Kubernetes (ya sea en la nube o en las instalaciones) no ofrecen esta capacidad:

No admiten el modo de acceso "ReadWriteMany"
No admiten ser montadas en más de un pod a la vez
No admiten el acceso entre zonas de disponibilidad

Sin embargo, algunos complementos de Kubernetes (tanto de proveedores como de terceros) sí ofrecen esta capacidad. El que veremos en este artículo es Azure Blob Store.

Resumen

En este artículo vamos a:

Crear un clúster de Kubernetes en AKS (Azure Kubernetes Engine)
Usar Azure Blob Store para crear un volumen persistente de tipo ReadWriteMany
Usar IKO para desplegar un espejo de conmutación por error de IRIS que abarque dos zonas de disponibilidad
Montar el volumen persistente en ambos miembros del espejo
Demostrar que ambos miembros del espejo tienen acceso de lectura/escritura al volumen

Pasos

Los siguientes pasos los llevaréis a cabo usando Azure Cloud Shell. Tened en cuenta que InterSystems no se hace responsable de los costes en los que incurráis en los siguientes ejemplos.

Vais a usar la región "eastus" y las zonas de disponibilidad "eastus-2" y "eastus-3".

Crear grupo de recursos

az group create \
   --name samplerg \
   --location eastus

Crear entidad de servicio

Extraemos el App Id y el Client Secret para la siguiente llamada:

SP=$(az ad sp create-for-rbac -o tsv)
APP_ID="$(echo $SP | cut -d' ' -f1)"
CLIENT_SECRET="$(echo $SP | cut -d' ' -f3)"

Crear el cluster de Kubernetes

az aks create \ --resource-group samplerg \ --name sample \ --node-count 6 \ --zones 2 3 \ --generate-ssh-key \ --service-principal $APP_ID \ --client-secret $CLIENT_SECRET \ --kubernetes-version 1.33.2 \ --enable-blob-drive

Crear un PersistentVolumeClaim

Añadid lo siguiente a un archivo llamado azure-blob-pvc.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-blob-storage
spec:
  accessModes:
  - ReadWriteMany
  storageClassName: azureblob-nfs-premium
  resources:
    requests:
      storage: 5Gi

Ahora cread el persistent volume claim

kubectl apply -f azure-blob-pvc.yaml

Instalad IKO

Instalad e iniciad IKO:

helm install sample iris_operator_amd-3.8.42.100/chart/iris-operator

Consultad la documentación de IKO para obtener información adicional sobre cómo descargar y configurar IKO.

Cread un IrisCluster

Añadid lo siguiente a un archivo llamado iris-azureblob-demo.yaml:

apiVersion: intersystems.com/v1alpha1
kind: IrisCluster
metadata:
  name: sample
spec:
  storageClassName: iris-ssd-storageclass
  licenseKeySecret:
    name: iris-key-secret
  imagePullSecrets:
    - name: dockerhub-secret
  volumes:
  - name: nfs-volume
    persistentVolumeClaim:
      claimName: azure-blob-pvc
  topology:
    data:
      image: containers.intersystems.com/intersystems/iris:2025.2
      preferredZones: ["eastus-2","eastus-3"]
      mirrored: true
      volumeMounts:
      - name: nfs-volume
        mountPath: "/mnt/nfs"

Notas:

El espejo abarca ambas zonas de disponibilidad de nuestro clúster
Consultad la documentación de IKO para obtener información sobre cómo configurar un IrisCluster

Ahora cread el IrisCluster:

kubectl apply -f iris-azureblob-demo.yaml

Poco después deberíais ver que el IrisCluster está en funcionamiento:

$ kubectl get pod,pv,pvc
NAME                 READY  STATUS   RESTARTS  AGE
pod/sample-data-0-0  1/1    Running  0         9m34s
pod/sample-data-0-1  1/1    Running  0         91s

NAME              CAPACITY  ACCESS MODES  STATUS   CLAIM                      STORAGECLASS
pvc-bbdb986fba54   5Gi       RWX           Bound    azure-blob-pvc             azureblob-nfs-premium
pvc-9f5cce1010a3   4Gi       RWO           Bound    iris-data-sample-data-0-0  iris-ssd-storageclass
pvc-5e27165fbe5b   4Gi       RWO           Bound    iris-data-sample-data-0-1  iris-ssd-storageclass

NAME                      STATUS  VOLUME            CAPACITY  ACCESS MODES  STORAGECLASS            
azure-blob-pvc             Bound   pvc-bbdb986fba54  5Gi       RWX           azureblob-nfs-premium
iris-data-sample-data-0-0  Bound   pvc-9f5cce1010a3  4Gi       RWO           iris-ssd-storageclass
iris-data-sample-data-0-1  Bound   pvc-5e27165fbe5b  4Gi       RWO           iris-ssd-storageclass

También podemos (uniendo la salida de "kubectl get pod" con "kubectl get node") ver que los miembros del espejo residen en diferentes zonas de disponibilidad:

sample-data-0-0 aks-nodepool1-10664034-vmss000001 eastus-2
sample-data-0-1 aks-nodepool1-10664034-vmss000002 eastus-3

Probad el volumen compartido

Podéis crear archivos en el volumen compartido en cada pod:

kubectl exec sample-data-0-0 -- touch /mnt/nfs/primary.txt
kubectl exec sample-data-0-1 -- touch /mnt/nfs/backup.txt

Y luego observad que los archivos son visibles desde ambos pods:

$ kubectl exec sample-data-0-0 -- ls /mnt/nfs
primary.txt
backup.txt
$ kubectl exec sample-data-0-1 -- ls /mnt/nfs
primary.txt
backup.txt

Limpieza

Eliminad el despliegue de IrisCluster

kubectl delete -f iris-azureblob-demo.yaml --ignore-not-found
helm uninstall sample --ignore-not-found

Eliminad los volúmenes persistentes

kubectl delete azure-blob-pvc iris-data-sample-data-0-0 iris-data-sample-data-0-1 --ignore-not-found

Tened en cuenta que eliminar el PersistentVolumeClaim desencadena la eliminación del PersistentVolume correspondiente.

Eliminad el clúster de Kubernetes

az aks delete --resource-group samplerg --name sample --yes

Eliminad el grupo de recursos

az group delete --name samplerg --no-wait --yes

Conclusión

Hemos demostrado cómo Azure Blob Store puede usarse para montar volúmenes de lectura/escritura en pods que residen en diferentes zonas de disponibilidad. Existen varias otras soluciones disponibles tanto para AKS como para otros proveedores de nube. Como podéis ver, su configuración puede ser muy esotérica y específica de cada proveedor, pero una vez que funciona puede ser fiable y eficaz.

Ir a la publicación original, escrita por @Steve Lubars