Compartir por

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

  • Artigo

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:

Diagrama de opciones de almacenamiento para aplicaciones en un clúster de Azure Kubernetes Services (AKS).

Ajuste de tamaño predeterminado del disco del sistema operativo

Al crear un nuevo clúster o agregar un nuevo grupo de nodos a un clúster existente, de manera predeterminada el tamaño del disco del sistema operativo viene determinado por el número de vCPU. El número de vCPU se basa en la SKU de máquina virtual. En la siguiente tabla se muestra el tamaño de disco del sistema operativo predeterminado para cada SKU de máquina virtual:

Núcleos de SKU de máquina virtual (vCPU) Nivel predeterminado del disco del sistema operativo IOPS aprovisionadas Rendimiento aprovisionado (Mbps)
1 - 7 P10/128 G 500 100
8 - 15 P15/256 G 1100 125
16 - 63 P20/512 G 2300 150
64+ P30/1024 G 5000 200

Importante

El ajuste de tamaño predeterminado del disco del sistema operativo solo se usa en nuevos clústeres o grupos de nodos cuando no se admiten discos del sistema operativo efímeros y no se especifica un tamaño de disco del sistema operativo predeterminado. El tamaño predeterminado del disco del sistema operativo podría afectar al rendimiento o al costo del clúster. No se puede cambiar el tamaño del disco del sistema operativo después de la creación del clúster o del grupo de nodos. Este ajuste de tamaño de disco predeterminado afecta a los clústeres o grupos de nodos creados en julio de 2022 o posteriores.

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 máquina virtual 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.

Nota:

Si no se solicitan explícitamente discos administrados de Azure para el sistema operativo, AKS toma como valor predeterminado un sistema operativo efímero, siempre que sea posible, para una configuración de grupo de nodos determinada.

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.

Nota

En función de la SKU de máquina virtual que está usando, el controlador de CSI para discos de Azure podría tener un límite de volumen por nodo. Para algunas máquinas virtuales de alto rendimiento (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:

  • SSD Premium (recomendado para la mayoría de las cargas de trabajo)
  • Discos Ultra
  • Discos SSD estándar
  • Discos HDD estándar

Sugerencia

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

Dado que un disco de Azure se monta como ReadWriteOnce, solo está disponible para un solo 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 de 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. 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 también se pueden usar como una manera de insertar datos en un pod para que los usen sus 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 el volumen persistente:

Como se indica en la sección Volúmenes, la elección de Azure Disks o Azure Files suele determinarse por la necesidad de acceso simultáneo a los datos o al nivel de rendimiento.

Diagrama de volúmenes persistentes en un clúster de Azure Kubernetes Services (AKS).

Un administrador de clústeres puede de forma estática crear un volumen persistente o un 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 almacenamiento subyacente de Azure Disk o File Storage y adjuntarlo al pod. El aprovisionamiento dinámico usa una clase de almacenamiento para identificar qué tipo de recurso se 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 especificar distintos niveles de almacenamiento, como Premium o Estándar, puede crear una clase de almacenamiento.

Una clase de almacenamiento también define una directiva de recuperación. Al eliminar el volumen persistente, la directiva de reclamación controla el comportamiento del recurso de Azure Storage subyacente. El recurso subyacente se puede eliminar o conservar para su uso con un pod futuro.

En el caso de los clústeres que utilizan los controladores de Container Storage Interface (CSI) se crean las siguientes clases de almacenamiento adicionales:

Clase de almacenamiento Descripción
managed-csi usa almacenamiento con redundancia local (LRS) 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 que se van a expandir. Puede editar la notificación de volumen persistente para especificar el nuevo tamaño. A partir de la versión 1.29 de Kubernetes, en clústeres de Azure Kubernetes Service (AKS) implementados en varias zonas de disponibilidad, esta clase de almacenamiento usa almacenamiento con redundancia de zona SSD estándar (ZRS) de Azure para crear discos administrados.
managed-csi-premium Utiliza almacenamiento con redundancia local (LRS) 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. A partir de la versión 1.29 de Kubernetes, en clústeres de Azure Kubernetes Service (AKS) implementados en varias zonas de disponibilidad, esta clase de almacenamiento usa almacenamiento con redundancia de zona (ZRS) Premium de Azure para crear discos administrados.
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 de almacenamiento para un volumen persistente, se usa la clase de almacenamiento 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.

A partir de la versión 1.29 de Kubernetes, al implementar clústeres de Azure Kubernetes Service (AKS) en varias zonas de disponibilidad, AKS usa ahora almacenamiento con redundancia de zona (ZRS) para crear discos administrados en clases de almacenamiento integradas. ZRS garantiza la replicación sincrónica de los discos administrados de Azure en varias zonas de disponibilidad de Azure en la región elegida. Esta estrategia de redundancia mejora la resistencia de las aplicaciones y protege los datos frente a errores del centro de datos.

Sin embargo, es importante tener en cuenta que el almacenamiento con redundancia de zona (ZRS) tiene un costo mayor en comparación con el almacenamiento con redundancia local (LRS). Si la optimización de costos es una prioridad, puede crear una nueva clase de almacenamiento con el parámetro skuname establecido en LRS. A continuación, puede usar la nueva clase de almacenamiento en la notificación de volumen persistente (PVC).

Puede crear una clase de almacenamiento para 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

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

Una notificación de volumen persistente (PVC) solicita almacenamiento de una clase de almacenamiento determinada, modo de acceso y tamaño. El servidor de API de Kubernetes puede aprovisionar dinámicamente el recurso subyacente de Azure Storage si ningún recurso existente puede cumplir la notificación en función de la clase de almacenamiento definida.

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

Diagrama de notificaciones de volumen persistente en un clúster de Azure Kubernetes Services (AKS).

Una vez que se ha asignado un recurso de almacenamiento disponible al pod que solicita almacenamiento, el volumen persistente se enlaza a una notificación de volumen persistente. Los volúmenes persistentes se asignan a notificaciones en una asignación 1:1.

En el siguiente manifiesto YAML de ejemplo se muestra una notificación de volumen persistente que usa la clase de almacenamiento prémium administrada y solicita un disco de Azure con un tamaño de 5Gi:

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 montaje de volumen para que las 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:

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