Usa el controlador de CSI de Persistent Disk de Compute Engine

Google Kubernetes Engine (GKE) proporciona una forma sencilla de implementar de forma automática y administrar el controlador de interfaz de almacenamiento de contenedores (CSI) del disco persistente de Compute Engine en tus clústeres. El controlador de CSI de disco persistente de Compute Engine siempre está habilitado en los clústeres de Autopilot y no se puede inhabilitar ni editar. En los clústeres de Standard, debes habilitar el controlador CSI del disco persistente de Compute Engine.

La versión del controlador de CSI del disco persistente de Compute Engine está vinculada a los números de la versión de GKE. La versión del controlador de CSI del disco persistente de Compute Engine suele ser el controlador más reciente disponible en el momento en que se lanza la versión de GKE. Los controladores se actualizan de forma automática cuando el clúster se actualiza al último parche de GKE.

Ventajas

El uso del controlador de CSI del disco persistente de Compute Engine proporciona los siguientes beneficios:

• Esto permite la implementación y la administración automáticas del controlador del disco persistente sin tener que configurarlo de forma manual.
• Puedes usar claves de encriptación administradas por el cliente (CMEK). Estas se usan para encriptar las claves de encriptación de datos que encriptan tus datos. Para obtener más información sobre CMEK en GKE, consulta Usa CMEK.
• Puedes usar instantáneas de volumen con el controlador de CSI del disco persistente de Compute Engine. Las instantáneas de volumen te permiten crear una copia del volumen en un momento específico. Puedes usar esta copia para hacer que un volumen vuelva a su estado anterior o con el fin de aprovisionar un volumen nuevo.
• Puedes usar la clonación de volúmenes con el controlador de CSI del disco persistente de Compute Engine en clústeres que ejecutan la versión 1.22 de GKE y, luego, la clonación de volúmenes posterior te permite crear un duplicado de tu volumen en un momento determinado, aprovisionado con todos los datos del volumen de origen. La corrección de errores y la actualización de funciones se lanzan de forma independiente de las actualizaciones secundarias de Kubernetes.
• La corrección de errores y la actualización de funciones se lanzan de forma independiente de las actualizaciones secundarias de Kubernetes. Por lo general, este programa de lanzamiento da como resultado una cadencia de actualización más rápida.

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

• Habilitar la API de Google Kubernetes Engine
Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI.
• Para usar Google Cloud CLI para esta tarea, instala y luego inicializa gcloud CLI. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos de este documento. Si instalaste gcloud CLI anteriormente, obtén la versión más reciente ejecutando el comando gcloud components update. **Nota:** Para las instalaciones de gcloud CLI existentes, asegúrate de configurar la propiedad `compute/region`.

Para habilitar el controlador de CSI de disco persistente de Compute Engine en clústeres estándar existentes, usa Google Cloud CLI o laconsola.

Para habilitar el controlador en un clúster existente, completa los siguientes pasos: Cloud de Confiance

gcloud

gcloud container clusters update CLUSTER-NAME \
   --update-addons=GcePersistentDiskCsiDriver=ENABLED

Después de que hayas habilitado el controlador de CSI de disco persistente de Compute Engine, puedes usar el controlador en volúmenes de Kubernetes mediante el nombre del controlador y del aprovisionador: pd.csi.storage.gke.io.

Puedes inhabilitar el controlador de CSI del disco persistente de Compute Engine para clústeres estándar mediante Google Cloud CLI o laconsola.

Puedes inhabilitar el controlador CSI de disco persistente de Compute Engine para clústeres estándar con Google Cloud CLI o la Cloud de Confiance consola.

Además, fallará el inicio de todos los Pods nuevos que intenten usar esos PersistentVolumes. Además, fallará el inicio de todos los Pods nuevos que intenten usar esos PersistentVolumes.

Para inhabilitar el controlador en un clúster Estándar existente, completa los siguientes pasos:

gcloud container clusters update CLUSTER-NAME \
    --update-addons=GcePersistentDiskCsiDriver=DISABLED

En las siguientes secciones, se describe el proceso típico para usar disco persistente de Kubernetes respaldado por un controlador de CSI en GKE.

Estas secciones son específicas para clústeres que usan Linux. Estas secciones son específicas para clústeres que usan Linux.

Crea un StorageClass

Después de habilitar el controlador CSI del disco persistente de Compute Engine, GKE instala de forma automática las siguientes StorageClasses:

• standard-rwo, con disco persistente balanceado
• premium-rwo, con disco persistente SSD

