Almacenamiento

Descripción general

Hay situaciones en las que es posible que desee ejecutar aplicaciones que necesiten conservar los datos a corto o largo plazo. Para estos casos de uso, los pods pueden definir y montar los volúmenes para que sus contenedores puedan acceder a diferentes mecanismos de almacenamiento. Kubernetes admite diferentes tipos de volúmenes para el almacenamiento efímero y persistente. La elección del almacenamiento depende en gran medida de los requisitos de la aplicación. Cada enfoque tiene implicaciones en términos de costos y las prácticas que se detallan a continuación le ayudarán a lograr la rentabilidad de las cargas de trabajo que necesitan algún tipo de almacenamiento en sus entornos de EKS.

Volúmenes efímeros

Los volúmenes efímeros son para aplicaciones que requieren volúmenes locales transitorios, pero que no requieren que los datos se conserven después de reiniciarse. Algunos ejemplos de ello son los requisitos de espacio libre, el almacenamiento en caché y los datos de entrada de solo lectura, como los datos de configuración y los secretos. Puedes encontrar más información sobre los volúmenes efímeros de Kubernetes aquí. La mayoría de los volúmenes efímeros (por ejemplo, emptyDir, ConfigMap, DownwardAPI, secret, hostpath) están respaldados por dispositivos grabables conectados localmente (normalmente el disco raíz) o RAM, por lo que es importante elegir el volumen de host más rentable y con mejor rendimiento.

Uso de volúmenes de EBS

Recomendamos empezar con gp3 como volumen raíz del host. Es el último volumen SSD de uso general ofrecido por Amazon EBS y también ofrece un precio más bajo (hasta un 20%) por GB en comparación con los volúmenes gp2.

Uso de Amazon EC2 Instance Stores

Los almacenes de EC2 instancias de Amazon proporcionan almacenamiento temporal a nivel de bloque para tus EC2 instancias. Se puede acceder al almacenamiento que proporcionan los almacenes de EC2 instancias a través de discos que están conectados físicamente a los hosts. A diferencia de Amazon EBS, solo puede adjuntar volúmenes del almacén de instancias cuando se lanza la instancia, y estos volúmenes solo existen durante la vida útil de la instancia. No se pueden separar ni volver a conectar a otras instancias. Puedes obtener más información sobre los almacenes de EC2 instancias de Amazon aquí. No hay cargos adicionales asociados al volumen de un almacén de instancias. Esto las hace (volúmenes de almacenamiento de instancias) más rentables que las EC2 instancias generales con grandes volúmenes de EBS.

Para usar volúmenes de almacenamiento local en Kubernetes, debes particionar, configurar y formatear los discos con los EC2 datos de usuario de Amazon para que los volúmenes se puedan montar según las especificaciones del pod HostPath. Como alternativa, puedes aprovechar el aprovisionador estático de volúmenes persistentes locales para simplificar la administración del almacenamiento local. El aprovisionador estático de volúmenes persistentes locales le permite acceder a los volúmenes de los almacenes de instancias locales a través de la interfaz estándar de Kubernetes PersistentVolumeClaim (PVC). Además, proporcionará PersistentVolumes (PVs), que contiene información sobre la afinidad de los nodos, para programar los pods en los nodos correctos. Aunque usa Kubernetes PersistentVolumes, los volúmenes de los almacenes de EC2 instancias son de naturaleza efímera. Los datos escritos en discos efímeros solo están disponibles durante la vida útil de la instancia. Cuando la instancia finaliza, también lo hacen los datos. Consulte este blog para obtener más información.

Ten en cuenta que cuando usas volúmenes del almacén de EC2 instancias de Amazon, el límite total de IOPS se comparte con el host y vincula los pods a un host específico. Debe revisar minuciosamente sus requisitos de carga de trabajo antes de adoptar los volúmenes de almacenes de EC2 instancias de Amazon.

Volúmenes persistentes

Kubernetes suele estar asociado a la ejecución de aplicaciones sin estado. Sin embargo, hay situaciones en las que es posible que desee ejecutar microservicios que necesiten conservar los datos o la información persistentes de una solicitud a otra. Las bases de datos son un ejemplo habitual de estos casos de uso. Sin embargo, los pods y los contenedores o procesos que contienen son de naturaleza efímera. Para conservar los datos más allá de la vida útil de un pod, puedes definir el acceso al almacenamiento en una ubicación específica que sea independiente del pod. PVs Los costes asociados PVs dependen en gran medida del tipo de almacenamiento que se utilice y de cómo lo consuman las aplicaciones.

