Aprovisionar y usar almacenamiento en bloques sin formato respaldado por SSD local

Estándar

En esta página se explica cómo aprovisionar almacenamiento SSD local en clústeres de Google Kubernetes Engine (GKE) y cómo configurar cargas de trabajo para que consuman datos del almacenamiento de bloques sin formato respaldado por SSD local conectado a los nodos de tu clúster.

Si usas esta opción de SSD local, tendrás más control sobre el almacenamiento subyacente y podrás crear tu propia caché a nivel de nodo para los pods, lo que mejorará el rendimiento de tus aplicaciones. También puedes personalizar esta opción instalando un sistema de archivos en discos SSD locales. Para ello, ejecuta un DaemonSet para configurar RAID y formatear los discos según sea necesario.

Nota: Los volúmenes de SSD local requieren un tipo de máquina n1-standard-1 o superior. El tipo de máquina predeterminado, e2-medium, no se admite. Para obtener más información, consulta la sección sobre tipos de máquinas en la documentación de Compute Engine.

Advertencia: No recomendamos usar la unidad SSD local como almacenamiento en bloques sin formato para tus máquinas virtuales optimizadas para almacenamiento (Z3). Es posible que los datos de las unidades SSD locales de los nodos Z3 no estén disponibles durante los eventos de mantenimiento y no se garantiza la recuperación de los datos después del mantenimiento. Por lo tanto, te recomendamos que utilices la unidad SSD local como almacenamiento efímero para las cargas de trabajo que se ejecuten en máquinas virtuales Z3.

Para obtener más información sobre la compatibilidad con SSD local para el acceso a bloques sin formato en GKE, consulta el artículo Acerca de las SSD locales.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.
  Nota: Si ya tienes instalada la CLI de gcloud, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

Crear un clúster o un grupo de nodos con almacenamiento en bloques sin formato respaldado por SSD local

Usa la CLI de gcloud con la opción --local-nvme-ssd-block para crear un clúster con almacenamiento de bloques sin formato respaldado por SSD local.

Nota: Para usar el almacenamiento en bloque sin formato respaldado por SSD local, debes configurar los dispositivos manualmente. Los discos SSD locales no están formateados para RAID. También eres responsable de asegurar la capacidad de los nodos y de gestionar las posibles interrupciones de las cargas de trabajo ubicadas en el mismo lugar. Si usas PersistentVolume local, la programación está integrada. Si no necesitas que los datos se conserven durante el ciclo de vida del pod o no tienes requisitos de rendimiento especiales, usa la opción --ephemeral-storage-local-ssd, que debería adaptarse a la mayoría de los casos prácticos.

El comando de la CLI de gcloud que ejecutes para crear el clúster o el grupo de nodos dependerá de la generación de la serie de máquinas a la que pertenezca el tipo de máquina que estés usando. Por ejemplo, los tipos de máquinas N1 y N2 pertenecen a las series de máquinas de primera y segunda generación, respectivamente, mientras que los tipos de máquinas C3 pertenecen a la serie de máquinas de tercera generación.

Crear un clúster con SSD local

1.ª o 2.ª generación

Si usas un tipo de máquina de una serie de máquinas de primera o segunda generación, puedes crear el clúster especificando la opción --local-nvme-ssd-block count=NUMBER_OF_DISKS. Esta opción especifica el número de discos SSD locales que se van a asociar a cada nodo. El número máximo varía según el tipo de máquina y la región.

Si quieres crear un clúster, sigue estos pasos:

gcloud container clusters create CLUSTER_NAME \
    --local-nvme-ssd-block count=NUMBER_OF_DISKS \
    --machine-type=MACHINE_TYPE \
    --release-channel CHANNEL_NAME

Haz los cambios siguientes:

• CLUSTER_NAME: el nombre del clúster.
• NUMBER_OF_DISKS: el número de discos SSD locales que se aprovisionarán en cada nodo. El número máximo de discos varía según el tipo de máquina y la región.
• MACHINE_TYPE: el tipo de máquina de primera o segunda generación que se va a usar. Este campo es obligatorio porque no puedes usar SSDs locales con el tipo e2-medium predeterminado.
• CHANNEL_NAME: un canal de lanzamiento que incluye versiones de GKE posteriores a la 1.25.3-gke.1800.

3.ª o 4.ª generación

Si usas un tipo de máquina de una serie de máquinas de tercera o cuarta generación, utiliza la opción --local-nvme-ssd-block, sin un campo de recuento, para crear un clúster. GKE aprovisiona automáticamente la capacidad de SSD local para tu clúster en función del tipo de VM. El número máximo varía según el tipo de máquina y la región.

gcloud container clusters create CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --cluster-version CLUSTER_VERSION \
    --local-nvme-ssd-block

Haz los cambios siguientes:

• CLUSTER_NAME: el nombre del clúster.
• MACHINE_TYPE: el tipo de máquina que se va a usar de una serie de máquinas de tercera o cuarta generación.
• CLUSTER_VERSION: una versión de clúster de GKE que admita SSD local en tipos de máquinas de una serie de máquinas de tercera o cuarta generación.

Crear un grupo de nodos con SSD local

