Opciones de almacenamiento para aplicaciones en AKS habilitadas por Azure Arc
Se aplica a: AKS en Azure Stack HCI 22H2, AKS en Windows Server
Es posible que las aplicaciones que se ejecutan en implementaciones de AKS mediante Azure Kubernetes Service habilitado por Azure Arc necesiten almacenar y recuperar datos. En algunas carga de trabajo de la aplicación, los datos pueden usar almacenamiento local rápido en un nodo no necesario cuando se eliminan los pods (Kubernetes usa pods para ejecutar una instancia de una aplicación).
Otras cargas de trabajo pueden requerir almacenamiento que persista en volúmenes de datos más normales. Es posible que varios pods necesiten compartir los mismos volúmenes de datos o volver a adjuntar volúmenes de datos si el pod se vuelve a programar en un nodo diferente. Además, es posible que necesite una opción de almacenamiento si los pods contienen información confidencial de configuración de aplicaciones o datos confidenciales.
En este artículo se presentan los conceptos básicos que proporcionan almacenamiento a las aplicaciones en AKS Arc, entre los que se incluyen:
- Volúmenes
- Volúmenes persistentes
- Clases de almacenamiento
- Notificaciones de volumen persistente (PVC)
Volúmenes
A menudo, las aplicaciones necesitan poder almacenar y recuperar datos. Dado que Kubernetes suele tratar los pods individuales como recursos temporales y descartables, existen diferentes enfoques disponibles para usar aplicaciones y conservar datos. Un volumen representa una forma de almacenar, recuperar y conservar datos entre pods y a través del ciclo de vida de la aplicación.
En Kubernetes, los volúmenes pueden representar más que solo un tradicional en el que se almacena y recupera la información. Los volúmenes de Kubernetes también se pueden utilizar como una forma de insertar datos en un pod para que los contenedores lo utilicen. Algunos tipos de volúmenes comunes de Kubernetes incluyen los siguientes:
emptyDir: este volumen se suele utilizar como espacio temporal para un pod. Todos los contenedores dentro de un pod pueden acceder a los datos del volumen. Los datos escritos en este tipo de volumen se conservan únicamente para la duración del pod (cuando se elimina el pod, se elimina el volumen). Este volumen suele usar el almacenamiento en disco del nodo local subyacente, aunque también puede existir solo en la memoria del nodo.
secret : este volumen se usa para incluir datos confidenciales, como contraseñas, en pods. En primer lugar, cree un secreto mediante la API de Kubernetes. Al definir el pod o la implementación, puede solicitar un secreto específico. Los secretos solo se proporcionan a los nodos con un pod programado que lo requiere y el secreto se almacena en tmpfs, no se escribe en el disco. Cuando se elimina el último pod de un nodo que requiere un secreto, el secreto se elimina de tmpfs del nodo. Los secretos se almacenan en un espacio de nombres determinado y solo son accesibles para los pods del mismo espacio de nombres.
configMap: este tipo de volumen se usa para insertar las propiedades de pares clave-valor en pods, como la información de configuración de la aplicación. En lugar de definir la información de configuración de la aplicación dentro de una imagen de contenedor, puede definirla como un recurso de Kubernetes que se pueda actualizar fácilmente y aplicarse a las nuevas instancias de pods a medida que se implementan. De forma similar al uso de un secreto, primero se crea un objeto ConfigMap mediante la API de Kubernetes. Después, se puede solicitar este configMap al definir un pod o una implementación. ConfigMaps se almacenan en un espacio de nombres determinado y solo los pods pueden acceder a ellos dentro del mismo espacio de nombres.
Volúmenes persistentes
Los volúmenes que se definen y se crean como parte del ciclo de vida del pod solo existen hasta que se elimina este. Los pods suelen esperar que su almacenamiento se conserve si un pod se vuelve a programar en un host diferente durante un evento de mantenimiento, especialmente en StatefulSets. Un volumen persistente es un recurso de almacenamiento creado y administrado por la API de Kubernetes que puede existir más allá de la duración de un pod individual.
Puede usar volúmenes de disco de AKS respaldados por VHDX que se montan como ReadWriteOnce y son accesibles para un solo nodo a la vez. O bien, puede usar volúmenes de archivos de AKS respaldados por recursos compartidos de archivos SMB o NFS. Estos se montan como ReadWriteMany y están disponibles para varios nodos simultáneamente.
Un administrador de clústeres puede crear estáticamente un volumen persistente o el volumen se puede crear dinámicamente mediante el servidor de API de Kubernetes. Si un pod está programado y solicita almacenamiento que no está disponible actualmente, Kubernetes puede crear el archivo VHDX subyacente y conectarlo al pod. El aprovisionamiento dinámico usa StorageClass para identificar el tipo de almacenamiento que se debe crear.
Clases de almacenamiento
Para definir diferentes niveles (y ubicación) de almacenamiento, puede crear una clase StorageClass. StorageClass también define la propiedad reclaimPolicy. Esta propiedad reclaimPolicy controla el comportamiento del recurso de almacenamiento subyacente cuando se elimina el pod y es posible que el volumen persistente ya no sea necesario. El recurso de almacenamiento subyacente se puede eliminar o conservar para su uso con un pod futuro.
En AKS Arc, la clase de almacenamiento predeterminada se crea automáticamente y usa CSV para crear volúmenes respaldados por VHDX. La directiva de recuperación garantiza que el archivo VHDX subyacente se elimina cuando se elimina el volumen persistente que lo utiliza. La clase de almacenamiento también configura los volúmenes persistentes para que se puedan expandir, por tanto, solo es necesario editar la notificación de volumen persistente con el nuevo tamaño.
Si no se especifica StorageClass para un volumen persistente, se usa la clase StorageClass predeterminada. Al solicitar volúmenes persistentes, asegúrese de que usan el almacenamiento adecuado. Puede crear una clase StorageClass para necesidades adicionales.
Notificaciones de volúmenes persistentes
PersistentVolumeClaim solicita el almacenamiento ReadWriteOnce o ReadWriteMany de un storageClass y un tamaño determinados. El servidor de API de Kubernetes puede aprovisionar dinámicamente el recurso de almacenamiento subyacente en AKS Arc si no hay ningún recurso existente para cumplir la notificación en función de la clase StorageClass definida. La definición del pod incluye el montaje del volumen una vez que se este se ha conectado al pod.
PersistentVolume se enlaza a persistentVolumeClaim una vez que se asigna un recurso de almacenamiento disponible al pod que lo solicita. Existe una asignación de 1:1 de volúmenes a notificaciones.
En el siguiente manifiesto YAML de ejemplo se muestra una notificación de volumen persistente que usa storageClass predeterminada y solicita un disco 5Gi:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: aks-hci-vhdx
spec:
accessModes:
- ReadWriteOnce
storageClassName: default
resources:
requests:
storage: 5Gi
Al crear una definición de pod, especifique la notificación de volumen persistente para solicitar el almacenamiento deseado. A continuación, especifique para volumeMount que las aplicaciones lean y escriban datos. El siguiente manifiesto YAML de ejemplo muestra cómo se usa la notificación de volumen persistente anterior para montar un volumen en/mnt/aks-hci:
kind: Pod
apiVersion: v1
metadata:
name: nginx
spec:
containers:
- name: myfrontend
image: k8s.gcr.io/nginx
volumeMounts:
- mountPath: "/mnt/aks-hci"
name: volume
nodeSelector:
kubernetes.io/os: linux
volumes:
- name: volume
persistentVolumeClaim:
claimName: aks-hci-vhdx
En el ejemplo siguiente se muestra cómo montar un volumen en un contenedor de Windows y especificar la letra de unidad y la ruta de acceso:
volumeMounts:
- mountPath: "d:"
name: volume
- mountPath: "c:\k"
name: k-dir