Opciones de almacenamiento de aplicaciones en Azure Kubernetes Service (AKS)

Las aplicaciones que se ejecutan en Azure Kubernetes Service (AKS) pueden necesitar almacenar y recuperar datos. Aunque algunas cargas de trabajo de aplicación pueden usar almacenamiento local y rápido en nodos vacíos innecesarios, otras requieren almacenamiento que se conserva en volúmenes de datos más normales dentro de la plataforma Azure.

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 programa de nuevo en otro nodo.

Por último, es posible que deba recopilar y almacenar datos confidenciales o información de configuración de la aplicación en los pods.

En este artículo se presentan los conceptos básicos que proporcionan almacenamiento para sus aplicaciones en AKS:

• Volúmenes
• Volúmenes persistentes
• Clases de almacenamiento
• Notificaciones de volúmenes persistentes

Volúmenes

Kubernetes suele tratar los pods individuales como recursos efímeros y descartables. Las aplicaciones disponen de diferentes enfoques para usar y conservar datos. Un volumen representa una manera de almacenar, recuperar y conservar datos entre pods y durante el ciclo de vida de la aplicación.

Los volúmenes tradicionales se crean como recursos de Kubernetes respaldados por Azure Storage. Puede crear manualmente volúmenes de datos para que se asignen directamente a los pods, o bien hacer que Kubernetes los cree automáticamente. Los volúmenes de datos pueden usar: Azure Disk, Azure Files, Azure NetApp Files o blobs de Azure.

Nota

En función de la SKU de máquina virtual que se use, el controlador de CSI para discos de Azure podría tener un límite de volumen por nodo. Para algunas máquinas virtuales eficaces (por ejemplo, de 16 núcleos), el límite es de 64 volúmenes por nodo. Para identificar el límite por SKU de máquina virtual, revise la columna Número máximo de discos de datos de cada SKU de máquina virtual ofrecida. Para obtener una lista de las SKU de máquina virtual que se ofrecen y sus límites de capacidad correspondientes detallados correspondientes, vea Tamaños de máquina virtual de uso general.

Para ayudar a determinar la mejor opción para la carga de trabajo entre Azure Files y Azure NetApp Files, revise la información proporcionada en el artículo Comparación entre Azure Files y Azure NetApp.

Azure Disk

Use Azure Disk para crear un recurso DataDisk de Kubernetes. Entre los tipos de discos, se incluyen los siguientes:

• Discos Ultra
• Discos SSD Premium
• Discos SSD estándar
• Discos HDD estándar

Sugerencia

Para la mayoría de las cargas de trabajo de producción y desarrollo, utilice el nivel SSD prémium.

Puesto que los discos de Azure Disk se montan como ReadWriteOnce, solo están disponibles para un único nodo. Para los volúmenes de almacenamiento a los que pueden acceder varios pods en múltiples nodos simultáneamente, use Azure Files.

Azure Files

Use Azure Files para montar un recurso compartido del bloque de mensajes del servidor (SMB) versión 3.1.1 o un recurso compartido del sistema de archivos de red (NFS) versión 4.1 respaldado por una cuenta de almacenamiento de Azure en pods. Con Azure Files, puede compartir datos entre varios nodos y pods, además de utilizar:

• el almacenamiento Premium de Azure respaldado mediante SSD de alto rendimiento
• el almacenamiento Estándar de Azure respaldado mediante HDD normales

Azure NetApp Files

• Almacenamiento Ultra
• Premium Storage
• Standard Storage

Azure Blob Storage

Use Azure Blob Storage para crear un contenedor de Blob Storage y montarlo mediante el protocolo NFS v3.0 o BlobFuse.

• Blobs en bloques

Tipos de volúmenes

Los volúmenes de Kubernetes representan algo más que un disco tradicional para almacenar y recuperar información. Los volúmenes de Kubernetes pueden utilizarse también como una forma de insertar datos en un pod para su uso en contenedores.

Algunos tipos de volumen comunes de Kubernetes son, entre otros:

