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.

También 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

Disco de sistema operativo efímero

De manera predeterminada, Azure replica automáticamente el disco del sistema operativo de una máquina virtual en Azure Storage. De esta forma, puede evitarse la pérdida de datos si se reubica la VM en otro host. Sin embargo, como los contenedores no están diseñados para preservar el estado local, este comportamiento ofrece un valor limitado y además presenta algunos inconvenientes. Estos inconvenientes incluyen, entre otros, un aprovisionamiento de nodos más lento y una latencia de lectura y escritura más elevada.

En cambio, los discos de sistema operativo efímero solo se almacenan en el equipo host, al igual que los discos temporales. Con esta configuración, obtendrá una latencia de lectura y escritura más baja, junto con escalabilidad de nodos y actualizaciones de clúster más rápidas.

Los requisitos de tamaño y las recomendaciones para los discos de SO efímeros están disponibles en la documentación de la máquina virtual de Azure. A continuación se exponen algunas consideraciones generales sobre el dimensionamiento:

• Si decide utilizar la SKU Standard_DS2_v2 del tamaño de máquina virtual predeterminado de AKS con el tamaño de disco de sistema operativo predeterminado de 100 GiB, el tamaño de máquina virtual predeterminado es compatible con el sistema operativo efímero pero solo tiene 86 GiB de tamaño de caché. El valor predeterminado de esta configuración serán discos administrados si no se especifica explícitamente. Si solicita un sistema operativo efímero, recibirá un error de validación.

• Si solicita la misma SKU Standard_DS2_v2 con un disco de sistema operativo de 60 GiB, el valor predeterminado de esta configuración será un sistema operativo efímero. El tamaño solicitado de 60 GiB es menor que el tamaño máximo de caché de 86 GiB.

• Si selecciona la SKU Standard_D8s_v3 con un disco de sistema operativo de 100 GiB, este tamaño de máquina virtual admite el sistema operativo efímero y tiene 200 GiB de espacio en caché. Si no se especifica el tipo de disco del sistema operativo, el grupo de nodos recibirá un sistema operativo efímero de manera predeterminada.

La última generación de la serie de máquinas virtuales no tiene una caché dedicada, sino solo un almacenamiento temporal. Por ejemplo, si seleccionó el tamaño de máquina virtual de Standard_E2bds_v5 con el tamaño de disco del sistema operativo predeterminado de 100 GiB, admite discos de SO efímeros, pero solo tiene 75 GB de almacenamiento temporal. El valor predeterminado de esta configuración serán discos de sistema operativo administrados si no se especifica explícitamente. Si solicita un disco de SO efímero, recibirá un error de validación.

• Si solicita el mismo tamaño de máquina virtual Standard_E2bds_v5 con un disco de SO de 60 GiB, el valor predeterminado de esta configuración serán discos de SO efímeros. El tamaño solicitado de 60 GiB es menor que el almacenamiento temporal máximo de 75 GiB.

• Si selecciona la SKU Standard_E4bds_v5 con un disco de sistema operativo de 100 GiB, este tamaño de máquina virtual admite un sistema operativo efímero y tiene 150 GiB de almacenamiento temporal. Si no especifica el tipo de disco del sistema operativo, Azure aprovisiona de forma predeterminada un disco de SO efímero en el grupo de nodos.

Claves administradas por el cliente

Puede administrar el cifrado del disco de SO efímero con sus propias claves en un clúster de AKS. Para más información, consulte Uso de la clave administrada por el cliente con el disco de Azure en AKS.

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.

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

Puesto que el disco de Azure Disk se monta como ReadWriteOnce, solo está disponible 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 acceden a ellos 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.
   • ConfigMaps se almacena en un espacio de nombres determinado y solo acceden a ConfigMaps 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 los siguientes servicios de datos de Azure Storage para proporcionar PersistentVolume:

• Azure Disk
• Archivos de Azure
• Azure Container Storage (versión preliminar).

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 administrador de clústeres puede crear estáticamente PersistentVolume, o el servidor de API de Kubernetes crea dinámicamente el volumen. 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.

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. Al eliminar el volumen persistente, reclaimPolicy controla el comportamiento del recurso de almacenamiento de Azure subyacente. 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:

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

Puede crear una clase StorageClass para satisfacer otras necesidades 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_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

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 conocer los procedimientos recomendados asociados, consulta Procedimientos recomendados para almacenamiento y copias de seguridad en AKS y Consideraciones de almacenamiento de AKS.

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

• 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
• Usar del controlador CSI de Azure Blob Storage en Azure Kubernetes Service
• Configurar 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