Aquí se enumeran diferentes tipos de opciones de almacenamiento compatibles con Kubernetes en PVs Amazon EKS. Las opciones de almacenamiento que se describen a continuación son Amazon EBS, Amazon EFS, Amazon FSx for Lustre y Amazon FSx for NetApp ONTAP.

Volúmenes de Amazon Elastic Block Store (EBS)

Los volúmenes de Amazon EBS se pueden consumir como Kubernetes PVs para proporcionar volúmenes de almacenamiento a nivel de bloque. Son ideales para bases de datos que se basan en lecturas y escrituras aleatorias y para aplicaciones de alto rendimiento que realizan lecturas y escrituras prolongadas y continuas. El controlador de la interfaz de almacenamiento de contenedores (CSI) de Amazon Elastic Block Store permite a los clústeres de Amazon EKS gestionar el ciclo de vida de los volúmenes de Amazon EBS para los volúmenes persistentes. La interfaz de almacenamiento en contenedores permite y facilita la interacción entre Kubernetes y un sistema de almacenamiento. Cuando se implementa un controlador CSI en su clúster de EKS, puede acceder a sus capacidades a través de los recursos de almacenamiento nativos de Kubernetes, como Persistent Volumes (PVs), Persistent Volume Claims () y Storage Classes (PVCs). SCs Este enlace proporciona ejemplos prácticos de cómo interactuar con los volúmenes de Amazon EBS con el controlador CSI de Amazon EBS.

Elegir el volumen correcto

Recomendamos utilizar la última generación de almacenamiento en bloque (gp3), ya que proporciona el equilibrio adecuado entre precio y rendimiento. También le permite escalar el volumen de IOPS y el rendimiento independientemente del tamaño del volumen sin necesidad de aprovisionar capacidad adicional de almacenamiento en bloques. Si actualmente utiliza volúmenes gp2, le recomendamos encarecidamente que migre a los volúmenes gp3. En la entrada del blog Migración de clústeres de Amazon EKS de volúmenes de EBS de gp2 a gp3 se explica cómo migrar de gp2 a gp3 en clústeres de Amazon EKS con copias de seguridad y restauración mediante la función CSI Volume Snapshots, que requiere tiempo de inactividad de las aplicaciones.

Amazon EBS permite cambiar las características del volumen, como el tamaño del volumen, las IOPS y el rendimiento en línea. Al utilizar esta función, se puede migrar de gp2 a gp3 sin tiempo de inactividad de la aplicación mediante anotaciones de PVC, tal como se describe en este blog, que requiere el controlador CSI de EBS v1.19.0+, o empezando por Amazon EKS v1.31 y el controlador CSI de EBS 1.35 mediante la API, tal como se describe aquí. VolumeAttributesClass

Si tiene aplicaciones que requieren un mayor rendimiento y necesitan volúmenes superiores a los que puede admitir un único volumen de gp3, debería considerar la posibilidad de utilizar io2 block express. Este tipo de almacenamiento es ideal para su implementación más grande, de mayor intensidad de E/S y de misión crítica, como SAP HANA u otras bases de datos grandes con requisitos de baja latencia. Tenga en cuenta que el rendimiento de EBS de una instancia está limitado por los límites de rendimiento de la instancia, por lo que no todas las instancias admiten los volúmenes express de bloques de io2. Puedes comprobar los tipos de instancias compatibles y otras consideraciones en este documento.

Un único volumen gp3 puede admitir hasta 16 000 IOPS como máximo, 1 000 IOPS de rendimiento y MiB/s max throughput, max 16TiB. The latest generation of Provisioned IOPS SSD volume that provides up to 256,000 IOPS, 4,000 MiB/s 64 TiB.

Entre estas opciones, es la que mejor adapta el rendimiento y el coste del almacenamiento a las necesidades de sus aplicaciones.

Supervise y optimice a lo largo del tiempo

Es importante comprender el rendimiento básico de la aplicación y monitorizarla para ver si hay volúmenes seleccionados para comprobar si cumple con sus requisitos o expectativas o si está sobreaprovisionada (por ejemplo, en un escenario en el que las IOPS aprovisionadas no se utilizan al máximo).

En lugar de asignar un gran volumen desde el principio, puede aumentar gradualmente el tamaño del volumen a medida que acumula datos. Puede cambiar el tamaño de los volúmenes de forma dinámica mediante la función de redimensionamiento de volúmenes del controlador CSI de Amazon Elastic Block Store ()aws-ebs-csi-driver. Tenga en cuenta que solo puede aumentar el tamaño del volumen de EBS.

