SSD locales

En esta página, se proporciona una descripción general de la compatibilidad con SSD locales en Kubernetes y cómo usarlos con Google Kubernetes Engine (GKE).

Descripción general

Los SSD locales proporcionan almacenamiento efímero y de alto rendimiento para todos los nodos del clúster. Los SSD locales proporcionan mayor capacidad de procesamiento y menor latencia que los discos estándar. Funcionan bien en las cargas de trabajo que proporcionan almacenamiento en caché local y procesamiento.

Puedes crear grupos de nodos con SSD locales dentro de los límites del tipo de máquina de tu clúster y las cuotas del proyecto.

  • Los datos escritos en un SSD local son efímeros y no se conservan cuando se borra, repara, actualiza o experimenta un error irrecuperable.

  • Un 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 los SSD locales, consulta SSD locales en la documentación de Compute Engine.

Crea un clúster con SSD locales

Puedes crear un clúster o actualizar uno para usar SSD locales mediante Google Cloud Console o la herramienta de línea de comandos de gcloud.

Console

Puedes crear un clúster o grupo de nodos con SSD locales desde el menú de GKE en Cloud Console.

Para crear un clúster en el que el grupo predeterminado use discos SSD locales, sigue estos pasos:

  1. Dirígete al menú de Google Kubernetes Engine en Cloud Console.

    Ir al menú Google Kubernetes Engine

  2. Haz clic en el botón Crear clúster.

  3. En el panel de navegación, en Grupos de nodos, haz clic en grupo predeterminado.

  4. En Cantidad de nodos, ingresa 2.

  5. En el panel de navegación, en grupo predeterminado, haz clic en Nodos.

  6. Expande el menú Plataforma de CPU y GPU.

  7. Para los Discos SSD locales, ingresa la cantidad deseada de SSD como número absoluto.

  8. Haz clic en Crear.

Para crear un grupo de nodos con los discos SSD locales en un clúster existente, sigue estos pasos:

  1. Dirígete al menú de Google Kubernetes Engine en Cloud Console.

    Ir al menú Google Kubernetes Engine

  2. Selecciona el clúster que desees.

  3. Haz clic en Editar.

  4. En grupos de nodos, haz clic en Agregar grupo de nodos.

  5. Para Tamaño, ingresa 1.

  6. Para Discos SSD locales (por nodo), ingresa la cantidad deseada de SSD como número absoluto.

  7. Haz clic en Guardar.

gcloud

Para crear un clúster o grupo de nodos con SSD locales mediante gcloud, especifica la marca --local-ssd count. --local-ssd-count especifica la cantidad de SSD locales que se crearán por nodo. La cantidad máxima varía según el tipo de máquina y la región. Cuando se crean nodos, los SSD locales se formatean y se activan de forma automática en el sistema de archivos del nodo en puntos de activación, como /mnt/disks/ssd0 para el primer disco, /mnt/disks/ssd1 para el segundo disco, etc.

Para crear un clúster en el que el grupo predeterminado use discos SSD locales, ejecuta el siguiente comando:

gcloud container clusters create cluster-name \
  --num-nodes 2 \
  --local-ssd-count number-of-disks

en el que number-of-disks es la cantidad deseada de discos como número absoluto.

Para crear un grupo de nodos con discos SSD locales en un clúster existente, ejecuta el siguiente comando:

gcloud container node-pools create pool-name \
  --cluster cluster-name \
  --num-nodes 1 \
  --local-ssd-count number-of-disks

Formatea SSD locales para clústeres de Windows Server

Cuando usas SSD locales con tus clústeres que ejecutan grupos de nodos de Windows Server, debes acceder al nodo y formatear el disco antes de usarlo. En el siguiente ejemplo, el disco SSD local está formateado con el sistema de archivos NTFS. También puedes crear directorios en el disco. En este ejemplo, los directorios están en el disco D.

PS C:\> Get-Disk | Where partitionstyle -eq 'raw' | Initialize-Disk -PartitionStyle MBR -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem ntfs -Confirm:$false
PS C:\> mkdir D:\test-ss

Usa SSD locales

En la sección siguiente, se explica cómo usar SSD locales con GKE.

Puedes acceder a los SSD locales con uno de estos dos métodos:

  • Se recomienda usar los volúmenes de la ruta del host para las tareas siguientes:

    • Cargas de trabajo que usan DaemonSets.
    • Cargas de trabajo que usan grupos de nodos exclusivos. Se debe acceder a todos los SSD locales en la misma ruta en todas las instancias de un DaemonSet.
  • Los PersistentVolumes locales están disponibles para el público en general (GA) en la versión 1.14.x de GKE y posteriores.

    Se recomiendan para las siguientes tareas:

    • Cargas de trabajo que usan StatefulSets y volumeClaimTemplates.
    • Cargas de trabajo que comparten grupos de nodos. Cada SSD local se puede reservar a través de un PersistentVolumeClaim (PVC). Las rutas de acceso de host específicas no se codificarán 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 como su PersistentVolume local.

Ejemplos en los que se usan volúmenes hostPath

En los siguientes ejemplos, se muestra cómo usar volúmenes hostPath para Windows y Linux.

Linux

Si creas un grupo de nodos con tres SSD locales, el SO host activa los discos en /mnt/disks/ssd0, /mnt/disks/ssd1 y /mnt/disks/ssd2. Tus contenedores de Kubernetes acceden a los discos mediante el parámetro hostPath definido en el archivo de configuración de tu objeto.

Este archivo de configuración de pod de ejemplo hace referencia a un SSD local: /mnt/disks/ssd0:

