Compartir a través de

Opciones de almacenamiento para un clúster de Kubernetes

  • Artículo

En este artículo se comparan las funcionalidades de almacenamiento de Amazon Elastic Kubernetes Service (Amazon EKS) y Azure Kubernetes Service (AKS) y se describen las opciones para almacenar datos de carga de trabajo en AKS.

Nota:

Este artículo forma parte de una serie de artículos que ayudan a los profesionales que están familiarizados con Amazon EKS a comprender Azure Kubernetes Service (AKS).

Opciones de almacenamiento de Amazon EKS

Al ejecutar aplicaciones que requieren almacenamiento de datos, Amazon EKS ofrece diferentes tipos de volúmenes para el almacenamiento temporal y duradero.

Volúmenes efímeros

En el caso de las aplicaciones que requieren volúmenes locales temporales, pero que no necesitan conservar los datos después de reiniciarse, se pueden usar volúmenes efímeros. Kubernetes admite diferentes tipos de volúmenes efímeros, como emptyDir, configMap, downwardAPI, secretoy hostpath. Para garantizar la rentabilidad y el rendimiento, es importante elegir el volumen de host más adecuado. En Amazon EKS, puede usar gp3 como volumen raíz del host, que ofrece precios más bajos en comparación con los volúmenes gp2.

Otra opción para volúmenes efímeros son los almacenes de instancias de Amazon EC2, que proporcionan almacenamiento temporal de nivel de bloque para instancias de EC2. Estos volúmenes están conectados físicamente a los hosts y solo existen durante la vigencia de la instancia. El uso de volúmenes de almacén local en Kubernetes requiere la creación de particiones, la configuración y el formato de los discos mediante datos de usuario de Amazon EC2.

Volúmenes persistentes

Aunque Kubernetes se asocia normalmente a la ejecución de aplicaciones sin estado, hay casos en los que se requiere almacenamiento de datos persistente. Los volúmenes persistentes de Kubernetes (PV) se pueden usar para almacenar datos independientemente de los pods, lo que permite que los datos se conserven más allá de la vida útil de un pod específico. Amazon EKS admite diferentes tipos de opciones de almacenamiento para PVs, incluidos Amazon EBS, Amazon EFS, Amazon FSx for Lustre, y Amazon FSx for NetApp ONTAP.

los volúmenes de de Amazon EBS son adecuados para el almacenamiento a nivel de bloque y son ideales para bases de datos y aplicaciones que requieren un alto rendimiento. Los usuarios de Amazon EKS pueden usar la última generación de almacenamiento en bloques gp3 para un equilibrio entre el precio y el rendimiento. Para las aplicaciones de mayor rendimiento, se pueden usar volúmenes de io2 block express.

amazon EFS es un sistema de archivos elástico sin servidor que se puede compartir entre varios contenedores y nodos. Crece y se reduce automáticamente a medida que se agregan o quitan archivos, lo que elimina la necesidad de planear la capacidad. El controlador Amazon Elastic File System Container Storage Interface (CSI) se utiliza para integrar Amazon EFS con Kubernetes.

Amazon FSx para Lustre proporciona almacenamiento de archivos paralelos de alto rendimiento, ideal para escenarios que requieren operaciones de alto rendimiento y baja latencia. Se puede vincular a un repositorio de datos de Amazon S3 para almacenar grandes conjuntos de datos. Amazon FSx para NetApp ONTAP es una solución de almacenamiento compartido totalmente administrada basada en el sistema de archivos ONTAP de NetApp.

Los usuarios de Amazon EKS pueden usar herramientas como AWS Compute Optimizer y Velero para optimizar las configuraciones de almacenamiento y administrar copias de seguridad e instantáneas.

Opciones de almacenamiento de AKS

Es posible que las aplicaciones que se ejecutan en Azure Kubernetes Service (AKS) necesiten almacenar y recuperar datos. Aunque algunas cargas de trabajo de aplicaciones pueden usar el almacenamiento local y rápido en nodos vacíos innecesarios, otros requieren almacenamiento que persista en volúmenes de datos más normales dentro de la plataforma Azure. Es posible que varios pods necesiten:

  • Comparta los mismos volúmenes de datos.
  • volver a adjuntar volúmenes de datos si el pod se programa de nuevo en otro nodo.