Para identificar y eliminar cualquier volumen de EBS pendiente, puede utilizar la categoría de optimización de costes de AWS Trusted Advisor. Esta función le ayuda a identificar los volúmenes independientes o los volúmenes con una actividad de escritura muy baja durante un período de tiempo. Existe una herramienta de solo lectura y código abierto nativa de la nube llamada Popeye que escanea los clústeres de Kubernetes activos e informa sobre posibles problemas con los recursos y las configuraciones desplegados. Por ejemplo, puede buscar los elementos no utilizados PVs PVCs y comprobar si están enlazados o si hay algún error al montar el volumen.

Para obtener información detallada sobre la monitorización, consulte la guía de observabilidad de la optimización de costes de EKS.

Otra opción que puede considerar son las recomendaciones de volumen de AWS Compute Optimizer para Amazon EBS. Esta herramienta identifica automáticamente la configuración de volumen óptima y el nivel correcto de rendimiento necesario. Por ejemplo, se puede utilizar para configurar de forma óptima las IOPS aprovisionadas, los tamaños de los volúmenes y los tipos de volúmenes de EBS, en función de la utilización máxima durante los últimos 14 días. También cuantifica los posibles ahorros de costos mensuales derivados de sus recomendaciones. Puede revisar este blog para obtener más detalles.

Política de retención de copias de seguridad

Puede realizar copias de seguridad de los datos de sus volúmenes de Amazon EBS realizando point-in-time instantáneas. El controlador CSI de Amazon EBS admite instantáneas de volumen. Puede obtener información sobre cómo crear una instantánea y restaurar un EBS PV siguiendo los pasos que se describen aquí.

Las instantáneas posteriores son copias de seguridad incrementales, lo que significa que solo se guardan los bloques del dispositivo que han cambiado después de la instantánea más reciente. Esto disminuye el tiempo necesario para crearlo y ahorra costos de almacenamiento, ya que no se duplican los datos. Sin embargo, aumentar el número de instantáneas antiguas de EBS sin una política de retención adecuada puede generar costes inesperados al operar a gran escala. Si va a realizar copias de seguridad de los volúmenes de Amazon EBS directamente a través de la API de AWS, puede utilizar Amazon Data Lifecycle Manager (DLM), que proporciona una solución de gestión del ciclo de vida automatizada y basada en políticas para las instantáneas de Amazon Elastic Block Store (EBS) y las Amazon Machine Images () respaldadas por EBS (). AMIs La consola facilita la automatización de la creación, la retención y la eliminación de las instantáneas de EBS y. AMIs

nota

Actualmente no hay forma de utilizar Amazon DLM a través del controlador CSI de Amazon EBS.

En un entorno de Kubernetes, puede utilizar una herramienta de código abierto llamada Velero para hacer copias de seguridad de sus volúmenes persistentes de EBS. Puede establecer un indicador TTL al programar el trabajo para que caduque las copias de seguridad. He aquí una guía de Velero como ejemplo.

Amazon Elastic File System (EFS)

Amazon Elastic File System (EFS) es un sistema de archivos totalmente elástico y sin servidor que le permite compartir datos de archivos mediante una interfaz de sistema de archivos estándar y una semántica del sistema de archivos para una amplia gama de cargas de trabajo y aplicaciones. Algunos ejemplos de cargas de trabajo y aplicaciones incluyen Wordpress y Drupal, herramientas para desarrolladores como JIRA y Git, y sistemas de libretas compartidas como Jupyter, así como directorios principales.

Una de las principales ventajas de Amazon EFS es que se puede montar en varios contenedores repartidos en varios nodos y varias zonas de disponibilidad. Otra ventaja es que solo paga por el almacenamiento que utilice. Los sistemas de archivos EFS crecerán y se reducirán automáticamente a medida que añada y elimine archivos, lo que elimina la necesidad de planificar la capacidad.

Para utilizar Amazon EFS en Kubernetes, debe utilizar el controlador Amazon Elastic File System Container Storage Interface (CSI),. aws-efs-csi-driver Actualmente, el controlador puede crear puntos de acceso de forma dinámica. Sin embargo, primero se debe aprovisionar el sistema de archivos Amazon EFS y proporcionarlo como entrada al parámetro de clase de almacenamiento de Kubernetes.