emptyDir

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 solo se conservan durante la vida útil del pod. Una vez eliminado el pod, también 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

Los volúmenes secret se usan para insertar en pods datos confidenciales, como contraseñas.

1. Cree un secreto mediante la API de Kubernetes.
2. Defina el pod o la implementación y solicite un secreto específico.
   • Los secretos solo se proporcionan a nodos con un pod programado que los requiera.
   • El secreto se almacena en tmpfs, no se escribe en el disco.
3. Cuando se elimina el último pod de un nodo que requiere un secreto, dicho secreto se elimina del 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

Los volúmenes configMap pueden usarse para insertar en pods propiedades de pares clave-valor, como la información de configuración de la aplicación. Defina esta información como un recurso de Kubernetes que se actualice fácilmente y se aplique a nuevas instancias de pods a medida que se implementen.

Al igual que al usar un secreto, debe:

1. crear un volumen ConfigMap mediante la API de Kubernetes y
2. solicitar el volumen ConfigMap al definir un pod o una implementación.
   • Los volúmenes ConfigMap se almacenan en un espacio de nombres determinado y solo son accesibles para los pods del mismo espacio de nombres.

Volúmenes persistentes

Los volúmenes definidos y creados 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 Azure Disk o Azure Files para proporcionar el volumen PersistentVolume. Como se ha indicado en la sección Volúmenes, la elección de Azure Disks o Azure Files suele venir determinada por la necesidad de acceso simultáneo a los datos o al nivel de rendimiento.

Un volumen PersistentVolume puede crearlo de forma estática un administrador de clústeres o de forma dinámica el servidor de API de Kubernetes. Si un pod está programado y solicita almacenamiento que no está disponible actualmente, Kubernetes puede crear el almacenamiento subyacente de Azure Disk o Azure File y conectarlo al pod. El aprovisionamiento dinámico usa StorageClass para identificar el tipo de almacenamiento que Azure Storage debe crear.

Importante

Los volúmenes persistentes no se pueden compartir con pods de Windows y Linux debido a diferencias en la compatibilidad del sistema de archivos entre los dos sistemas operativos.

Clases de almacenamiento

Para definir niveles de almacenamiento diferentes, como Premium y Estándar, puede crear una clase StorageClass.

La clase StorageClass también define la directiva reclaimPolicy. Si se elimina el volumen persistente, la directiva reclaimPolicy controla el comportamiento del recurso de almacenamiento subyacente de Azure. Este recurso puede eliminarse o conservarse para usarse con un pod futuro.

En el caso de los clústeres que usan los controladores de Container Storage Interface, se crean los siguientes StorageClasses adicionales:

Permiso	Motivo
managed-csi	Usa almacenamiento con redundancia local de SSD Estándar de Azure para crear un disco administrado. La directiva de reclamación garantiza que el almacenamiento de Azure Disks 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, solo es necesario editar la notificación de volumen persistente con el nuevo tamaño.
managed-csi-premium	Usa almacenamiento con redundancia local Premium de Azure para crear un disco administrado. De nuevo, la directiva de reclamación garantiza que el almacenamiento de Azure Disks subyacente se elimina cuando se elimina el volumen persistente que lo utiliza. De forma similar, esta clase de almacenamiento permite expandir los volúmenes persistentes.
azurefile-csi	Usa el almacenamiento Azure Standard para crear un recurso compartido de archivos de Azure. La directiva de reclamación garantiza que el recurso compartido de archivos de Azure subyacente se elimina cuando se elimina el volumen persistente que lo usa.
azurefile-csi-premium	Usa Azure Premium Storage para crear un recurso compartido de archivos de Azure. La directiva de reclamación garantiza que el recurso compartido de archivos de Azure subyacente se elimina cuando se elimina el volumen persistente que lo usa.
azureblob-nfs-premium	Usa Azure Premium Storage para crear un contenedor de Azure Blob Storage y conectarse mediante el protocolo NFS v3. La directiva de reclamación garantiza que el contenedor subyacente de Azure Blob Storage se elimina cuando se elimina el volumen persistente que lo usa.
azureblob-fuse-premium	Usa Azure Premium Storage para crear un contenedor de Azure Blob Storage y conectarse mediante BlobFuse. La directiva de reclamación garantiza que el contenedor subyacente de Azure Blob Storage se elimina cuando se elimina el volumen persistente que lo usa.