apiVersion: v1
kind: Pod
metadata:
  name: "test-ssd"
spec:
  containers:
  - name: "shell"
    image: "ubuntu:14.04"
    command: ["/bin/sh", "-c"]
    args: ["echo 'hello world' > /test-ssd/test.txt && sleep 1 && cat /test-ssd/test.txt"]
    volumeMounts:
    - mountPath: "/test-ssd/"
      name: "test-ssd"
  volumes:
  - name: "test-ssd"
    hostPath:
      path: "/mnt/disks/ssd0"
  nodeSelector:
    cloud.google.com/gke-local-ssd: "true"

Windows

apiVersion: v1
kind: Pod
metadata:
name: "test-ssd"
spec:
containers:
- name: "test"
  image: "mcr.microsoft.com/windows/servercore/iis"
  volumeMounts:
  - mountPath: "/test-ssd/"
    name: "test-ssd"
volumes:
- name: "test-ssd"
  hostPath:
    path: "d:\\test-ssd"
nodeSelector:
  cloud.google.com/gke-local-ssd: "true"
  kubernetes.io/os: windows

Ejemplos en los que se usan PersistentVolumes locales

Los SSD locales se pueden especificar como PersistentVolumes.

Puedes crear PersistentVolumes desde SSD locales si creas un PersistentVolume de forma manual o si ejecutas el aprovisionador estático de volumen local.

Limitaciones

Crea el PersistentVolume de forma manual

Puedes crear un PersistentVolume de forma manual para todos los SSD locales de cada nodo del clúster.

Usa el campo nodeAffinity en un objeto PersistentVolume para hacer referencia a un SSD local en un nodo específico. Por ejemplo, el siguiente ejemplo de Linux es una especificación de PersistentVolume para un SSD local activado en /mnt/disks/ssd0 en el nodo gke-test-cluster-default-pool-926ddf80-f166:

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"

Windows

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ssd-local-pv
spec:
  capacity:
    storage: 375Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: "d:\\test-ssd"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - gke-gke-cluster-windows-dds-2263bc7c-wq6m
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: ssd-local-claim
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: local-storage
  resources:
    requests:
      storage: 37Gi

Ahora puedes crear un pod para acceder al disco. Para asegurarte de que tus pods se programen de forma correcta en los nodos de Windows Server, debes agregar un selector de nodos a tu especificación de pods:

apiVersion: v1
kind: Pod
metadata:
  name: "test-ssd"
spec:
  containers:
  - name: "test"
    image: "mcr.microsoft.com/windows/servercore/iis"
    volumeMounts:
    - mountPath: "/test-ssd/"
      name: "test-ssd"
  volumes:
  - name: "test-ssd"
    persistentVolumeClaim:
      claimName: ssd-local-claim
  nodeSelector:
    cloud.google.com/gke-local-ssd: "true"
  tolerations:
  - key: "node.kubernetes.io/os"
    value: "windows"
    operator: "Equal"
    effect: "NoSchedule"

Si borras el PersistentVolume, deberás borrar de forma manual los datos del disco.

Ejecuta el aprovisionador estático de volumen local

Puedes crear PersistentVolumes para SSD locales de forma automática mediante el aprovisionador estático de volumen local. El aprovisionador es un DaemonSet que administra los SSD locales en cada nodo, crea y borra PersistentVolumes para estos y limpia los datos en el SSD local cuando se libera el PersistentVolume.

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

  1. Descarga la especificación gke.yaml del repositorio sig-storage-local-static-provisioner y modifica los campos namespace de la especificación según sea necesario.

    La especificación incluye estos elementos:

    • ServiceAccount para el aprovisionador
    • ClusterRole y ClusterRoleBindings con permiso para realizar lo siguiente:
      • Crear y borrar los objetos PersistentVolume
      • Obtener objetos del nodo
    • ConfigMap con la configuración del aprovisionador para GKE
    • DaemonSet para ejecutar el aprovisionador
  2. Implementa el aprovisionador:

    kubectl apply -f gke.yaml
    

Una vez que el aprovisionador se ejecute de forma correcta, crea un objeto PersistentVolume para cada SSD local en el clúster.

Habilita la vinculación de volumen demorada

Para mejorar la programación, se recomienda crear también una StorageClass con volumeBindingMode: WaitForFirstConsumer. Esto demora la vinculación de PersistentVolumeClaim (PVC) hasta la programación del pod, de modo que se elige un SSD local de un nodo apropiado que pueda ejecutar el pod. Este comportamiento de programación mejorado considera las solicitudes de CPU y memoria de pods, la afinidad de nodos, la afinidad y la antiafinidad de pods, y las solicitudes de varias PVC, junto con los nodos que tienen SSD locales disponibles, cuando seleccionas un nodo para un pod ejecutable.

En este ejemplo, se usa el modo de vinculación de volumen demorado:

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

Cuando usas clústeres con grupos de nodos de Windows Server, debes crear una StorageClass porque la StorageClass predeterminada usa ext4 como el tipo de sistema de archivos, que solo funciona con contenedores de Linux.

En el siguiente archivo YAML llamado storageclass-name, se usa un disco persistente de Compute Engine con NTFS como tipo de almacenamiento de archivos. Puedes usar esta StorageClass cuando trabajas con clústeres de Windows.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: storageclass-name
parameters:
  type: pd-standard
  fstype: NTFS
provisioner: kubernetes.io/gce-pd
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Para crear una StorageClass con vinculación demorada, guarda el manifiesto YAML en un archivo local y aplícalo al clúster mediante el siguiente comando:

kubectl apply -f filename

Próximos pasos