Para los clústeres Autopilot, la StorageClass predeterminada es standard-rwo, que usa el controlador de CSI del disco persistente de Compute Engine. Para los clústeres estándar, la StorageClass predeterminada usa el complemento de volumen gcePersistentDisk en árbol de Kubernetes.

Para encontrar el nombre de la StorageClass instalada, ejecuta el siguiente comando:

kubectl get sc

Por ejemplo, puedes crear una StorageClass con el siguiente archivo llamado `pd-example-class.yaml`.pd.csi.storage.gke.io

Por ejemplo, puedes crear una StorageClass con el siguiente archivo, que se llama pd-example-class.yaml.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-example
provisioner: pd.csi.storage.gke.io
# Recommended setting. Delays the binding and provisioning of a PersistentVolume until a Pod that uses the
# PersistentVolumeClaim is created and scheduled on a node.
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-balanced

Puede especificar los siguientes tipos de discos persistentes en el parámetro type:

• pd-balanced
• pd-ssd
• pd-standard
• Si usas `pd-standard` o pd-extreme, consulta los tipos de máquinas no compatibles para conocer las restricciones adicionales de uso.

Si usas pd-standard o pd-extreme, consulta los tipos de máquinas no compatibles para conocer las restricciones adicionales de uso.

Cuando usas la opción pd-extreme, también debes agregar el campo provisioned-iops-on-create a tu manifiesto. Este campo debe configurarse con el mismo valor que el valor de IOPS aprovisionado que especificaste cuando creaste el disco persistente.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-extreme-example
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-extreme
  provisioned-iops-on-create:'10000'

Después de crear el archivo pd-example-class.yaml, ejecuta el siguiente comando:

kubectl create -f pd-example-class.yaml

Crea una PersistentVolumeClaim

Puedes crear una PersistentVolumeClaim que haga referencia a la StorageClass del controlador de CSI del disco persistente de Compute Engine.

En el siguiente archivo, llamado pvc-example.yaml, se usa la clase de almacenamiento standard-rwo instalada previamente:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: standard-rwo
  resources:
    requests:
      storage: 6Gi

Después de crear el manifiesto de PersistentVolumeClaim, ejecuta el siguiente comando:

kubectl create -f pvc-example.yaml

En la StorageClass instalada previamente (standard-rwo), volumeBindingMode se configura como WaitForFirstConsumer. Cuando volumeBindingMode se establece como WaitForFirstConsumer, el PersistentVolume no se aprovisiona hasta que se programa un Pod que haga referencia a la PersistentVolumeClaim. Si volumeBindingMode en la StorageClass se configura como Immediate (o se omite), se aprovisiona un PersistentVolume respaldado por un disco persistente luego de que se crea la PersistentVolumeClaim.

Crea un Pod que consuma el volumen

Si bien no se suele usar un Pod independiente, en el siguiente ejemplo, se usa uno para mayor simplicidad. En el siguiente ejemplo, se consume el volumen que creaste en la sección anterior:

Usa el controlador de CSI del disco persistente de Compute Engine para clústeres de Windows

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  containers:
   - name: web-server
     image: nginx
     volumeMounts:
       # The path in the container where the volume will be mounted.
       - mountPath: /var/lib/www/html
         # The name of the volume that is being defined in the "volumes" section.
         name: mypvc
  volumes:
   - name: mypvc
     persistentVolumeClaim:
       # References the PersistentVolumeClaim created earlier.
       claimName: podpvc
       readOnly: false

En las siguientes secciones, se describe el proceso típico para usar un volumen de Kubernetes respaldado por un controlador de CSI en GKE.

Estas secciones son específicas para clústeres que usan Windows. Estas secciones son específicas para clústeres que usan Windows.

Asegúrate de que se cumplan estas condiciones:

• La versión del clúster es 1.19.7-gke.2000, 1.20.2-gke.2000 o superior.
• Las versiones de nodo son 1.18.12-gke.1203, 1.19.6-gke.800 o superiores.

Crea un StorageClass

Crear una StorageClass para Windows es muy similar a hacerlo en Linux. Debes tener en cuenta que la StorageClass instalada de forma predeterminada no funcionará para Windows porque el tipo de sistema de archivos es diferente. El controlador de CSI de disco persistente de Compute Engine para Windows requiere NTFS como tipo de sistema de archivos.

Por ejemplo, puedes crear una StorageClass mediante el siguiente archivo llamado pd- windows-class.yaml. Asegúrate de agregar csi.storage.k8s.io/fstype: NTFS a la lista de parámetros:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-sc-windows
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-balanced
  csi.storage.k8s.io/fstype: NTFS

