Las unidades de estado sólido (SSDs) locales son unidades SSD de tamaño fijo que se pueden montar en una sola VM de Compute Engine. Puedes usar SSD local en GKE para obtener un almacenamiento de alto rendimiento que no sea persistente (efímero) y que esté vinculado a todos los nodos de tu clúster. Las SSDs locales también ofrecen un mayor rendimiento y una latencia menor que los discos estándar.
En la versión 1.25.3-gke.1800 y posteriores, puedes configurar un grupo de nodos de GKE para que use SSD local con una interfaz NVMe para el almacenamiento efímero local o el almacenamiento de bloques sin formato.
Si usas GKE con clústeres estándar, puedes conectar volúmenes de SSD local a los nodos cuando crees grupos de nodos. De esta forma, se mejora el rendimiento del almacenamiento efímero de las cargas de trabajo que usan volúmenes emptyDir o volúmenes persistentes locales. Puedes crear grupos de nodos con SSD local dentro de los límites de tipo de máquina de tu clúster y de las cuotas de tu proyecto.
Un disco SSD local solo se conecta a un nodo, y los nodos son efímeros. Una carga de trabajo se puede programar en un nodo diferente en cualquier momento.
Cuando configuras SSDs locales, GKE monta automáticamente los siguientes directorios en el volumen de SSD local para mejorar el rendimiento: /var/lib/kubelet, /var/log/pods y /var/lib/containerd. De esta forma, se garantiza un acceso más rápido a los datos críticos de kubelet, los registros de pods y los archivos de tiempo de ejecución de contenedores.
Para obtener más información sobre las ventajas y las limitaciones de las SSD locales, como el rendimiento y el número de discos SSD permitidos por tipo de máquina, consulta la sección SSD locales de la documentación de Compute Engine.
Por qué elegir SSD local para GKE
SSD local es una buena opción si tus cargas de trabajo tienen alguno de los siguientes requisitos:
- Quieres ejecutar aplicaciones que descarguen y procesen datos, como IA o aprendizaje automático, analíticas, procesamiento por lotes, almacenamiento en caché local y bases de datos en memoria.
- Tus aplicaciones tienen necesidades de almacenamiento especializadas y quieres acceder a bloques sin formato en un almacenamiento efímero de alto rendimiento.
- Quieres ejecutar aplicaciones de datos especializadas y operar volúmenes SSD 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 memoria, como Aerospike o Redis.
Almacenamiento efímero
Te recomendamos que uses la opción --ephemeral-storage-local-ssd para aprovisionar SSD local para el almacenamiento efímero de nodos (esta es la opción predeterminada si usas una serie de máquinas de tercera generación).
Con este enfoque, los volúmenes emptyDir, las capas en las que se pueden escribir contenedores y las imágenes que constituyen el almacenamiento efímero de tu nodo se colocan en el SSD local. Entre las ventajas, se incluyen un ancho de banda de E/S mejorado en comparación con el Persistent Disk predeterminado y tiempos de inicio de pods más rápidos.
Si usas unidades SSD locales para el almacenamiento efímero de los nodos, los volúmenes de las unidades SSD locales de los discos de arranque no estarán disponibles para otros usos. No modifiques los dispositivos SSD locales, como /dev/nvme*
, directamente mediante un DaemonSet privilegiado, HostPath u otro mecanismo. De lo contrario, el nodo puede fallar.
Si necesitas un control detallado sobre los volúmenes de SSD local, utiliza el enfoque de bloque sin formato.
Bloquear el almacenamiento del dispositivo
El almacenamiento en dispositivos de bloque permite el acceso aleatorio a los datos en bloques de tamaño fijo. Algunas aplicaciones especializadas requieren acceso directo al almacenamiento de dispositivos de bloque porque, por ejemplo, la capa del sistema de archivos introduce una sobrecarga innecesaria.
Estos son algunos de los casos prácticos habituales del almacenamiento de dispositivos de bloque:
- 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 NVMe locales de bloque sin formato conectados mediante la opción --local-nvme-ssd-block. Después, puedes personalizar el almacenamiento en bloques formateando el sistema de archivos que quieras (como ZFS o HDFS) y configurando RAID. Esta opción es adecuada si necesitas más control para ejecutar cargas de trabajo que requieran específicamente acceso al almacenamiento en bloque respaldado por SSD local.
También puedes usar el método de bloqueo de acceso con SSD local si quieres una caché de datos unificada para compartir datos entre pods y los datos están vinculados al ciclo de vida de un nodo. Para ello, instala un DaemonSet con una configuración RAID, da formato a un sistema de archivos y usa un PersistentVolume local para compartir datos entre pods.
Requisitos de la máquina
La forma de aprovisionar SSD local para tus clústeres y grupos de nodos de GKE depende del tipo de máquina subyacente. GKE admite volúmenes de SSD local en las series de máquinas de primera, segunda y tercera generación de Compute Engine. Los volúmenes SSD locales requieren el tipo de máquina n1-standard-1 o superior.
No se admite el tipo de máquina predeterminado, e2-medium.
Para identificar la serie de tu máquina, usa el número del nombre del tipo de máquina. Por ejemplo, las máquinas N1 son de primera generación y las máquinas N2 son de segunda generación.
Para ver una lista de las series y los tipos de máquinas disponibles, consulta el recurso y la guía de comparación de familias de máquinas en la documentación de Compute Engine.
Requisitos de la serie 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 o una posterior de GKE.
Para aprovisionar SSD local en una serie de máquinas de primera o segunda generación, especifica el número de volúmenes de SSD local que quieres usar con tu VM. Para ver una lista de series de máquinas y el número de SSDs locales que se pueden usar en cada una, consulta el artículo Elegir un número válido de SSDs locales de la documentación de Compute Engine.
Requisitos de las series de máquinas de tercera y cuarta generación
Si quieres usar una serie de máquinas de tercera generación con SSD local, tu clúster o grupo de nodos debe ejecutar una de las siguientes versiones de GKE o una posterior:
- De 1.25.13-gke.200 a 1.26
- 1.26.8-gke.200 a 1.27
- 1.27.5-gke.200 a 1.28
- De 1.28.1-gke.200 a 1.29
Si quieres usar una serie de máquinas de cuarta generación con SSD local, tu clúster o pool de nodos debe ejecutar una de las siguientes versiones de GKE o una posterior:
- 1.32.1-gke.1357000
En las series de máquinas de tercera y cuarta generación, cada tipo de máquina se preconfigura sin SSD local o con una cantidad fija de volúmenes de SSD local. No especifica el número de volúmenes SSD locales que quiere incluir. En su lugar, la capacidad de SSD local disponible para tus clústeres se define implícitamente como parte del tipo de VM.
Para ver una lista de series de máquinas y el número permitido de SSDs locales correspondiente, consulta la sección Elegir un número válido de SSDs locales de la documentación de Compute Engine.
Patrón de uso de volúmenes SSD locales
Para usar volúmenes de SSD local en tus clústeres, sigue estos pasos generales:
- Aprovisionar 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 de almacenamiento en bloques sin formato cuando llames al comando
create cluster. Al definir los parámetros de SSD local, se crea un grupo de nodos de GKE con SSD local conectado y configurado como almacenamiento efímero local o almacenamiento en bloque sin formato, en función de los parámetros que elijas. Para obtener más información sobre las opciones de aprovisionamiento de SSD local, consulta Parámetros de SSD local. - Acceder a los datos de los volúmenes de SSD local: para usar los datos de los volúmenes de SSD local, puedes usar una estructura de Kubernetes, como emptyDir o un volumen persistente local. Para obtener más información sobre estas opciones, consulta Acceso a SSD local.
Parámetros de SSD local en GKE
En la siguiente tabla se resumen los parámetros recomendados que proporciona GKE para aprovisionar almacenamiento SSD local en clústeres. Puede usar la CLI de gcloud para introducir estos parámetros.
| Tipo de SSD local | Comando de la CLI de gcloud | Disponibilidad de GKE | Perfil de SSD local |
|---|---|---|---|
| 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 configuración RAID: hasta 9 TiB. GKE configura automáticamente RAID de forma interna. Formato: sistema de archivos (emptyDir de Kubernetes) Integración del programador de Kubernetes: totalmente integrada de forma predeterminada. El programador de Kubernetes se asegurará de que haya espacio en el nodo antes de colocarlo y escalará los nodos si es necesario. Para saber cómo usar este parámetro de API, consulta Aprovisionar y usar almacenamiento efímero respaldado por SSD local. |
| Bloque SSD NVMe local | gcloud container clusters create |
v1.25.3-gke.1800 o posterior |
Tecnología de almacenamiento: NVMe Datos compartidos entre pods: sí, mediante PVs locales. Ciclo de vida de los datos: nodo Tamaño y necesidad de configuración RAID: hasta 9 TiB. Debes configurar manualmente RAID para tamaños más grandes. Formato: bloque sin formato Integración del programador de Kubernetes: no, de forma predeterminada. Debes asegurar la capacidad de los nodos y gestionar los vecinos ruidosos. Si habilitas la opción de energía fotovoltaica local, se integrará la programación. Para saber cómo usar este parámetro de la API, consulta Aprovisionar y usar almacenamiento de bloques sin formato respaldado por SSD local. |
Compatibilidad con los parámetros de SSD local
En la siguiente tabla se resumen estos parámetros de SSD local y sus sustitutos recomendados:
| Parámetros de SSD local actuales | Comando de la CLI de gcloud | Perfil de SSD local | Versión de disponibilidad general recomendada de los parámetros de SSD local |
|---|---|---|---|
| Parámetro Local SSD Count | gcloud container clusters create |
Tecnología de almacenamiento: SCSI Datos compartidos entre pods: sí, mediante PVs locales Ciclo de vida de los datos: nodo Tamaño y necesidad de configuración RAID: 375 GiB. Debes configurar manualmente RAID para tamaños más grandes. Formato: sistema de archivos (ext-4) Integración del programador de Kubernetes: no de forma predeterminada. Debes asegurarte de que haya capacidad en los nodos y gestionar los vecinos ruidosos. Si habilitas la opción de energía fotovoltaica local, la programación se integra. |
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 configuración RAID: hasta 9 TiB. GKE configura automáticamente RAID de forma interna. Formato: sistema de archivos (emptyDir de Kubernetes) Integración del programador de Kubernetes: totalmente integrada de forma predeterminada. El programador de Kubernetes se asegurará de que haya espacio en los nodos antes de colocarlos y escalará los nodos si es necesario. |
gcloud container clusters create |
| Parámetro de volúmenes SSD 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 configuración RAID: 375 GiB. Debes configurar manualmente RAID para tamaños más grandes. Formato: sistema de archivos (ext-4) o bloque sin formato Integración del programador de Kubernetes: no de forma predeterminada. Debes asegurarte de que haya capacidad en los nodos y gestionar los vecinos ruidosos. |
gcloud container clusters create |
Acceso a SSD local
Puede acceder a los volúmenes de SSD local con uno de los siguientes métodos.
Volumen emptyDir
En GKE 1.25.3-gke.1800 y versiones posteriores, puedes usar el almacenamiento efímero como un volumen emptyDir respaldado por SSD local mediante la opción --ephemeral-storage-local-ssd. Recomendamos este enfoque en la mayoría de los casos, incluidas las aplicaciones que necesitan espacio de almacenamiento efímero de alto rendimiento.
GKE te permite configurar un grupo de nodos para montar el almacenamiento efímero de nodos en un SSD local 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 SSD locales entre pods. Como el disco local es un disco SSD local, los datos siguen siendo efímeros.
Te recomendamos este enfoque si se ejecuta alguno de los siguientes elementos en tu clúster:
- Cargas de trabajo que usan StatefulSets y volumeClaimTemplates.
- Cargas de trabajo que comparten grupos de nodos. Cada volumen de SSD local se puede reservar mediante un PersistentVolumeClaim y los HostPaths específicos 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 en el mismo nodo que 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
Tu aplicación debe gestionar correctamente la pérdida de acceso a los datos de los volúmenes de SSD local. Los datos escritos en un disco SSD local no se conservan cuando se elimina, se repara o se actualiza el pod o el nodo, o cuando se produce un error irrecuperable.
El parámetro de almacenamiento efímero SSD local configura los volúmenes de SSD local para que tengan un ciclo de vida de los datos basado en pods, mientras que el parámetro de bloque de SSD local NVMe configura los volúmenes de SSD local para que tengan un ciclo de vida de los datos basado en nodos.
Si necesitas almacenamiento persistente, te recomendamos que uses una opción de almacenamiento duradera (como Persistent Disk, Filestore o Cloud Storage). También puede usar réplicas regionales para minimizar el riesgo de pérdida de datos durante las operaciones del ciclo de vida del clúster o de la aplicación.
La configuración de SSD local no se puede modificar una vez creado el grupo de nodos. No puedes habilitar, inhabilitar ni actualizar la configuración de SSD local de un grupo de nodos. Para hacer cambios, debes eliminar el grupo de nodos y volver a crearlo.
Los pods que usan emptyDir usan SSD local de forma transparente. Sin embargo, esto se aplica a todos los pods de todos los nodos de ese grupo de nodos. GKE no admite que, en el mismo grupo de nodos, algunos pods usen volúmenes emptyDir de SSD local respaldados por SSD local y otros pods usen volúmenes emptyDir respaldados por un disco de arranque de 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 otro grupo de nodos.
Los clústeres de Autopilot y el aprovisionamiento automático de nodos no se admiten en unidades SSD locales.
Te recomendamos que uses la unidad SSD local como almacenamiento efímero para las cargas de trabajo que se ejecutan en máquinas virtuales optimizadas para almacenamiento (Z3). La migración activa se admite en las máquinas virtuales Z3 con menos de 88 vCPUs, pero las máquinas virtuales Z3 con 88 vCPUs o más se terminan durante los eventos de mantenimiento. Para obtener más información, consulta Mantenimiento de instancias Z3. Como las VMs Z3 con 88 o más vCPUs se terminan, es posible que los datos de la unidad SSD local de los nodos no estén disponibles durante los eventos de mantenimiento y no se garantiza la recuperación de los datos después del mantenimiento. Para obtener más información, consulta Persistencia de discos tras la finalización de la instancia.
Siguientes pasos
- Aprovisionar y usar almacenamiento efímero con SSD local.
- Aprovisiona y usa almacenamiento en bloques sin formato respaldado por SSD local.