1.ª o 2.ª generación

Para crear un grupo de nodos que use discos SSD locales para el acceso a bloques sin formato, ejecuta el siguiente comando:

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --local-nvme-ssd-block count=NUMBER_OF_DISKS

Haz los cambios siguientes:

• POOL_NAME: el nombre del nuevo grupo de nodos.
• CLUSTER_NAME: el nombre del clúster.
• MACHINE_TYPE: el tipo de máquina de primera o segunda generación que se va a usar. Este campo es obligatorio, ya que no se puede usar SSD local con el tipo e2-medium predeterminado.
• NUMBER_OF_DISKS: el número de discos SSD locales que se aprovisionarán en cada nodo. El número máximo de discos varía según el tipo de máquina y la región.

3.ª o 4.ª generación

Si usas un tipo de máquina de una serie de máquinas de tercera o cuarta generación, utiliza la opción --local-nvme-ssd-block, sin un campo de recuento, para crear un clúster:

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --node-version NODE_VERSION \
    --local-nvme-ssd-block

Haz los cambios siguientes:

• POOL_NAME: el nombre del nuevo grupo de nodos.
• CLUSTER_NAME: el nombre del clúster.
• MACHINE_TYPE: el tipo de máquina que se va a usar de un tipo de máquina de tercera o cuarta generación.
• NODE_VERSION: una versión de grupo de nodos de GKE que admite SSD local en tipos de máquina de una serie de máquinas de tercera o cuarta generación.

Los nodos del grupo de nodos se crean con la etiqueta cloud.google.com/gke-local-nvme-ssd=true. Para verificar las etiquetas, ejecuta el siguiente comando:

kubectl describe node NODE_NAME

Por cada SSD local conectado al pool de nodos, el SO host crea un enlace simbólico (symlink) para acceder al disco en una carpeta ordinal y un symlink con un identificador único universal (UUID). Por ejemplo, si creas un pool de nodos con tres SSDs locales mediante la opción --local-nvme-ssd-block, el SO host crea los siguientes enlaces simbólicos para los discos:

• /dev/disk/by-id/google-local-ssd-block0
• /dev/disk/by-id/google-local-ssd-block1
• /dev/disk/by-id/google-local-ssd-block2

Del mismo modo, el SO anfitrión también crea los siguientes enlaces simbólicos con UUIDs para los discos:

• /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID1
• /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID2
• /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID3

De esta forma, se puede acceder a los discos mediante un identificador único.

Acceder a volúmenes SSD locales

En el siguiente ejemplo se muestra cómo acceder al almacenamiento de bloques sin formato respaldado por SSD local.

PersistentVolumes locales

Los volúmenes SSD locales se pueden montar como pods mediante PersistentVolumes.

Puedes crear PersistentVolumes a partir de SSD local creando manualmente un PersistentVolume o ejecutando el proveedor estático de volúmenes locales.

Limitaciones de los PersistentVolumes locales

Nota: Cuando se usan canales de versiones, la actualización y la reparación automáticas no se pueden inhabilitar. No recomendamos usar PersistentVolumes locales con clústeres en un canal de lanzamiento.

• El autoescalado de clústeres y el aprovisionamiento dinámico no se admiten con PersistentVolumes locales.

• Si actualizas un clúster de GKE o reparas nodos, se eliminarán las instancias de Compute Engine, lo que también eliminará todos los datos de los discos SSD locales.

• No habilites las actualizaciones automáticas de nodos ni la reparación automática de nodos en clústeres o grupos de nodos que usen SSD local para datos persistentes. Primero debes crear una copia de seguridad de los datos de tu aplicación y, a continuación, restaurarlos en un nuevo clúster o grupo de nodos.

Precaución: Los clústeres y grupos de nodos creados con la consola Google Cloud tienen habilitada la actualización automática de nodos de forma predeterminada. Para inhabilitar esta función, consulta el artículo sobre las actualizaciones automáticas de nodos.

• Los objetos PersistentVolume locales no se limpian automáticamente cuando se elimina, actualiza, repara o reduce la escala de un nodo. Te recomendamos que analices y elimines periódicamente los objetos Local PersistentVolume obsoletos asociados a los nodos eliminados.

Crear el PersistentVolume manualmente

Puede crear manualmente un PersistentVolume para cada SSD local de cada nodo de su clúster.

Utilice el campo nodeAffinity de un objeto PersistentVolume para hacer referencia a un LocalSSD en un nodo específico. En el siguiente ejemplo se muestra la especificación de PersistentVolume para SSD local en nodos que ejecutan Linux:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: "example-local-pv"
spec:
  capacity:
    storage: 375Gi
  accessModes:
  - "ReadWriteOnce"
  persistentVolumeReclaimPolicy: "Retain"
  storageClassName: "local-storage"
  local:
    path: "/mnt/disks/ssd0"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "kubernetes.io/hostname"
          operator: "In"
          values:
          - "gke-test-cluster-default-pool-926ddf80-f166"

