Aprovisionar discos persistentes regionales y volúmenes de Hyperdisk Balanced High Availability

En esta página se explica cómo habilitar el aprovisionamiento dinámico de volúmenes de alta disponibilidad de Hyperdisk Balanced y discos persistentes regionales, así como cómo aprovisionarlos manualmente en Google Kubernetes Engine (GKE). Para obtener información sobre la compatibilidad de los tipos de máquinas, consulta las limitaciones de los discos regionales y la compatibilidad de las series de máquinas con Hyperdisk. Por lo general, debes usar volúmenes Hyperdisk Balanced High Availability en series de máquinas de tercera generación o posteriores, y discos persistentes regionales en series de máquinas de segunda generación o anteriores. Para obtener más información sobre la generación de series de máquinas, consulta la terminología de Compute Engine.

Para crear soluciones completas para aplicaciones de alta disponibilidad con discos persistentes regionales, consulta Aumentar la disponibilidad de aplicaciones con estado con Stateful HA Operator. Esta función no admite volúmenes de Hyperdisk Balanced High Availability.

Hyperdisk Balanced High Availability

En este ejemplo se muestra cómo pueden aprovisionarse dinámicamente los volúmenes de Hyperdisk Balanced High Availability según sea necesario o cómo puede aprovisionarlos manualmente el administrador del clúster con antelación.