A menos que especifique una clase StorageClass para un volumen persistente, se usará la clase StorageClass predeterminada. Cuando solicite volúmenes persistentes, asegúrese de que usen el almacenamiento adecuado que necesita.

Importante

A partir de la versión 1.21 de Kubernetes, AKS solo usa controladores CSI de forma predeterminada y la migración de CSI está habilitada. Aunque los volúmenes persistentes existentes en el árbol siguen funcionando, a partir de la versión 1.26, AKS ya no admitirá volúmenes creados con el controlador en el árbol y el almacenamiento aprovisionados para archivos y discos.

La clase default será la misma que managed-csi.

Puede crear una clase StorageClass para satisfacer necesidades adicionales mediante kubectl. En el siguiente ejemplo se utilizan discos administrados Premium y se especifica que el disco subyacente de Azure Disks debe conservarse cuando se elimine el pod:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_LRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Nota

AKS concilia las clases de almacenamiento predeterminadas y sobrescribirá los cambios que realice en ellas.

Para obtener más información sobre las clases de almacenamiento, consulte StorageClass en Kubernetes.

Notificaciones de volúmenes persistentes

Las notificaciones PersistentVolumeClaim solicitan almacenamiento de una clase StorageClass, un modo de acceso y un tamaño determinados. El servidor de API de Kubernetes puede aprovisionar dinámicamente el recurso de almacenamiento subyacente de Azure si no existe ningún recurso para satisfacer la notificación de acuerdo con la clase StorageClass definida.

La definición del pod incluye el montaje del volumen una vez que se este se ha conectado al pod.

Una vez que se ha asignado un recurso de almacenamiento disponible al pod que lo solicita, se enlaza un volumen PersistentVolume a una notificación PersistentVolumeClaim. Los volúmenes persistentes se asignan a las notificaciones de uno a uno.

El manifiesto YAML de ejemplo siguiente muestra una notificación de volumen persistente que usa la clase StorageClass managed-premium y solicita un disco de 5 Gi de tamaño:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

Al crear una definición de pod, también se especifica lo siguiente:

• La notificación de volumen persistente para solicitar el almacenamiento deseado
• El objeto volumeMount para que sus aplicaciones lean y escriban datos

El siguiente manifiesto YAML de ejemplo muestra cómo se puede usar la notificación de volumen persistente anterior para montar un volumen en /mnt/azure:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

Para montar un volumen en un contenedor de Windows, especifique la letra de unidad y la ruta de acceso. Por ejemplo:

...      
       volumeMounts:
        - mountPath: "d:"
          name: volume
        - mountPath: "c:\k"
          name: k-dir
...

Pasos siguientes

Para consultar los procedimientos recomendados asociados, consulte Procedimientos recomendados para el almacenamiento y las copias de seguridad en Azure Kubernetes Service (AKS).

Para obtener información sobre cómo usar controladores CSI, consulte los siguientes artículos:

• Habilitación de los controladores de Container Storage Interface (CSI) para Azure Disk, Azure Files y Azure Blob Storage en Azure Kubernetes Service
• Uso del controlador CSI de Azure Disk en Azure Kubernetes Service
• Uso del controlador CSI de Azure Files en Azure Kubernetes Service
• Uso del controlador CSI de Azure Blob Storage (versión preliminar) en Azure Kubernetes Service
• Integración de Azure NetApp Files con Azure Kubernetes Service

Para obtener más información sobre los conceptos básicos de Kubernetes y AKS, consulte los artículos siguientes:

• Clústeres y cargas de trabajo de Kubernetes/AKS
• Identidad de Kubernetes/AKS
• Seguridad de Kubernetes/AKS
• Redes virtuales de Kubernetes/AKS
• Escala de Kubernetes/AKS