Cómo elegir la clase de almacenamiento EFS adecuada

Amazon EFS ofrece cuatro clases de almacenamiento.

Dos clases de almacenamiento estándar:

• Estándar Amazon EFS

• Amazon EFS Standard-Infrequent Access (EFS Standard-IA)

Dos clases de almacenamiento de una zona:

• Amazon EFS One Zone

• Amazon EFS One Zone-Infrequent Access (EFS One Zone-IA)

Las clases de almacenamiento de acceso infrecuente (IA) optimizan los costos para los archivos a los que no se accede todos los días. Con la administración del ciclo de vida de Amazon EFS, puede mover los archivos a los que no se haya accedido durante la vigencia de la política de ciclo de vida (7, 14, 30, 60 o 90 días) a las clases de almacenamiento de IA, lo que puede reducir el costo de almacenamiento hasta un 92 por ciento en comparación con las clases de almacenamiento EFS Standard y EFS One Zone, respectivamente.

Con EFS Intelligent-Tiering, la administración del ciclo de vida supervisa los patrones de acceso de su sistema de archivos y mueve automáticamente los archivos a la clase de almacenamiento más óptima.

nota

aws-efs-csi-driver actualmente no controla los cambios en las clases de almacenamiento, la administración del ciclo de vida ni la organización inteligente por niveles. Deben configurarse manualmente en la consola de AWS o mediante EFS APIs.

nota

aws-efs-csi-driver no es compatible con las imágenes de contenedores basadas en Windows.

nota

Existe un problema conocido de memoria cuando vol-metrics-opt-in(emitir métricas de volumen) está habilitada debido a que la DiskUsagefunción consume una cantidad de memoria proporcional al tamaño del sistema de archivos. Actualmente, recomendamos desactivar la opción `-- vol-metrics-opt-in `en sistemas de archivos de gran tamaño para evitar consumir demasiada memoria. Aquí tienes un enlace a un problema de GitHub para obtener más información.

Amazon FSx para Lustre

Lustre es un sistema de archivos paralelos de alto rendimiento que se utiliza habitualmente en cargas de trabajo que requieren un rendimiento de hasta cientos de GB/s y latencias inferiores a un milisegundo por operación. Se utiliza para escenarios como la formación en aprendizaje automático, la elaboración de modelos financieros, la HPC y el procesamiento de vídeo. Amazon FSx for Lustre proporciona un almacenamiento compartido totalmente gestionado con escalabilidad y rendimiento integrados a la perfección con Amazon S3.

Puede usar los volúmenes de almacenamiento persistente de Kubernetes respaldados por FSx for Lustre mediante el FSx controlador CSI for Lustre de Amazon EKS o su clúster de Kubernetes autogestionado en AWS. Consulte la documentación de Amazon EKS para obtener más detalles y ejemplos.

Enlace a Amazon S3

Se recomienda vincular un repositorio de datos de larga duración y larga duración que resida en Amazon S3 con su sistema de archivos FSx for Lustre. Una vez enlazados, los conjuntos de datos de gran tamaño se cargan de forma diferida según sea necesario desde Amazon S3 hasta los sistemas de archivos FSx Lustre. También puede volver a ejecutar los análisis y los resultados en S3 y, a continuación, eliminar el sistema de archivos de Lustre.

Elegir las opciones de despliegue y almacenamiento adecuadas

FSx for Lustre ofrece diferentes opciones de despliegue. La primera opción se llama scratch y no replica los datos, mientras que la segunda opción se llama persistente, que, como su nombre lo indica, conserva los datos.

La primera opción (scratch) se puede utilizar para reducir el coste del procesamiento temporal de datos a corto plazo. La opción de implementación persistente está diseñada para un almacenamiento a largo plazo que replica automáticamente los datos dentro de una zona de disponibilidad de AWS. También es compatible con el almacenamiento en SSD y en disco duro.

Puede configurar el tipo de despliegue deseado en los parámetros de Kubernetes del sistema de archivos FSx for lustre. StorageClass Aquí hay un enlace que proporciona plantillas de muestra.

nota

Para las cargas de trabajo sensibles a la latencia o las cargas de trabajo que requieren los niveles más altos de IOPs/rendimiento, debe elegir el almacenamiento SSD. Para las cargas de trabajo centradas en el rendimiento y que no son sensibles a la latencia, debe elegir el almacenamiento en disco duro.

Habilite la compresión de datos