En este artículo se presentan las opciones de almacenamiento y los conceptos básicos que proporcionan almacenamiento a las aplicaciones en AKS.

Tipos de volumen

Los volúmenes de Kubernetes representan más que solo un disco tradicional para almacenar y recuperar información. Los volúmenes de Kubernetes también se pueden utilizar como un método para inyectar datos en un pod para que sean utilizados por sus contenedores.

Los tipos de volumen comunes de Kubernetes incluyen EmptyDirs, Secrety ConfigMaps.

EmptyDirs

Para un pod que define un volumen de emptyDir, el volumen se crea cuando se asigna el pod a un nodo. Como sugiere el nombre, el volumen de emptyDir está inicialmente vacío. Todos los contenedores del pod pueden leer y escribir en los mismos archivos del volumen emptyDir, aunque este volumen se pueda montar en las mismas o distintas rutas dentro de cada contenedor. Cuando se quita un pod de un nodo por cualquier motivo, los datos de emptyDir se eliminan de forma permanente.

Secretos

Un Secreto es un objeto que contiene una pequeña cantidad de datos sensibles, como una contraseña, un token o una clave. Esta información se incluiría en una especificación del Pod o imagen de contenedor. Mediante un secreto, evita insertar datos confidenciales directamente en el código de la aplicación. Dado que los secretos se pueden crear independientemente de los pods que los usan, existe un riesgo reducido de exponer el secreto (y sus datos) durante los procesos de creación, visualización y edición de pods. Kubernetes, junto con las aplicaciones que se ejecutan en el clúster, también puede tomar precauciones adicionales con los Secretos, como evitar que se escriban datos confidenciales en el almacenamiento no persistente. Aunque los secretos son similares a ConfigMaps, están diseñados específicamente para almacenar datos confidenciales.

Puede usar secretos para los siguientes fines:

El plano de control de Kubernetes también utiliza secretos, como los secretos de token de inicio, que son un mecanismo para ayudar a automatizar el registro de nodos.

ConfigMaps

Un ConfigMap es un objeto de Kubernetes que se usa para almacenar datos no confidenciales en pares clave-valor. Los pods pueden consumir ConfigMaps como variables de entorno, argumentos de línea de comandos o como archivos de configuración en un volumen. ConfigMap permite desacoplar la configuración específica del entorno de las imágenes de contenedor, de modo que las aplicaciones sean fácilmente portátiles.

ConfigMap no proporciona confidencialidad ni cifrado. Si los datos que desea almacenar son confidenciales, use un Secreto en lugar de un ConfigMap, o utilice herramientas adicionales (de terceros) para proteger la privacidad de sus datos.

Puede usar configMap para establecer los datos de configuración por separado del código de la aplicación. Por ejemplo, imagine que está desarrollando una aplicación que puede ejecutar en su propio equipo (para el desarrollo) y en la nube (para controlar el tráfico real). Usted escribe el código para buscar en una variable de entorno denominada DATABASE_HOST. Localmente, establezca esa variable en localhost. En la nube, lo configuras para que haga referencia a un Servicio de Kubernetes que expone el componente de base de datos a tu clúster. Esto le permite capturar una imagen de contenedor que se ejecuta en la nube y depurar el mismo código exactamente de forma local si es necesario.

Volúmenes persistentes

Los volúmenes definidos y creados como parte del ciclo de vida del pod solo existen hasta que se elimina el pod. 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 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 por el 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 pods de Windows y Linux no pueden compartir volúmenes persistentes debido a diferencias en la compatibilidad del sistema de archivos entre los dos sistemas operativos.