En este ejemplo, los discos SSD locales se configuran manualmente para RAID y se formatean. Después, se montan en /mnt/disks/ssd0 en el nodo gke-test-cluster-default-pool-926ddf80-f166. El campo nodeAffinity se usa para asignar cargas de trabajo a nodos con SSDs locales que se han configurado manualmente para RAID. Si solo tienes un nodo en el clúster o has configurado RAID para todos los nodos, no es necesario que incluyas el campo nodeAffinity.

La especificación de PersistentVolumeClaim correspondiente tiene el siguiente aspecto:

  kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: ssd-local-claim
  spec:
    accessModes:
    - ReadWriteOnce
    storageClassName: local-storage
    resources:
      requests:
        storage: 37Gi

Si eliminas el PersistentVolume, debes borrar manualmente los datos del disco.

Ejecutar el aprovisionador estático de volúmenes locales

Nota: El aprovisionador estático de volumen local es un proyecto de la comunidad y no lo mantiene ni lo admite Google. Tampoco se puede usar con Windows.

Puedes crear PersistentVolumes para SSD local automáticamente mediante el aprovisionador estático de volúmenes locales. El provisionador es un DaemonSet que gestiona los discos SSD locales de cada nodo, crea y elimina los PersistentVolumes correspondientes y limpia los datos de los discos SSD locales cuando se libera el PersistentVolume.

Para ejecutar el aprovisionador estático de volumen local, haz lo siguiente:

1. Usa un DaemonSet para configurar RAID y formatear los discos:

   1. Descarga la especificación gke-daemonset-raid-disks.yaml.

   2. Despliega el DaemonSet de los discos RAID. DaemonSet configura un array RAID 0 en todos los discos SSD locales y formatea el dispositivo en un sistema de archivos ext4.

      kubectl create -f gke-daemonset-raid-disks.yaml
      

2. Descarga la especificación gke-nvme-ssd-block-raid.yaml y modifica los campos de espacio de nombres según sea necesario.

   La especificación incluye estos recursos:

   • ServiceAccount del provisioner
   • ClusterRole y ClusterRoleBindings para los permisos de:
     • Crear y eliminar objetos PersistentVolume
     • Obtener objetos Node
   • ConfigMap con ajustes de aprovisionador para GKE
   • DaemonSet para ejecutar el aprovisionador

3. Implementa el aprovisionador:

   kubectl create -f gke-nvme-ssd-block-raid.yaml
   

   Una vez que el aprovisionador se haya ejecutado correctamente, creará un objeto PersistentVolume para el dispositivo SSD local RAID en el clúster.

4. Guarda el siguiente manifiesto PersistentVolumeClaim como provisioner-pvc-example.yaml:

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: PVC_NAME
   spec:
     accessModes:
     - ReadWriteOnce
     resources:
       requests:
         storage: 50Gi
     storageClassName: nvme-ssd-block
   

   Sustituye PVC_NAME por el nombre de tu PersistentVolumeClaim.

5. Crea el PersistentVolumeClaim:

   kubectl create -f provisioner-pvc-example.yaml
   

6. Guarda el siguiente archivo de manifiesto de Pod como provisioner-pod-example.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: POD_NAME
   spec:
     containers:
     - name: "shell"
       image: "ubuntu:14.04"
       command: ["/bin/sh", "-c"]
       args: ["echo 'hello world' > /cache/test.txt && sleep 1 && cat /cache/test.txt && sleep 3600"]
       volumeMounts:
       - mountPath: /cache
         name: local-ssd-storage
     volumes:
     - name: local-ssd-storage
       persistentVolumeClaim:
         claimName: PVC_NAME
   

   Sustituye POD_NAME por el nombre de tu pod.

7. Crea el Pod:

   kubectl create -f provisioner-pod-example.yaml
   

Habilitar la vinculación de volumen retrasada

Nota: Si has seguido las instrucciones para ejecutar el aprovisionador estático de volúmenes locales, su manifiesto proporciona una definición de StorageClass adecuada. Si usas el aprovisionador estático de volumen local, no es necesario que sigas los pasos de esta sección.

Para mejorar la programación, te recomendamos que también crees un StorageClass con volumeBindingMode: WaitForFirstConsumer. De esta forma, se retrasa el enlace de PersistentVolumeClaim hasta la programación del pod, de modo que se elija un SSD local de un nodo adecuado que pueda ejecutar el pod. Este comportamiento de programación mejorado tiene en cuenta las solicitudes de CPU y memoria de los pods, la afinidad de los nodos, la afinidad y la antiafinidad de los pods, y varias solicitudes de PersistentVolumeClaim, así como los nodos que tienen SSDs locales disponibles, al seleccionar un nodo para un pod ejecutable.

En este ejemplo se usa el modo de enlace de volumen diferido:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: "local-nvme"
provisioner: "kubernetes.io/no-provisioner"
volumeBindingMode: "WaitForFirstConsumer"

Para crear un StorageClass con enlace retrasado, guarda el manifiesto YAML en un archivo local y aplícalo al clúster con el siguiente comando:

kubectl apply -f filename

Solución de problemas

Para obtener instrucciones sobre cómo solucionar problemas, consulta el artículo Solucionar problemas de almacenamiento en GKE.

Siguientes pasos

• Obtén más información sobre los grupos de nodos.