Aprovisionamiento de discos persistentes regionales y volúmenes de alta disponibilidad balanceada de Hyperdisk

Autopilot estándar

En esta página, se explica cómo habilitar el aprovisionamiento dinámico de volúmenes de Hyperdisk equilibrado con alta disponibilidad y discos persistentes regionales, y cómo aprovisionarlos de forma manual en Google Kubernetes Engine (GKE). Para conocer las compatibilidades de los tipo de máquina, consulta Limitaciones de los discos regionales y Compatibilidad de series de máquinas con Hyperdisk. Por lo general, debes usar volúmenes de alta disponibilidad balanceada de Hyperdisk para series de máquinas de 3ª generación o más recientes, y discos persistentes regionales en series de máquinas de 2ª generación o más antiguas. Para obtener más información sobre la generación de series de máquinas, consulta Terminología de Compute Engine.

Para crear soluciones de extremo a extremo para aplicaciones de alta disponibilidad con discos persistentes regionales, consulta Aumenta la disponibilidad de las apps con estado con el operador de HA con estado. Esta función no admite volúmenes de Hyperdisk Balanced High Availability.

Nota: Los discos de multiescritura solo se pueden usar en el modo de volumen de bloques. La aplicación es responsable de administrar su propio sistema de archivos o algún otro mecanismo de sincronización sobre el dispositivo de almacenamiento en bloques. Para obtener más información, consulta Sistemas de archivos compatibles para el modo de multiescritura.

Alta disponibilidad balanceada de Hyperdisk

En este ejemplo, se muestra cómo el administrador del clúster puede aprovisionar de forma dinámica los volúmenes de Hyperdisk Balanced High Availability según sea necesario o aprovisionarlos de forma manual por adelantado.

Nota: El aprovisionamiento de volúmenes de alta disponibilidad de Hyperdisk Balanced solo es compatible con el controlador de CSI de disco persistente de Compute Engine a partir de la versión 1.33 de GKE.

Aprovisionamiento dinámico

1. Guarda el siguiente manifiesto como 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
   

   Reemplaza lo siguiente:

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

2. Crea la 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
   

   Reemplaza lo siguiente:

   • ACCESS_MODE: Hyperdisk Balanced High Availability admite ReadWriteOnce, ReadWriteMany y ReadWriteOncePod. Para conocer las diferencias y los casos de uso de cada modo de acceso, consulta Modos de acceso de volúmenes persistentes.
   • Si decides usar ReadWriteMany, también debes agregar volumeMode: Block a PersistentVolumeClaim. Este parámetro de configuración evita el daño de datos que puede ocurrir cuando varios Pods escriben en el almacenamiento de forma simultánea. El parámetro de configuración volumeMode: Block expone el disco como un dispositivo de almacenamiento en bloques sin procesar que omite la administració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 la PersistentVolumeClaim que hace referencia a la StorageClass que creaste anteriormente:

   kubectl apply -f pvc-example.yaml
   

Aprovisionamiento manual

1. Sigue la documentación de Compute Engine para crear un volumen de alta disponibilidad balanceada de Hyperdisk de forma manual.

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
   

   Reemplaza lo siguiente:

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

3. Crea el volumen persistente que hace referencia al volumen de alta disponibilidad balanceada de Hyperdisk que creaste antes:

   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
   

   Reemplaza lo siguiente:

   • ACCESS_MODE: Hyperdisk Balanced High Availability admite ReadWriteOnce, ReadWriteMany y ReadWriteOncePod. Debe ser el mismo modo de acceso que se especifica en el PersistentVolume del paso anterior. Para conocer las diferencias y los casos de uso de cada modo de acceso, consulta Modos de acceso de volúmenes persistentes.

5. Aplica la PersistentVolumeClaim que hace referencia al PersistentVolume que creaste antes:

   kubectl apply -f pvc-example.yaml
   

Cómo consumir un volumen de multiescritura en modo de bloque

Para usar un volumen en modo de bloque, debes especificar volumeBlock en lugar de volumeMounts en el Pod de consumo. Un Pod de ejemplo que usa el PersistenVolumeClaim presentado anteriormente debería verse de la siguiente manera:

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 con los discos persistentes zonales, el administrador del clúster puede aprovisionar de forma dinámica o manual por adelantado los discos persistentes regionales según sea necesario, aunque la primera opción es la recomendada. Para usar discos persistentes regionales del tipo pd-standard, establece el atributo spec.resources.requests.storage de PersistentVolumeClaim en un mínimo de 200 GiB. Si tu caso de uso requiere un volumen más pequeño, considera usar pd-balanced o pd-ssd en su lugar.

Aprovisionamiento dinámico

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

Por ejemplo, en el siguiente manifiesto, se describe una StorageClass llamada regionalpd-storageclass en la que se usan discos persistentes estándares y se replican 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 consume una PersistentVolumeClaim que usa este StorageClass, se aprovisiona un disco persistente regional con dos zonas. Una zona es la misma en la que está programado el Pod. La otra zona se elige al azar entre las zonas disponibles para el clúster.

Nota: Puedes omitir allowedTopologies en tu StorageClass solo si tus grupos de nodos tienen nodos activos en al menos dos zonas diferentes. Esto permite que GKE seleccione automáticamente las zonas principal y secundaria correctas para tus discos persistentes regionales.

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

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

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

Dado que StorageClass se configura con volumeBindingMode: WaitForFirstConsumer, el PersistentVolume no se aprovisiona hasta que se crea un pod mediante PersistentVolumeClaim.

El siguiente manifiesto es un pod de ejemplo en el que se usa el PersistentVolumeClaim creado con anterioridad:

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

Luego, puedes crear un PersistentVolume que haga referencia al disco persistente regional que acabas de crear. Además de los objetos que figuran en Usa discos persistentes preexistentes como PersistentVolumes, el PersistentVolume para un disco persistente regional también debe especificar una node-affinity. Si usas un StorageClass, debe especificar el controlador CSI del disco persistente.

A continuación, se muestra un ejemplo de un manifiesto StorageClass que usa discos persistentes estándares y 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

A continuación, se muestra un manifiesto de ejemplo que crea un PersistentVolume con el nombre pv-demo y hace referencia a 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 para el ejemplo de PersistentVolume:

• El campo volumeHandle contiene detalles de la llamada gcloud compute disks create, incluido tu PROJECT_ID.
• El campo claimRef.namespace debe especificarse incluso cuando se configura en default.

Asigna nombres a los discos persistentes

Kubernetes no puede distinguir entre discos persistentes regionales y zonales que tengan el mismo nombre. Para evitar este problema, asegúrate de que los discos persistentes tengan nombres únicos. Esto no es necesario cuando se usan los discos persistentes aprovisionados de forma dinámica.

¿Qué sigue?

• Sigue un instructivo para aprender a implementar WordPress en GKE con discos persistentes y Cloud SQL.