Si quiere una solución totalmente administrada para el acceso de nivel de bloque a los datos, considere la posibilidad de usar Azure Container Storage en lugar de controladores CSI. Azure Container Storage se integra con Kubernetes, lo que permite el aprovisionamiento dinámico y automático de volúmenes persistentes. Azure Container Storage admite discos de Azure, discos efímeros y SAN elástico de Azure (versión preliminar) como almacenamiento de respaldo, lo que ofrece flexibilidad y escalabilidad para las aplicaciones con estado que se ejecutan en clústeres de Kubernetes.

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 política 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.

Para los clústeres que usan Azure Container Storage, verá una clase de almacenamiento adicional denominada acstor-<storage-pool-name>. También se crea una clase de almacenamiento interna.

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

Clase de almacenamiento Descripción
managed-csi Usa el almacenamiento con redundancia local (LRS) de SSD estándar de Azure para crear un disco administrado. La política de recuperación garantiza que el disco de Azure subyacente se elimine cuando se elimine el volumen persistente que lo utilizó. La clase de almacenamiento también configura los volúmenes persistentes que se van a expandir. Puede editar la solicitud 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 Usa el almacenamiento con redundancia local (LRS) de Azure Premium para crear un disco administrado. La política de reclamación asegura nuevamente que se elimine el disco de Azure subyacente cuando se elimine el volumen persistente que lo utilizó. De forma similar, esta clase de almacenamiento permite expandir volúmenes persistentes. Efectivo 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 utiliza almacenamiento con redundancia de zona Premium (ZRS) de Azure para crear discos administrados.
azurefile-csi Usa Azure Standard Storage para crear un recurso compartido de archivos de Azure. La política de reclamación garantiza que, cuando se elimina el volumen persistente que lo utilizó, se elimine también el recurso compartido de archivos de Azure subyacente.
azurefile-csi-premium Usa Azure Premium Storage para crear un recurso compartido de archivos de Azure. La política de reclamación garantiza que el recurso compartido de archivos subyacente de Azure se elimine cuando se elimine el volumen persistente que lo usó.
azureblob-nfs-premium Usa Azure Premium Storage para crear un contenedor de Azure Blob Storage y conectarse mediante el protocolo NFS v3. La política de reclamación garantiza que el contenedor subyacente de Azure Blob Storage se elimine cuando se borra el volumen persistente que lo utilizaba.
azureblob-fuse-premium Usa Azure Premium Storage para crear un contenedor de Azure Blob Storage y conectarse mediante BlobFuse. La política de recuperación garantiza que el contenedor subyacente de almacenamiento de Azure Blob se elimine cuando se elimine el volumen persistente que lo utilizó.

A menos que especifique una clase de almacenamiento para un volumen persistente, se usa la clase de almacenamiento predeterminada. Asegúrese de que los volúmenes usan el almacenamiento adecuado que necesita al solicitar volúmenes persistentes.

Importante: a partir de la versión 1.21 de Kubernetes, AKS usa controladores CSI de forma predeterminada y la migración 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 á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 ejemplo siguiente se usan discos administrados Premium y se especifica que el disco subyacente de Azure Disk debe conservarse al eliminar 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

Tenga en cuenta que AKS reconcilia las clases de almacenamiento predeterminadas y sobrescribirá los cambios que realice en esas clases de almacenamiento.

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

Notificaciones de volúmenes persistentes

Una reclamación de volumen persistente (PVC) solicita almacenamiento de una clase de almacenamiento, un modo de acceso y un tamaño determinados. 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 solicitudes 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
...

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.

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 y las recomendaciones de tamaño para los discos de sistema operativo efímeros están disponibles en la documentación de Azure VM . A continuación se muestran algunas consideraciones generales de ajuste de tamaño:

  • Si decide usar el tamaño de máquina virtual predeterminado de AKS Standard_DS2_v2 SKU con el tamaño de disco del sistema operativo predeterminado de 100 GiB, el tamaño de máquina virtual predeterminado admite sistema operativo efímero, pero solo tiene 86 GiB de tamaño de caché. Esta configuración tendría como valor predeterminado discos administrados si no lo 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 de Standard_D8s_v3 con un disco de sistema operativo de 100 GB, este tamaño de máquina virtual admite el sistema operativo efímero y tiene 200 GiB de espacio en caché. Si no especifica el tipo de disco del sistema operativo, el grupo de nodos recibiría el sistema operativo efímero de forma predeterminada.