Crea una PersistentVolumeClaim

Después de crear una StorageClass para Windows, puedes crear un PersistentVolumeClaim que haga referencia a esa StorageClass:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc-windows
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: pd-sc-windows
  resources:
    requests:
      storage: 6Gi

Crea un Pod que consuma el volumen

Modifica de forma dinámica las IOPS y la capacidad de procesamiento de Hyperdisk con `VolumeAttributeClass`

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  # Node selector to ensure the Pod runs on a Windows node.
  nodeSelector:
    kubernetes.io/os: windows
  containers:
    - name: iis-server
      # The container image to use.
      image: mcr.microsoft.com/windows/servercore/iis
      ports:
      - containerPort: 80
      volumeMounts:
      # The path in the container where the volume will be mounted.
      - mountPath: /var/lib/www/html
        name: mypvc
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        # References the PersistentVolumeClaim created earlier.
        claimName: podpvc-windows
        readOnly: false

Puedes usar VolumeAttributeClass con el controlador de CSI del disco persistente de Compute Engine para modificar de forma dinámica los atributos del disco persistente, incluidas las IOPS y la capacidad de procesamiento.

Puedes usar VolumeAttributesClass con el controlador CSI de disco persistente de Compute Engine para modificar de forma dinámica los atributos de disco persistente, como las IOPS y el rendimiento. En esta sección, se muestra cómo usar `clúster de GKE.

Creas dos recursos VolumeAttributesClass, `silver` y `gold`, para definir diferentes niveles de IOPS y capacidad de procesamiento. Creas dos recursos VolumeAttributesClass, silver y gold, para definir diferentes niveles de IOPS y rendimiento. Por último, actualizas la StorageClass para que haga referencia al nivel PersistentVolumeClaim, lo que realiza una actualización dinámica de la configuración de rendimiento del volumen.silver Finalmente, actualizas el PersistentVolumeClaim para hacer referencia al nivel gold, lo que realiza una actualización dinámica de la configuración de rendimiento del volumen.

En esta sección, se definen los recursos VolumeAttributesClass con los niveles de ejemplo llamados `silver` y `gold`.

Guarda el siguiente manifiesto como `vac-classes.yaml`:VolumeAttributesClasssilvergold

1. Guarda el siguiente manifiesto como vac-classes.yaml

   apiVersion: storage.k8s.io/v1
   kind: VolumeAttributesClass
   metadata:
     name: silver
   driverName: pd.csi.storage.gke.io
   parameters:
     iops: "3000"
     throughput: "188Mi"
   ---
   apiVersion: storage.k8s.io/v1
   kind: VolumeAttributesClass
   metadata:
     name: gold
   driverName: pd.csi.storage.gke.io
   parameters:
     iops: "6000"
     throughput: "345Mi"
   

2. Crea una StorageClass para Hyperdisk

   kubectl apply -f vac-classes.yaml
   

En esta sección, se define un recurso `StorageClass` para aprovisionar volúmenes de Hyperdisk.

Guarda el siguiente manifiesto como `StorageClass`:

1. Guarda el siguiente manifiesto como hyperdisk-sc.yaml

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: hyperdisk-example
   provisioner: pd.csi.storage.gke.io
   volumeBindingMode: WaitForFirstConsumer
   allowVolumeExpansion: true
   parameters:
     type: hyperdisk-balanced
   

2. Crea una PVC con un nivel de rendimiento inicial

   kubectl apply -f hyperdisk-sc.yaml
   

En esta sección, se crea una PVC y se usa el nivel inicial llamado `silver`.

Guarda el siguiente manifiesto como `vac-silver-pvc.yaml`:

1. Guarda el siguiente manifiesto como vac-silver-pvc.yaml

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-pv-claim
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: hyperdisk-example
     volumeAttributesClassName: silver
     resources:
       requests:
         storage: 200Gi
   

2. Para aprovisionar un volumen persistente, crea un Pod que consuma la PVC.

   kubectl apply -f vac-silver-pvc.yaml
   

3. La `StorageClass` creada en la sección anterior establece `volumeBindingMode: WaitForFirstConsumer`, lo que retrasa el aprovisionamiento del volumen hasta que un Pod consume la PVC. El StorageClass creado en la sección anterior establece volumeBindingMode: WaitForFirstConsumer, lo que retrasa el aprovisionamiento del volumen hasta que un Pod consume el PVC. Guarda el siguiente manifiesto como test-pod.yaml

   apiVersion: v1
   kind: Pod
   metadata:
     name: test-pvc-pod
   spec:
     containers:
       - name: nginx-container
         image: nginx:latest
         ports:
           - containerPort: 80
         volumeMounts:
           - name: pvc-storage
             mountPath: /usr/share/nginx/html
     volumes:
       - name: pvc-storage
         persistentVolumeClaim:
           claimName: test-pv-claim
   

4. Para verificar la configuración de rendimiento del disco, consulta Verifica la configuración de rendimiento del disco en laconsola.

   kubectl apply -f test-pod.yaml
   

5. Para verificar la configuración de rendimiento del disco, consulte Verificar la configuración de rendimiento del disco en la Cloud de Confiance consola. El IOPS aprovisionado debe ser 3000 y el rendimiento aprovisionado debe ser 188, respectivamente.

En esta sección, se actualiza la PVC para usar el nivel `gold` en lugar del nivel `silver`.

Esta sección actualiza el PVC para usar el nivel gold en lugar del nivel silver.

1. Guarda el siguiente manifiesto como vac-gold-pvc.yaml

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-pv-claim
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: hyperdisk-example
     volumeAttributesClassName: gold
     resources:
       requests:
         storage: 200Gi
   

2. Para verificar que se actualizó la configuración de rendimiento del disco, consulta Verifica la configuración de rendimiento del disco en laconsola.

   kubectl apply -f vac-gold-pvc.yaml
   

3. Para verificar que la configuración de rendimiento del disco se haya actualizado, consulte Verificar la configuración de rendimiento del disco en la Cloud de Confiance consola. El IOPS aprovisionado debe ser 6000 y el rendimiento aprovisionado debe ser 345, respectivamente.

Para verificar que la configuración de IOPS y capacidad de procesamiento se aplique al disco persistente, consulta los detalles del disco en la Cloud de Confiance consola.

Puedes verificar que la configuración de IOPS y rendimiento se aplique al disco persistente consultando los detalles del disco en la Cloud de Confiance consola.

1. En laconsola, ve a la página **Discos**.

   PV_NAME=$(kubectl get pvc test-pv-claim -o=jsonpath='{.spec.volumeName}')
   DISK_NAME=$(kubectl get pv $PV_NAME -o=jsonpath='{.spec.csi.volumeHandle}' | sed 's|.*/||')
   echo "Persistent disk name: $DISK_NAME"
   

2. En la consola, ir a la página de Discos Cloud de Confiance

   Haz clic en el nombre del disco persistente que coincida con el nombre del disco del resultado del paso anterior.

3. En la página **Detalles del disco persistente** , en la sección **Rendimiento** , consulta las **IOPS aprovisionadas** y la **capacidad de procesamiento aprovisionada**.

4. En la página Detalles del disco, en la sección Rendimiento, consulta IOPS aprovisionadas y Rendimiento aprovisionado.

Para obtener más información, consulta Ver la configuración de rendimiento aprovisionado para Hyperdisk.

**Vuelve a aplicar las configuraciones anteriores:** Si una PVC no puede vincularse con una clase de atributos de volumen debido a un error, como recursos no disponibles, puedes volver a aplicar la PVC anterior de forma segura.

• Compatibilidad con cuotas: El plano de control de Kubernetes puede aplicar cuotas en las PVC que hacen referencia a una `VolumeAttributesClass` específica mediante `scopeSelector` en `ResourceQuota`.
• Compatibilidad con cuotas: El plano de control de Kubernetes puede aplicar cuotas en los PVC que hacen referencia a un VolumeAttributesClass específico mediante el uso de scopeSelector en ResourceQuota.

El tipo de sistema de archivos predeterminado para los disco persistente de Compute Engine en GKE es `ext4`.

El tipo de sistema de archivos predeterminado para los discos persistentes de Compute Engine en GKE es ext4. También puedes usar el tipo de almacenamiento xfs siempre que la imagen de tu nodo lo admita. Consulta Compatibilidad de controladores de almacenamiento para obtener una lista de controladores compatibles por imagen de nodo.

En el siguiente ejemplo, se muestra cómo usar xfs como el tipo de sistema de archivos predeterminado en lugar de ext4 con el controlador de CSI del disco persistente de Compute Engine.

Crea un StorageClass

1. Guarda el siguiente manifiesto YAML como un archivo llamado pd-xfs-class.yaml.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: xfs-class
   provisioner: pd.csi.storage.gke.io
   parameters:
     # The type of Compute Engine persistent disk to provision.
     type: pd-balanced
     # Specify "xfs" as the filesystem type.
     csi.storage.k8s.io/fstype: xfs
   volumeBindingMode: WaitForFirstConsumer
   

2. Aplica el manifiesto

   kubectl apply -f pd-xfs-class.yaml
   

Crea una PersistentVolumeClaim

1. Guarda el siguiente manifiesto como pd-xfs-pvc.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: xfs-pvc
   spec:
     # References the StorageClass created earlier.
     storageClassName: xfs-class
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         # The amount of storage requested.
         storage: 10Gi
   

2. Aplica el manifiesto

   kubectl apply -f pd-xfs-pvc.yaml
   

Crea un Pod que consuma el volumen

1. Guarda el siguiente manifiesto como pd-xfs-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: pd-xfs-pod
   spec:
     containers:
     - name: cloud-sdk
       image: google/cloud-sdk:slim
       # Keep the container running for 1 hour.
       args: ["sleep","3600"]
       volumeMounts:
       # The path in the container where the volume will be mounted.
       - mountPath: /xfs
         name: xfs-volume
     # Define the volumes available to the containers in the Pod.
     volumes:
     - name: xfs-volume
       persistentVolumeClaim:
         # References the PersistentVolumeClaim created earlier.
         claimName: xfs-pvc
   

2. Aplica el manifiesto

   kubectl apply -f pd-xfs-pod.yaml
   

Verifica que el volumen se haya activado de forma correcta

1. Abre una sesión de shell en el Pod:

   kubectl exec -it pd-xfs-pod -- /bin/bash
   

2. Busca particiones xfs:

   df -aTh --type=xfs
   

   El resultado debería ser similar al ejemplo siguiente:

   Filesystem     Type  Size  Used Avail Use% Mounted on
   /dev/sdb       xfs    30G   63M   30G   1% /xfs
   

Visualiza los registros del controlador de CSI de Persistent Disk para Compute Engine

Puedes usar Cloud Logging para ver eventos relacionados con el controlador de CSI de Persistent Disk para Compute Engine. Los registros pueden ayudarte a solucionar problemas.

Para obtener más información sobre Cloud Logging, consulta Visualiza los registros de GKE.

Ve a la página **Cloud Logging** en laconsola.

1. Ir a Cloud Logging en la Cloud de Confiance consola.

   Para filtrar las entradas de registro de modo que solo muestren las entradas relacionadas con el controlador de CSI que se ejecuta en tu espacio de nombres, ejecuta la siguiente consulta de Cloud Logging:

2. Reemplaza lo siguiente:

    resource.type="k8s_container"
    resource.labels.project_id="PROJECT_ID"
    resource.labels.location="LOCATION"
    resource.labels.cluster_name="CLUSTER_NAME"
    resource.labels.namespace_name="kube-system";
    resource.labels.container_name="gce-pd-driver"
   

   `PROJECT_ID`: nombre del proyecto.

   • PROJECT_ID: nombre del proyecto.
   • LOCATION: la región o zona de Compute Engine del clúster.
   • CLUSTER_NAME: El nombre de tu clúster.

Problemas conocidos

Tipos de máquinas no compatibles

Si usas la familia de máquinas de la serie C3, el tipo de disco persistente pd-standard no es compatible.

Si intentas ejecutar un Pod en una máquina y el Pod usa un tipo de disco persistente no compatible, verás un mensaje de advertencia como el siguiente que se emite en el Pod:

AttachVolume.Attach failed for volume "pvc-d7397693-5097-4a70-9df0-b10204611053" : rpc error: code = Internal desc = unknown Attach error: failed when waiting for zonal op: operation operation-1681408439910-5f93b68c8803d-6606e4ed-b96be2e7 failed (UNSUPPORTED_OPERATION): [pd-standard] features are not compatible for creating instance.

Si tu clúster tiene varios grupos de nodos con diferentes familias de máquinas, puedes usar taints de nodos y afinidad de nodos para limitar las cargas de trabajo se puede programar. Por ejemplo, puedes usar este método para restringir la ejecución de una carga de trabajo con pd-standard en una familia de máquinas no compatible.

Si usas el tipo de disco persistente pd-extreme, debes asegurarte de que el disco esté conectado a una instancia de VM con una forma de máquina adecuada. Para obtener más información, consulta Compatibilidad con formas de máquinas.

¿Qué sigue?

• Obtén más información sobre cómo usar la expansión de volúmenes.
• Obtén información sobre cómo usar las instantáneas de volumen.
• Obtén más información sobre cómo crear discos persistentes regionales.
• Obtén más información sobre el controlador en GitHub.
• Obtén más información sobre el controlador en GitHub.