También puede habilitar la compresión de datos en su sistema de archivos especificando LZ4 "» como tipo de compresión de datos. Una vez activado, todos los archivos recién escritos se comprimirán automáticamente FSx para Lustre antes de escribirse en el disco y se descomprimirán cuando se lean. LZ4 El algoritmo de compresión de datos no tiene pérdidas, por lo que los datos originales se pueden reconstruir completamente a partir de los datos comprimidos.

Puede configurar el tipo de compresión de datos como se indica en los parámetros LZ4 del Kubernetes del sistema de FSx archivos for lustre. StorageClass La compresión se desactiva cuando el valor se establece en NONE, que es el valor predeterminado. Este enlace proporciona plantillas de ejemplo.

nota

Amazon FSx for Lustre no es compatible con las imágenes de contenedores basadas en Windows.

Amazon FSx para NetApp ONTAP

Amazon FSx for NetApp ONTAP es un almacenamiento compartido totalmente gestionado que se basa en el sistema NetApp de archivos ONTAP. FSx for ONTAP proporciona un almacenamiento de archivos compartido rápido, flexible y rico en funciones al que se puede acceder fácilmente desde instancias informáticas de Linux, Windows y macOS que se ejecutan en AWS o de forma local.

Amazon FSx for NetApp ONTAP admite dos niveles de almacenamiento: 1 nivel principal y 2 niveles de grupo de capacidad.

El nivel principal es un nivel aprovisionado y basado en SSD de alto rendimiento para datos activos y sensibles a la latencia. El nivel del pool de capacidad, totalmente elástico, optimiza los costes para los datos a los que se accede con poca frecuencia, se escala automáticamente a medida que los datos se agrupan en niveles y ofrece petabytes de capacidad prácticamente ilimitados. Puede habilitar la compresión y la deduplicación de datos en el almacenamiento del pool de capacidad y reducir aún más la cantidad de capacidad de almacenamiento que consumen sus datos. NetAppSu FabricPool función nativa basada en políticas monitorea continuamente los patrones de acceso a los datos y los transfiere automáticamente de forma bidireccional entre los niveles de almacenamiento para optimizar el rendimiento y los costes.

NetAppde Astra Trident ofrece una organización dinámica del almacenamiento mediante un controlador CSI que permite a los clústeres EKS de Amazon gestionar el ciclo de vida de los volúmenes persistentes respaldados PVs por Amazon FSx para los sistemas de archivos NetApp ONTAP. Para empezar, consulta Cómo usar el Astra Trident con Amazon FSx para NetApp ONTAP en la documentación del Astra Trident.

Otras consideraciones

Minimice el tamaño de la imagen del contenedor

Una vez desplegados los contenedores, las imágenes de los contenedores se almacenan en caché en el host en varias capas. Al reducir el tamaño de las imágenes, se puede reducir la cantidad de almacenamiento necesaria en el host.

Al utilizar desde el principio imágenes básicas reducidas, como imágenes de borrador o imágenes de contenedores sin distribución (que solo contienen su aplicación y sus funciones de ejecución), puede reducir los costes de almacenamiento, además de otras ventajas adicionales, como la reducción del área de superficie de ataque y la reducción de los tiempos de extracción de imágenes.

También debería considerar la posibilidad de utilizar herramientas de código abierto, como Slim.ai, que proporciona una forma fácil y segura de crear imágenes mínimas.

Varias capas de paquetes, herramientas, dependencias de aplicaciones y bibliotecas pueden aumentar fácilmente el tamaño de la imagen del contenedor. Al usar compilaciones de varias etapas, puedes copiar artefactos de forma selectiva de una etapa a otra, excluyendo todo lo que no sea necesario de la imagen final. Puedes consultar más prácticas recomendadas para la creación de imágenes aquí.

Otra cosa a tener en cuenta es cuánto tiempo se deben conservar las imágenes en caché. Es posible que desee limpiar las imágenes obsoletas de la memoria caché de imágenes cuando se utilice cierta cantidad de disco. Si lo hace, le ayudará a asegurarse de que dispone de suficiente espacio para el funcionamiento del host. De forma predeterminada, el kubelet recolecta basura en las imágenes no utilizadas cada cinco minutos y en los contenedores no utilizados cada minuto.

Para configurar las opciones de recolección de basura de contenedores e imágenes no utilizadas, ajuste el kubelet mediante un archivo de configuración y cambie los parámetros relacionados con la recolección de basura utilizando el tipo de recurso. KubeletConfiguration

Puedes obtener más información al respecto en la documentación de Kubernetes.