La última generación de la serie de máquinas virtuales no tiene una memoria 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 sistema operativo efímeros, pero solo tiene 75 GB de almacenamiento temporal. Esta configuración tendría como valor predeterminado discos del sistema operativo administrados si no lo especifica explícitamente. Si solicita un disco de sistema operativo 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 sistema operativo de 60 GiB, esta configuración tiene como valor predeterminado discos de sistema operativo efímeros. El tamaño solicitado de 60 GiB es menor que el almacenamiento temporal máximo de 75 GiB.
  • Si selecciona Standard_E4bds_v5 SKU con un disco del sistema operativo de 100 GiB, este tamaño de máquina virtual admite sistemas operativos efímeros 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 sistema operativo efímero en el grupo de nodos.

Claves administradas por el cliente

Puede administrar el cifrado del disco del sistema operativo 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 tienen diferentes enfoques disponibles 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 que se asignarán a pods directamente o 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 use, es posible que el controlador CSI de disco de Azure tenga un límite de volumen por nodo. Para algunas máquinas virtuales de alto rendimiento (por ejemplo, 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 para cada SKU de máquina virtual que se ofrece. 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 de Azure Files y Azure NetApp Files.

Azure Disk

De forma predeterminada, un clúster de AKS incluye clases de almacenamiento managed-csi y managed-csi-premium creadas previamente que usan Disk Storage. De forma similar a Amazon EBS, estas clases crean un disco administrado o un dispositivo de bloque que está conectado al nodo para el acceso al pod.

Las clases de almacenamiento de Disk permiten el aprovisionamiento de volúmenes estáticos y dinámicos. La directiva de reclamación garantiza que el disco se elimine con el volumen persistente. Puede expandir el disco editando la notificación de volumen persistente.

Estas clases de almacenamiento usan discos administrados de Azure con almacenamiento con redundancia local (LRS). LRS significa que los datos tienen tres copias sincrónicas dentro de una sola ubicación física en una región primaria de Azure. LRS es la opción de replicación menos costosa, pero no ofrece protección contra un error del centro de datos. Puede definir clases de almacenamiento personalizadas que usen discos administrados de almacenamiento con redundancia de zona (ZRS). El almacenamiento con redundancia de zona (ZRS) replica de forma sincrónica el disco administrado de Azure en tres zonas de disponibilidad de Azure en la región que seleccione. Cada zona de disponibilidad es una ubicación física independiente con alimentación, refrigeración y redes independientes. Los discos ZRS proporcionan al menos 99.99999999999% (12 9's) de durabilidad durante un año determinado. Un disco administrado ZRS se puede conectar mediante una máquina virtual en una zona de disponibilidad diferente. Actualmente, los discos ZRS no están disponibles en todas las regiones de Azure. Para obtener más información sobre los discos ZRS, vea el vídeo Opción de almacenamiento con redundancia de zona (ZRS) para discos de Azure a fin de lograr una alta disponibilidad. Además, para mitigar el riesgo de pérdida de datos, puede realizar copias de seguridad o instantáneas periódicas de datos de Disk Storage mediante Azure Kubernetes Service Backup o soluciones de terceros como Velero o Azure Backup que pueden usar tecnologías de instantánea integradas.

Puede usar Azure Disk para crear un recurso Kubernetes DataDisk. Los tipos de discos incluyen:

Sugerencia

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

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.

Discos v2 SSD de Azure Premium

Los discos SSD prémium v2 de Azure ofrecen cargas de trabajo empresariales intensas en E/S, una latencia de disco inferior a milisegundos coherente, y un alto rendimiento e IOPS. El rendimiento (capacidad, rendimiento e IOPS) de discos SSD prémium v2 se puede configurar de forma independiente en cualquier momento, lo que facilita que más escenarios sean rentables, a la vez que satisfacen las necesidades de rendimiento. Para obtener más información sobre cómo configurar un clúster de AKS nuevo o existente para usar discos v2 SSD de Azure Premium, consulte Uso de discos SSD v2 de Azure Premium en Azure Kubernetes Service.

Almacenamiento en disco Ultra

El Almacenamiento en disco Ultra es un nivel de disco administrado de Azure que ofrece un alto rendimiento, IOPS alto y almacenamiento en disco consistente de baja latencia para VM de Azure. El Almacenamiento en disco Ultra está diseñado para cargas de trabajo que requieren muchos datos y transacciones. Al igual que otras SKU de Disk Storage y Amazon EBS, el Almacenamiento en disco Ultra monta un pod a la vez y no proporciona acceso simultáneo.

Use la marca --enable-ultra-ssd para habilitar el Almacenamiento en disco Ultra en el clúster de AKS.

Si elige Almacenamiento en disco Ultra, tenga en cuenta sus limitaciones y asegúrese de seleccionar un tamaño de VM compatible. El Almacenamiento en disco Ultra está disponible con replicación de almacenamiento con redundancia local (LRS).

Traer sus propias claves (BYOK)

Azure cifra todos los datos de un disco administrado en reposo. De manera predeterminada, los datos se cifran con claves administradas por Microsoft. Para tener más control sobre las claves de cifrado, puede proporcionar claves administradas por el cliente y utilizarlas para el cifrado en reposo del sistema operativo y los discos de datos de los clústeres de AKS. Para obtener más información, consulte Traer sus propias claves (BYOK) con discos administrados de Azure en Azure Kubernetes Service (AKS).

Azure Files

Disk Storage no puede proporcionar acceso simultáneo a un volumen, pero puede usar Azure Files para montar un recurso compartido de Bloque de mensajes del servidor (SMB) versión 3.1.1 o recurso compartido del sistema de archivos de red (NFS) versión 4.1 respaldado por Azure Storage. Este proceso proporciona un almacenamiento conectado a la red similar a Amazon EFS. Al igual que con Disk Storage, hay dos opciones:

  • El almacenamiento Estándar de Azure Files está respaldado por unidades de disco duro (HDD) normales.
  • El almacenamiento Prémium de Azure Files respalda el recurso compartido de archivos con unidades SSD de alto rendimiento. El tamaño mínimo del recurso compartido de archivos para Prémium es de 100 GB.

Azure Files tiene las siguientes opciones de replicación de la cuenta de almacenamiento para proteger los datos en caso de error:

Para optimizar los costos de Azure Files, compre reservas de capacidad de Azure Files.

Azure NetApp Files

Azure NetApp Files es un servicio empresarial de almacenamiento de archivos de alto rendimiento y medido que se ejecuta en Azure y admite volúmenes que usan NFS (NFSv3 o NFSv4.1), SMBy doble protocolo (NFSv3 y SMB, o NFSv4.1 y SMB). Los usuarios de Kubernetes tienen dos opciones para usar volúmenes de Azure NetApp Files para cargas de trabajo de Kubernetes:

  • Crear volúmenes de Azure NetApp Files de manera estática. En este escenario, la creación de volúmenes es externa a AKS. Los volúmenes se crean mediante la CLI de Azure o desde Azure Portal y, a continuación, se exponen a Kubernetes mediante la creación de un PersistentVolume. Los volúmenes de Azure NetApp Files creados estáticamente tienen muchas limitaciones (por ejemplo, incapacidad de expandirse, necesidad de sobreaprovisionarse, etc.). No se recomiendan volúmenes creados estáticamente para la mayoría de los casos de uso.
  • Crear volúmenes de Azure NetApp Files dinámicamente y orquestarlo mediante Kubernetes. Este método es la forma preferida para crear múltiples volúmenes directamente a través de Kubernetes, y se logra utilizando Astra Trident. Astra Trident es un orquestador de almacenamiento dinámico compatible con CSI que ayuda a aprovisionar volúmenes de forma nativa a través de Kubernetes.

Para obtener más información, consulte Configuración de Azure NetApp Files para Azure Kubernetes Service.

Almacenamiento de blobs de Azure

El controlador Azure Blob Storage Container Storage Interface (CSI) es un controlador compatible con la especificación CSI utilizado por Azure Kubernetes Service (AKS) para administrar el ciclo de vida del almacenamiento de Azure Blob. CSI es un estándar para exponer sistemas arbitrarios de almacenamiento de archivos y bloques a cargas de trabajo en contenedores en Kubernetes.

Al adoptar y usar CSI, AKS ahora puede escribir, implementar e iterar complementos para exponer nuevos o mejorar los sistemas de almacenamiento existentes en Kubernetes. El uso de controladores CSI en AKS evita tener que tocar el código principal de Kubernetes y esperar sus ciclos de lanzamiento.

Al montar Azure Blob Storage como un sistema de archivos en un contenedor o pod, permite usar Blob Storage con una serie de aplicaciones que funcionan grandes cantidades de datos no estructurados. Por ejemplo:

  • Datos del archivo de registro
  • Imágenes, documentos y streaming de vídeo o audio
  • Datos de recuperación ante desastres

Se puede acceder a los datos del almacenamiento de objetos mediante aplicaciones que usan el protocolo BlobFuse o Network File System (NFS) 3.0. Antes de la introducción del controlador CSI de Azure Blob Storage, la única opción era instalar manualmente un controlador no compatible para acceder a Blob Storage desde la aplicación que se ejecuta en AKS. Cuando el controlador CSI de Azure Blob Storage está habilitado en AKS, hay dos clases de almacenamiento integradas: azureblob-fuse-premium y azureblob-nfs-premium.

Para crear un clúster de AKS con compatibilidad con controladores CSI, consulte Controladores CSI en AKS. Para más información sobre las diferencias de acceso entre cada uno de los tipos de almacenamiento de Azure mediante el protocolo NFS, consulte Comparación del acceso a Azure Files, Blob Storage y Azure NetApp Files con NFS.

Azure HPC Cache

Azure HPC Cache acelera el acceso a los datos para las tareas de HPC, con toda la escalabilidad de las soluciones en la nube. Si elige esta solución de almacenamiento, asegúrese de implementar el clúster de AKS en una región que admita caché HPC de Azure.

Servidor NFS

La mejor opción para el acceso NFS compartido es usar Azure Files o Azure NetApp Files. También puede crear un servidor NFS en una VM de Azure que exporte volúmenes.

Tenga en cuenta que esta opción solo admite el aprovisionamiento estático. Debe aprovisionar los recursos compartidos NFS manualmente en el servidor y no puede hacerlo desde AKS automáticamente.

Esta solución se basa en la infraestructura como servicio (IaaS) en lugar de en la plataforma como servicio (PaaS). Usted es el responsable de administrar el servidor NFS, incluidas las actualizaciones del SO, la alta disponibilidad, las copias de seguridad, la recuperación ante desastres y la escalabilidad.

Trae tus propias claves (BYOK) con discos de Azure

Azure Storage cifra todos los datos de una cuenta de almacenamiento en reposo, incluidos el sistema operativo y los discos de datos de un clúster de AKS. De manera predeterminada, los datos se cifran con claves administradas por Microsoft. Para obtener más control sobre las claves de cifrado, puede proporcionar claves administradas por el cliente para usarlas para el cifrado en reposo del sistema operativo y los discos de datos de los clústeres de AKS. Para más información, vea:

Azure Container Storage

Azure Container Storage es un servicio de administración, implementación y orquestación de volúmenes basado en la nube creado de forma nativa para contenedores. Se integra con Kubernetes, lo que le permite aprovisionar volúmenes persistentes de forma dinámica y automática para almacenar datos para aplicaciones con estado que se ejecutan en clústeres de Kubernetes.

Azure Container Storage utiliza ofertas de Azure Storage existentes para el almacenamiento de datos real y ofrece una solución de orquestación y administración de volúmenes creada específicamente para contenedores. Entre las opciones de almacenamiento auxiliares admitidas se incluyen:

  • Azure Disks: control exhaustivo de las SKU y las configuraciones de almacenamiento. Están previstos para bases de datos de uso general y de nivel 1.
  • Discos efímeros: usa recursos de almacenamiento local en nodos de AKS (NVMe o SSD temporal). Se adapta mejor a las aplicaciones sin necesidad de que haya durabilidad en los datos ni compatibilidad integrada con la replicación de datos. AKS detecta el almacenamiento efímero disponible en los nodos de AKS y los adquiere para la implementación de volúmenes.
  • Azure Elastic SAN: aprovisiona recursos totalmente administrados a petición. Sirve para bases de datos de uso general, servicios de streaming y mensajería, entornos de CD/CI y otras cargas de trabajo de nivel 1/2. Varios clústeres pueden acceder simultáneamente a una sola SAN, pero los volúmenes persistentes solo se pueden adjuntar por un consumidor a la vez.

Hasta ahora, proporcionar almacenamiento en la nube para contenedores requería utilizar controladores de Container Storage Interface (CSI) individuales para utilizar servicios de almacenamiento destinados a cargas de trabajo centradas en la infraestructura como servicio (Iaas) y hacer que funcionaran para contenedores. Esto genera sobrecarga operativa y aumenta el riesgo de problemas de disponibilidad, escalabilidad, rendimiento, facilidad de uso y coste de las aplicaciones.

Azure Container Storage se deriva de OpenEBS, una solución de código abierto que proporciona funcionalidades de almacenamiento de contenedores para Kubernetes. Al ofrecer una solución de orquestación de volúmenes administrada a través de controladores de almacenamiento basados en microservicios en un entorno de Kubernetes, Azure Container Storage habilita el almacenamiento nativo de contenedor verdadero.

Se puede usar Azure Container Storage en los siguientes escenarios:

  • Acelerar las iniciativas de VM a contenedores: Azure Container Storage pone a disposición de los contenedores toda la gama de ofertas de almacenamiento en bloque de Azure que antes solo estaban disponibles para máquinas virtuales. Esto incluye un disco efímero que proporciona una latencia extremadamente baja para cargas de trabajo como Cassandra, así como Azure Elastic SAN que proporciona destinos aprovisionados compartidos e iSCSI nativos.

  • Simplificar la administración de volúmenes con Kubernetes: Al proporcionar la orquestación de volúmenes a través del plano de control de Kubernetes, Azure Container Storage facilita la implementación y la administración de volúmenes dentro de Kubernetes, sin necesidad de moverse entre diferentes planos de control.

  • Reducir el costo total de propiedad (TCO): Mejore la rentabilidad aumentando la escala de volúmenes persistentes admitidos por pod o nodo. Reduzca los recursos de almacenamiento necesarios para el aprovisionamiento mediante el uso compartido dinámico de recursos de almacenamiento. Tenga en cuenta que no se admite la compatibilidad con el escalado vertical para el propio bloque de almacenamiento.

Azure Container Storage ofrece las siguientes ventajas principales:

  • Escalado horizontal rápido de pods con estado: Azure Container Storage monta los volúmenes persistentes a través de los protocolos de almacenamiento en bloques de red (NVMe-oF o iSCSI), lo que ofrece una asociación y desasociación rápida de volúmenes persistentes. Puede empezar poco a poco e ir implementando recursos a medida que los vaya necesitando, a la vez que se asegura de que sus aplicaciones no estén inactivas o interrumpidas, ya sea durante la inicialización o en producción. La resistencia de las aplicaciones se mejora con la regeneración (respawns) de pods en todo el clúster, lo que requiere un movimiento rápido de los volúmenes persistentes. Al usar los protocolos de red remotos, Azure Container Storage se acopla estrechamente con el ciclo de vida de los pods para admitir aplicaciones con estado de alta resiliencia y a gran escala en AKS.

  • Rendimiento mejorado para cargas de trabajo con estado: Azure Container Storage permite un rendimiento de lectura superior y proporciona un rendimiento de escritura parecido al de un disco utilizando NVMe-oF sobre RDMA. Esto permite a los clientes responder de forma rentable a los requisitos de rendimiento de las distintas cargas de trabajo de los contenedores, incluidas las de nivel 1, intensivas en E/S, de uso general, sensibles al rendimiento y de desarrollo/prueba. Acorte el tiempo de asociación o desasociación de volúmenes persistentes y reduzca el tiempo de conmutación por error de pods.

  • Orquestación de volúmenes nativa de Kubernetes: Cree grupos de almacenamiento y volúmenes persistentes, capture instantáneas y administre todo el ciclo de vida de los volúmenes mediante comandos kubectl sin cambiar entre conjuntos de herramientas para diferentes operaciones del plano de control.

Soluciones de terceros

Al igual que Amazon EKS, AKS es una implementación de Kubernetes y puede integrar soluciones de almacenamiento de Kubernetes de terceros. Estos son algunos ejemplos de soluciones de almacenamiento de terceros para Kubernetes:

  • Rook convierte los sistemas de almacenamiento distribuidos en servicios de almacenamiento autoadministrados mediante la automatización de tareas de administrador de almacenamiento. Rook ofrece sus servicios a través de un operador de Kubernetes para cada proveedor de almacenamiento.
  • GlusterFS es un sistema de archivos de red escalable de código abierto y gratuito que usa hardware comercial común para crear soluciones de almacenamiento grandes y distribuidas para tareas que consumen mucho ancho de banda y datos.
  • Ceph proporciona un servicio de almacenamiento unificado confiable y escalable con interfaces de objetos, bloques y archivos de un único clúster creado a partir de componentes de hardware básicos.
  • El almacenamiento de objetos multinube MinIO permite a las empresas crear una infraestructura de datos compatible con AWS S3 en cualquier nube, lo que proporciona una interfaz consistente y portátil para los datos y las aplicaciones.
  • Portworx es una solución de administración de datos y almacenamiento de un extremo a otro para proyectos de Kubernetes e iniciativas basadas en contenedores. Portworx ofrece almacenamiento pormenorizado en contenedores, recuperación ante desastres, seguridad de datos y migraciones multinube.
  • Quobyte proporciona almacenamiento de objetos y archivos de alto rendimiento que puede implementar en cualquier servidor o nube para escalar el rendimiento, administrar grandes cantidades de datos y simplificar la administración.
  • Ondat ofrece una capa de almacenamiento consistente en cualquier plataforma. Puede ejecutar una base de datos o cualquier carga de trabajo persistente en un entorno de Kubernetes sin tener que administrar la capa de almacenamiento.

Consideraciones sobre el almacenamiento de Kubernetes

Tenga en cuenta los siguientes factores al elegir una solución de almacenamiento para Amazon EKS o AKS.

Modos de acceso de clase de almacenamiento

En la versión 1.21 de Kubernetes y versiones más recientes, las clases de almacenamiento de AKS y Amazon EKS usan controladores de Container Storage Interface (CSI) solamente y de forma predeterminada.

Los distintos servicios admiten clases de almacenamiento que tienen diferentes modos de acceso.

Servicio ReadWriteOnce ReadOnlyMany ReadWriteMany
Azure Disks X
Azure Files X X X
Azure NetApp Files X X X
Servidor NFS X X X
Azure HPC Cache X X X

Aprovisionamiento dinámico frente a estático

Aprovisione volúmenes de forma dinámica para reducir la sobrecarga de administración de la creación estática de volúmenes persistentes. Establezca una directiva de reclamación correcta para evitar tener discos sin usar al eliminar pods.

Copia de seguridad

Elija una herramienta para realizar copias de seguridad de datos persistentes. La herramienta debe coincidir con el tipo de almacenamiento, como instantáneas, Azure Backup, Velero o Kasten.

Optimización de costos

Para optimizar los costos de Azure Storage, use las reservas de Azure. Asegúrese de comprobar qué servicios admiten Azure Reservations. Consulte también Administración de costos para un clúster de Kubernetes.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes