Las unidades de estado sólido (SSDs) locales son unidades de tamaño fijo, que se pueden activar en una sola VM de Compute Engine. Puedes usar SSDs locales en GKE para obtener almacenamiento de alto rendimiento que no sea persistente (efímero) que esté conectado a cada nodo de tu clúster. Las SSDs locales también proporcionan mayor capacidad de procesamiento y menor latencia que los discos estándar.
En la versión 1.25.3-gke.1800 y en las posteriores, puedes configurar un grupo de nodos de GKE para usar una SSD local con una interfaz NVMe para el almacenamiento efímero local o el almacenamiento en bloque sin procesar.
Si usas GKE con clústeres Estándar, puedes conectar SSDs locales a los nodos cuando creas grupos de nodos. Esto mejora el rendimiento del almacenamiento efímero para las cargas de trabajo que usan volúmenes de emptyDir o PersistentVolumes locales. Puedes crear grupos de nodos con SSDs locales dentro de los límites del tipo de máquina de tu clúster y las cuotas de tu proyecto.
Una SSD local se conecta a un solo nodo y los nodos son efímeros. Una carga de trabajo se puede programar en un nodo diferente en cualquier momento.
Para obtener más información sobre los beneficios y las limitaciones de las SSDs locales, como el rendimiento y la cantidad permitida de SSD por tipo de máquina, consulta SSDs locales en la documentación de Compute Engine.
Por qué elegir SSDs locales para GKE
Las SSDs locales son una buena opción cuando tus cargas de trabajo tienen alguno de los siguientes requisitos:
- Deseas ejecutar aplicaciones que descarguen y procesen datos, como IA o aprendizaje automático, estadísticas, procesamiento por lotes, almacenamiento en caché local y bases de datos en la memoria.
- Tus aplicaciones tienen necesidades de almacenamiento especializadas y deseas acceso a bloques sin procesar en almacenamiento efímero de alto rendimiento.
- Deseas ejecutar aplicaciones de datos especializadas y operar volúmenes de SSDs locales como una caché a nivel de nodo para tus Pods. Puedes usar este enfoque para mejorar el rendimiento de las aplicaciones de bases de datos en la memoria, como Aerospike o Redis.
Almacenamiento efímero
Te recomendamos usar la opción --ephemeral-storage-local-ssd a fin de aprovisionar SSDs locales para el almacenamiento efímero del nodo (este es el valor predeterminado si usas una máquina de la serie de tercera generación).
Este enfoque coloca los volúmenes emptyDir, las capas que admiten escritura de contenedores y las imágenes que constituyen el almacenamiento efímero del nodo en SSDs locales. Los beneficios incluyen un ancho de banda de E/S mejor que el de Persistent Disk predeterminado y tiempos de inicio mejorados del Pod.
El uso de SSDs locales para el almacenamiento efímero del nodo significa que los volúmenes de SSDs locales de disco de arranque no están disponibles para otros usos. No modifiques el disco de arranque directamente mediante un Daemonset, un HostPath o algún otro mecanismo con privilegios, de lo contrario, el nodo puede fallar. Si necesitas un control detallado sobre los volúmenes de SSDs locales, usa el enfoque de bloque sin procesar.
Almacenamiento en dispositivo de almacenamiento en bloques
El almacenamiento en dispositivo de almacenamiento en bloques permite el acceso aleatorio a los datos en bloques de tamaño fijo. Algunas aplicaciones especializadas requieren acceso directo a dispositivos de almacenamiento en bloques porque, por ejemplo, la capa del sistema de archivos genera una sobrecarga innecesaria.
Los casos comunes para usar el almacenamiento en dispositivos de almacenamiento en bloques son los siguientes:
- Bases de datos en las que los datos se organizan directamente en el almacenamiento subyacente.
- Software que implementa algún tipo de servicio de almacenamiento (sistemas de almacenamiento definidos por software).
En la versión v1.25.3-gke.1800 y posteriores de GKE, puedes crear clústeres y grupos de nodos con SSDs locales de NVMe de bloque sin procesar conectados mediante la opción --local-nvme-ssd-block. Luego, puedes personalizar el almacenamiento en bloque mediante el formateo de un sistema de archivos de elección (como ZFS o HDFS) y la configuración de RAID. Esta opción es adecuada si necesitas control adicional para ejecutar cargas de trabajo que requieren acceso específico al almacenamiento en bloque respaldado por SSD local.
También puedes usar el enfoque de acceso en bloque con SSDs locales si desea que una caché de datos unificada comparta datos entre Pods y que los datos estén vinculados a un ciclo de vida de nodo. Para hacerlo, instala un DaemonSet con una configuración RAID, dale formato un sistema de archivos y usa un PersistentVolume local para compartir datos entre los Pods.
Requisitos de la máquina
La forma en que aprovisionas SSDs locales para tus clústeres de GKE y grupos de nodos depende del tipo de máquina subyacente. GKE admite volúmenes de SSDs locales en las series de máquinas de Compute Engine de primera, segunda y tercera generación. Los volúmenes de SSDs locales requieren el tipo de máquina n1-standard-1 o una superiores.
El tipo de máquina predeterminado, e2-medium, no es compatible.
Para identificar tu serie de máquina, usa el número en el nombre del tipo de máquina. Por ejemplo, las máquinas N1 son de primera generación y las N2 son de segunda generación.
Para obtener una lista de las series y tipos de máquinas disponibles, consulta la Guía de comparación y recursos de familias de máquinas en la documentación de Compute Engine.
Requisitos para series de máquinas de primera y segunda generación
Para usar una serie de máquinas de primera o segunda generación con SSD local, tu clúster o grupo de nodos debe ejecutar la versión 1.25.3-gke.1800 de GKE o superior.
Para aprovisionar SSDs locales en series de máquinas de primera o segunda generación, especifica la cantidad de volúmenes de SSDs locales que se usarán con tu VM. Para obtener una lista de las series de máquinas y la cantidad permitida de SSDs locales, consulta Elige una cantidad válida de SSDs locales en la documentación de Compute Engine.
Requisitos para las series de máquinas de tercera generación
Si deseas usar una máquina de la serie de tercera generación con SSD local, tu clúster o grupo de nodos debe usar una de las siguientes versiones de GKE o superior:
- 1.25.13-gke.200 a 1.26
- 1.26.8-gke.200 a 1.27
- 1.27.5-gke.200 a 1.28
- 1.28.1-gke.200 a 1.29
Para las máquinas de la serie de tercera generación, cada tipo de máquina está preconfigurado sin SSD local o una cantidad fija de volúmenes de SSDs locales. No debes especificar la cantidad de volúmenes de SSDs locales que se incluirán. En cambio, la capacidad de SSDs locales disponible para los clústeres se define de forma implícita como parte de la forma de la VM.
Para obtener una lista de las series de máquinas y la cantidad permitida de SSDs locales, consulta Elige una cantidad válida de SSDs locales en la documentación de Compute Engine.
Patrón de uso para volúmenes de SSDs locales
Para usar volúmenes de SSDs locales en tus clústeres, sigue estos pasos generales:
- Aprovisiona un grupo de nodos con SSD local conectado: Para crear un grupo de nodos de GKE con SSDs locales conectados, pasa el parámetro de almacenamiento efímero o del almacenamiento en bloque sin procesar cuando llames al comando
create cluster. Cuando se configuran los parámetros de SSDs locales, se crea un grupo de nodos de GKE con SSDs locales conectado y configurado como almacenamiento efímero local o almacenamiento en bloque sin procesar según los parámetros que elijas. Si deseas obtener más información sobre las opciones para aprovisionar SSDs locales, consulta Parámetros de SSDs locales. - Accede a los datos desde los volúmenes de SSDs locales: Para usar los datos de los volúmenes de SSDs locales, puedes usar una construcción de Kubernetes, como el volumen emptyDir o persistente local. Para obtener más información sobre estas opciones, consulta la página sobre el acceso a SSDs locales.
Parámetros de SSDs locales en GKE
En la siguiente tabla, se resumen los parámetros recomendados que proporciona GKE para aprovisionar almacenamiento SSD local en clústeres. Puedes usar gcloud CLI para pasar estos parámetros.
| Tipo de SSD local | Comando de gcloud CLI | Disponibilidad de GKE | Perfil de SSDs locales |
|---|---|---|---|
| SSD local de Almacenamiento efímero | gcloud container clusters create |
v1.25.3-gke.1800 o posterior |
Tecnología de almacenamiento: NVMe Datos compartidos entre Pods: No Ciclo de vida de los datos: Pod Tamaño y necesidad de la configuración de RAID: Hasta 9 TiB. GKE configura automáticamente el RAID de forma interna. Formato: Sistema de archivos (Kubernetes emptyDir) Integración con programadores de Kubernetes: Se integra por completo de forma predeterminada. El programador de Kubernetes garantizará el espacio en el nodo antes de la ubicación y hara un escalamiento de los nodos si es necesario. Para aprender a usar este parámetro de API, consulta Aprovisiona y usa el almacenamiento efímero respaldado por SSD local. |
| Bloque local de SSD NVMe | gcloud container clusters create |
v1.25.3-gke.1800 o posterior |
Tecnología de almacenamiento: NVMe Datos compartidos entre Pods: Sí, a través de los PV locales. Ciclo de vida de los datos: Nodo Tamaño y necesidad de la configuración de RAID: Hasta 9 TiB. Debes configurar RAID de forma manual para tamaños más grandes. Formato: Bloque sin procesar Integración del programador de Kubernetes: No, de forma predeterminada. Debes garantizar la capacidad en los nodos y manejar los vecinos ruidosos. Si habilitas el PV local, la programación está integrada. Para aprender a usar este parámetro de API, consulta Aprovisiona y usa almacenamiento en bloque sin procesar respaldado por SSD local. |
Compatibilidad con parámetros de SSDs locales existentes
En la tabla siguiente, se resumen los parámetros de SSDs locales existentes y sus sustitutos recomendados:
| Parámetros de SSDs locales existentes | Comando de gcloud CLI | Perfil de SSDs locales | Versión recomendada de GA de los parámetros de SSDs locales |
|---|---|---|---|
| Parámetro de recuento de SSDs locales | gcloud container clusters create |
Tecnología de almacenamiento: SCSI Datos compartidos entre Pods: Sí, a través de los PV locales Ciclo de vida de los datos: Nodo Tamaño y necesidad de la configuración de RAID: 375 GiB. Debes configurar RAID de forma manual para tamaños más grandes. Formato: Sistema de archivos (ext-4) Integración del programador de Kubernetes: no de forma predeterminada. Debes garantizar la capacidad en los nodos y manejar los vecinos ruidosos. Si habilitas el PV local, la programación está integrada. |
gcloud container clusters create |
| Parámetro de Almacenamiento efímero (beta) | gcloud beta container clusters create |
Tecnología de almacenamiento: NVMe Datos compartidos entre Pods: No Ciclo de vida de los datos: Pod Tamaño y necesidad de la configuración de RAID: hasta 9 TiB. GKE configura automáticamente el RAID de forma interna. Formato: Sistema de archivos (Kubernetes emptyDir) Integración con programadores de Kubernetes: Se integra por completo de forma predeterminada. El programador de Kubernetes garantizará el espacio en los nodos antes de la ubicación y escalará los nodos si es necesario. |
gcloud container clusters create |
| Parámetro de volúmenes SSDs locales (alfa) | gcloud alpha container clusters create |
Tecnología de almacenamiento: NVMe o SCSI Datos compartidos entre Pods: No Ciclo de vida de los datos: Nodo Tamaño y necesidad de la configuración de RAID: 375 GiB. Debes configurar RAID de forma manual para tamaños más grandes. Formato: Sistema de archivos (ext-4) o bloque sin procesar Integración del programador de Kubernetes: No de forma predeterminada, debes garantizar la capacidad en los nodos y manejar los vecinos ruidosos. |
gcloud container clusters create |
Acceso a SSDs locales
Puedes acceder a los volúmenes de SSDs locales con uno de los siguientes métodos.
Volume emptyDir
En la versión v1.25.3-gke.1800 y posteriores de GKE, puedes usar el almacenamiento efímero como un volumen emptyDir respaldado por SSDs locales, a través de la opción --ephemeral-storage-local-ssd. Recomendamos este enfoque para la mayoría de los casos, incluidas las aplicaciones que necesitan espacio temporal efímero de alto rendimiento.
GKE te permite configurar un grupo de nodos para activar el almacenamiento efímero del nodo en SSDs locales con una interfaz NVMe.
Para obtener más información, consulta este ejemplo.
Volumen persistente local
Un volumen persistente local representa un disco local que está conectado a un solo nodo. Los volúmenes persistentes locales te permiten compartir recursos de SSDs locales entre Pods. Debido a que el disco local es una SSD local, los datos siguen siendo efímeros.
Recomendamos este enfoque si se ejecuta alguna de las siguientes opciones en tu clúster:
- Cargas de trabajo con StatefulSets y volumeClaimTemplates
- Cargas de trabajo que comparten grupos de nodos. Cada volumen SSD local se puede reservar a través de PersistentVolumeClaim. Las HostPaths específicas no se codifican directamente en la especificación del Pod.
- Pods que requieren gravedad de datos en el mismo SSD local. Un Pod siempre se programa para el mismo nodo que el de su PersistentVolume local.
Para obtener más información, consulta este ejemplo y la documentación de volúmenes de Kubernetes de código abierto.
Restricciones
La aplicación debe manejar con facilidad la pérdida de acceso a los datos en los volúmenes de SSDs locales. Los datos escritos en un disco SSD local no se conservan cuando el Pod o el nodo se borra, repara, actualiza o experimenta un error irrecuperable.
El parámetro de almacenamiento local SSD configura los volúmenes de SSDs locales para tener un ciclo de vida de datos basado en Pods y el parámetro de bloque SSD NVMe local configura los volúmenes de SSDs locales a fin de que tengan un ciclo de vida de datos basado en nodos.
Si necesitas almacenamiento persistente, te recomendamos que uses una opción de almacenamiento duradero (como Persistent Disk, Filestore o Cloud Storage). También puedes usar réplicas regionales para minimizar el riesgo de pérdida de datos durante las operaciones de ciclo de vida del clúster o de ciclo de vida de la aplicación.
Los ajustes de configuración del SSD local no se pueden modificar una vez que se crea el grupo de nodos. No puedes habilitar, inhabilitar ni actualizar la configuración de SSD local para un grupo de nodos existente. Debes borrar el grupo de nodos y volver a crear uno nuevo para realizar cualquier cambio.
Los Pods que usan emptyDir de manera transparente usan SSDs locales. Sin embargo, esto ocurre con todos los Pods de todos los nodos en ese grupo de nodos. GKE no admite tener, en el mismo grupo de nodos, algunos Pods que usan volúmenes emptyDir de SSDs locales respaldadas por una SSD local y otros Pods que usan volúmenes emptyDir respaldados por un disco de arranque del nodo. Si tienes cargas de trabajo que usan volúmenes emptyDir respaldados por un disco de arranque de nodo, programa las cargas de trabajo en un grupo de nodos diferente.
Los clústeres de Autopilot y el aprovisionamiento automático de nodos no son compatibles con las SSDs locales.
Recomendamos usar el SSD local como almacenamiento efímero para las cargas de trabajo que se ejecutan en VMs optimizadas para almacenamiento (Z3). Los nodos Z3 finalizan durante los eventos de mantenimiento. Debido a esto, es posible que los datos en la SSD local de estos nodos no estén disponibles durante los eventos de mantenimiento y no se garantiza la recuperación de datos después del mantenimiento.
¿Qué sigue?
- Aprovisiona y usa el almacenamiento efímero respaldado por SSDs locales.
- Aprovisiona y usa el almacenamiento en bloque sin procesar respaldado por SSDs locales.