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: 5GiAhora cread el persistent volume claim
kubectl apply -f azure-blob-pvc.yamlInstalad IKO
Instalad e iniciad IKO:
helm install sample iris_operator_amd-3.8.42.100/chart/iris-operatorConsultad 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.yamlPoco 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 91sNAME 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-storageclassNAME 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-storageclassTambié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-3Probad 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.txtY 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.txtLimpieza
Eliminad el despliegue de IrisCluster
kubectl delete -f iris-azureblob-demo.yaml --ignore-not-found
helm uninstall sample --ignore-not-foundEliminad los volúmenes persistentes
kubectl delete azure-blob-pvc iris-data-sample-data-0-0 iris-data-sample-data-0-1 --ignore-not-foundTened 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 --yesEliminad 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.