Aprovisionamiento dinámico

  1. Guarda el siguiente manifiesto en un archivo llamado balanced-ha-storage.yaml.

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: balanced-ha-storage
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
# Allow volume expansion.
allowVolumeExpansion: true
parameters:
  type: hyperdisk-balanced-high-availability
  # Provisioned throughput in MiB/s.
  provisioned-throughput-on-create: "250Mi"
  # Provisioned IOPS (input/output operations per second).
  provisioned-iops-on-create: "7000"
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - ZONE1
    - ZONE2

    Haz los cambios siguientes:

    • ZONE1 y ZONE2: las zonas de la región en las que se replicará el volumen aprovisionado dinámicamente.

  2. Crea el objeto StorageClass:

    kubectl create -f hdb-ha-example-class.yaml

  3. Guarda el siguiente manifiesto de PersistentVolumeClaim en un archivo llamado pvc-example.yaml:

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ACCESS_MODE
  storageClassName: balanced-ha-storage
  resources:
    requests:
      storage: 20Gi

    Haz los cambios siguientes:

    • ACCESS_MODE: Hyperdisk Balanced High Availability admite ReadWriteOnce, ReadWriteMany y ReadWriteOncePod. Para ver las diferencias y los casos prácticos de cada modo de acceso, consulta Modos de acceso de volúmenes persistentes.
    • Si decides usar ReadWriteMany, también debes añadir volumeMode: Block a PersistentVolumeClaim. Este ajuste evita que se dañen los datos, lo que puede ocurrir si varios pods escriben en el almacenamiento simultáneamente. El ajuste volumeMode: Block expone el disco como un dispositivo de bloque sin formato que omite la gestión del sistema de archivos por parte de Kubernetes. A continuación, se muestra un ejemplo:
      kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: podpvc
  spec:
    accessModes:
    - ReadWriteMany
    volumeMode: Block
    storageClassName: balanced-ha-storage
    resources:
      requests:
        storage: 20Gi
  ```

  4. Aplica el PersistentVolumeClaim que hace referencia al StorageClass que has creado anteriormente:

    kubectl apply -f pvc-example.yaml

Aprovisionamiento manual

  1. Sigue la documentación de Compute Engine para crear manualmente un volumen de Hyperdisk Balanced High Availability.

  2. Guarda el siguiente manifiesto de PersistentVolume en un archivo llamado pv-example.yaml. El manifiesto hace referencia al volumen de Hyperdisk Balanced High Availability que acabas de crear:

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-demo
spec:
  capacity:
    storage: 500Gi
  accessModes:
    - ACCESS_MODE
  # ClaimRef links this PersistentVolume to a PersistentVolumeClaim.
  claimRef:
    namespace: default
    name: podpvc
  csi:
    driver: pd.csi.storage.gke.io
    # The unique identifier of the Compute Engine disk resource that backs this volume.
    volumeHandle: projects/PROJECT_ID/regions/REGION/disks/gce-disk-1
  # Node affinity to ensure the Pod is scheduled in a zone where the volume is replicated.
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
          - key: topology.gke.io/zone
            operator: In
            values:
            - ZONE1
            - ZONE2

    Haz los cambios siguientes:

    • PROJECT_ID: el ID del proyecto del volumen que has creado.
    • REGION: la región del disco que has creado. Consulta la documentación de Compute Engine para ver la disponibilidad regional más reciente.
    • ZONE1 y ZONE2: las zonas de la región en las que se replica el volumen que has creado.
    • ACCESS_MODE: Hyperdisk Balanced High Availability admite ReadWriteOnce, ReadWriteMany y ReadWriteOncePod. Para ver las diferencias y los casos prácticos de cada modo de acceso, consulta Modos de acceso de volúmenes persistentes.

  3. Crea el volumen persistente que haga referencia al volumen de Hyperdisk Balanced High Availability que has creado anteriormente:

    kubectl apply -f pv-example.yaml

  4. Guarda el siguiente manifiesto de PersistentVolumeClaim en un archivo llamado pvc-example.yaml:

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ACCESS_MODE
  storageClassName: balanced-ha-storage
  resources:
    requests:
      storage: 20Gi

    Haz los cambios siguientes:

    • ACCESS_MODE: Hyperdisk Balanced High Availability admite ReadWriteOnce, ReadWriteMany y ReadWriteOncePod. Debe ser el mismo modo de acceso que el especificado en PersistentVolume en el paso anterior. Para ver las diferencias y los casos prácticos de cada modo de acceso, consulta Modos de acceso de volúmenes persistentes.

  5. Aplica la reclamación de volumen persistente que hace referencia al volumen persistente que has creado anteriormente:

    kubectl apply -f pvc-example.yaml

Usar un volumen multiescritura en modo de bloque

Para usar un volumen en modo de bloque, debes especificar volumeBlock en lugar de volumeMounts en el pod consumidor. Un Pod de ejemplo que use el PersistenVolumeClaim que hemos presentado anteriormente debería tener el siguiente aspecto:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        # Use volumeDevices instead of volumeMounts to consume the volume as a raw block device.
        volumeDevices:
        # The "mountPath" field specifies the path where the block device is accessible in the container.
        - mountPath: /dev/my-device
          name: mypvc
      volumes:
      - name: mypvc
        persistentVolumeClaim:
          claimName: podpvc
          readOnly: false

Discos persistentes regionales

Al igual que los discos persistentes zonales, los discos persistentes regionales se pueden aprovisionar dinámicamente según sea necesario o aprovisionar manualmente con antelación por el administrador del clúster, aunque se recomienda el aprovisionamiento dinámico. Para utilizar discos persistentes regionales de tipo pd-standard, asigna al atributo spec.resources.requests.storage de PersistentVolumeClaim un valor mínimo de 200 GiB. Si tu caso práctico requiere un volumen menor, considera usar pd-balanced o pd-ssd.

Aprovisionamiento dinámico

Para habilitar el aprovisionamiento dinámico de discos persistentes regionales, crea un StorageClass con el parámetro replication-type y especifica las restricciones de zona en allowedTopologies.

Por ejemplo, el siguiente manifiesto describe un StorageClass llamado regionalpd-storageclass que usa discos persistentes estándar y que replica datos en las zonas europe-west1-b y europe-west1-c:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: regionalpd-storageclass
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  # Specifies that the disk should be a regional persistent disk.
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
# Constrains which zones the regional persistent disk can be provisioned in.
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - europe-west1-b
    - europe-west1-c

Si usas un clúster regional, puedes dejar allowedTopologies sin especificar. Si lo haces, cuando crees un pod que consuma un PersistentVolumeClaim que use este StorageClass, se aprovisionará un disco persistente regional con dos zonas. Una zona es la misma en la que está programado el Pod. La otra zona se elige aleatoriamente entre las zonas disponibles para el clúster.

Cuando se usa un clúster zonal, se debe definir allowedTopologies.

Una vez que se haya creado el StorageClass, crea un objeto PersistentVolumeClaim con el campo storageClassName para hacer referencia al StorageClass. Por ejemplo, el siguiente archivo de manifiesto crea un PersistentVolumeClaim llamado regional-pvc y hace referencia al regionalpd-storageclass:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: regional-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Gi
  storageClassName: regionalpd-storageclass

Como StorageClass se ha configurado con volumeBindingMode: WaitForFirstConsumer, PersistentVolume no se aprovisiona hasta que se crea un pod que usa PersistentVolumeClaim.

El siguiente manifiesto es un ejemplo de Pod que usa el PersistentVolumeClaim creado anteriormente:

kind: Pod
apiVersion: v1
metadata:
  name: task-pv-pod
spec:
  volumes:
    - name: task-pv-storage
      # This Pod uses the PVC that's associated with the
      # "regionalpd-storageclass" StorageClass.
      persistentVolumeClaim:
        claimName: regional-pvc
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      # The volume is mounted into the container at the "/usr/share/nginx/html" path.
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

Aprovisionamiento manual

Primero, crea un disco persistente regional con el comando gcloud compute disks create. En el siguiente ejemplo se crea un disco llamado gce-disk-1 replicado en las zonas europe-west1-b y europe-west1-c:

gcloud compute disks create gce-disk-1 \
   --size 500Gi \
   --region europe-west1 \
   --replica-zones europe-west1-b,europe-west1-c

A continuación, puedes crear un PersistentVolume que haga referencia al disco persistente regional que acabas de crear. Además de los objetos de Usar discos persistentes preexistentes como volúmenes persistentes, el PersistentVolume de un disco persistente regional también debe especificar un node-affinity. Si usas un StorageClass, debe especificar el controlador de CSI para Persistent Disk.

A continuación se muestra un ejemplo de un manifiesto de StorageClass que usa discos persistentes estándar y que replica datos en las zonas europe-west1-b y europe-west1-c:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: regionalpd-storageclass
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  # Specifies that the disk should be a regional persistent disk.
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
# Constrains which zones the regional persistent disk can be provisioned in.
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - europe-west1-b
    - europe-west1-c

Aquí tienes un ejemplo de archivo de manifiesto que crea un PersistentVolume llamado pv-demo y hace referencia al regionalpd-storageclass:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-demo
spec:
  # The StorageClass that specifies regional replication.
  storageClassName: "regionalpd-storageclass"
  capacity:
     storage: 500Gi
  accessModes:
     - ReadWriteOnce
  claimRef:
    namespace: default
    name: pv-claim-demo
  csi:
    driver: pd.csi.storage.gke.io
    # The unique identifier for the pre-existing regional disk.
    volumeHandle: projects/PROJECT_ID/regions/europe-west1/disks/gce-disk-1
  # Ensures that Pods are scheduled in zones where the disk is replicated.
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
          - key: topology.gke.io/zone
            operator: In
            values:
               - europe-west1-b
               - europe-west1-c

Ten en cuenta lo siguiente en el ejemplo de PersistentVolume:

  • El campo volumeHandle contiene detalles de la gcloud compute disks create llamada, incluido tu PROJECT_ID.
  • El campo claimRef.namespace debe especificarse aunque se le asigne el valor default.

Asignar nombres a discos persistentes

Kubernetes no puede distinguir entre discos persistentes zonales y regionales con el mismo nombre. Como solución alternativa, asegúrate de que los discos persistentes tengan nombres únicos. Este problema no se produce cuando se usan discos persistentes aprovisionados dinámicamente.

Siguientes pasos