Provisioning dei dischi permanenti a livello di regione e dei volumi Hyperdisk bilanciato ad alta affidabilità

Autopilot Standard

Questa pagina spiega come abilitare il provisioning dinamico dei volumi Hyperdisk bilanciati ad alta affidabilità e dei dischi permanenti regionali e come eseguirne il provisioning manuale in Google Kubernetes Engine (GKE). Per le compatibilità dei tipo di macchina, consulta Limitazioni per il disco regionale e Supporto delle serie di macchine per Hyperdisk. In genere, devi utilizzare i volumi Hyperdisk bilanciato ad alta affidabilità per le serie di macchine di terza generazione o successive e i dischi permanenti a livello di regione nelle serie di macchine di seconda generazione o precedenti. Per ulteriori informazioni sulla generazione delle serie di macchine, consulta la terminologia di Compute Engine.

Per creare soluzioni end-to-end per applicazioni ad alta disponibilità con dischi permanenti regionali, consulta Aumentare la disponibilità delle app stateful con l'operatore HA stateful. Questa funzionalità non supporta i volumi Hyperdisk bilanciati ad alta affidabilità.

Nota: i dischi multi-writer possono essere utilizzati solo in modalità Block Volume. L'applicazione è responsabile della gestione del proprio file system o di un altro meccanismo di sincronizzazione sopra il dispositivo a blocchi. Per ulteriori informazioni, vedi Filesystem supportati per la modalità multi-writer.

Hyperdisk bilanciato con disponibilità elevata

Questo esempio mostra come i volumi Hyperdisk bilanciato ad alta affidabilità possono essere sottoposti a provisioning dinamico in base alle necessità o a provisioning manuale in anticipo da parte dell'amministratore del cluster.

Nota :il provisioning dei volumi Hyperdisk bilanciato ad alta affidabilità è supportato solo dal driver CSI per il disco permanente di Compute Engine a partire dalla versione 1.33 di GKE.

Provisioning dinamico

1. Salva il seguente manifest in un file denominato 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
   

   Sostituisci quanto segue:

   • ZONE1, ZONE2: le zone all'interno della regione in cui verrà replicato il volume di cui è stato eseguito il provisioning dinamico.

2. Crea StorageClass:

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

3. Salva il seguente manifest PersistentVolumeClaim in un file denominato pvc-example.yaml:

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

   Sostituisci quanto segue:

   • ACCESS_MODE: Hyperdisk bilanciato ad alta affidabilità supporta ReadWriteOnce, ReadWriteMany e ReadWriteOncePod. Per le differenze e i casi d'uso di ogni modalità di accesso, consulta Modalità di accesso ai volumi persistenti.
   • Se scegli di utilizzare ReadWriteMany, devi anche aggiungere volumeMode: Block a PersistentVolumeClaim. Questa impostazione impedisce il danneggiamento dei dati che può verificarsi quando più pod scrivono contemporaneamente nello spazio di archiviazione. L'impostazione volumeMode: Block espone il disco come dispositivo a blocchi non elaborati che bypassa la gestione del file system da parte di Kubernetes. Di seguito è riportato un esempio:

     kind: PersistentVolumeClaim
     apiVersion: v1
     metadata:
       name: podpvc
     spec:
       accessModes:
       - ReadWriteMany
       volumeMode: Block
       storageClassName: balanced-ha-storage
       resources:
         requests:
           storage: 20Gi
     ```
   

4. Applica l'oggetto PersistentVolumeClaim che fa riferimento alla classe di archiviazione che hai creato in precedenza:

   kubectl apply -f pvc-example.yaml
   

Provisioning manuale

1. Segui la documentazione di Compute Engine per creare manualmente un volume Hyperdisk bilanciato ad alta affidabilità.

2. Salva il seguente manifest PersistentVolume in un file denominato pv-example.yaml. Il manifest fa riferimento al volume Hyperdisk bilanciato ad alta affidabilità che hai appena creato:

   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
   

   Sostituisci quanto segue:

   • PROJECT_ID: l'ID progetto del volume che hai creato.
   • REGION: la regione del disco che hai creato. Per informazioni aggiornate sulla disponibilità regionale, consulta la documentazione di Compute Engine.
   • ZONE1, ZONE2: le zone all'interno della regione in cui viene replicato il volume che hai creato.
   • ACCESS_MODE: Hyperdisk bilanciato ad alta affidabilità supporta ReadWriteOnce, ReadWriteMany e ReadWriteOncePod. Per le differenze e i casi d'uso di ogni modalità di accesso, consulta Modalità di accesso ai volumi persistenti.

3. Crea il Persistent Volume che fa riferimento al volume Hyperdisk bilanciato ad alta affidabilità che hai creato in precedenza:

   kubectl apply -f pv-example.yaml
   

4. Salva il seguente manifest PersistentVolumeClaim in un file denominato pvc-example.yaml:

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

   Sostituisci quanto segue:

   • ACCESS_MODE: Hyperdisk bilanciato ad alta affidabilità supporta ReadWriteOnce, ReadWriteMany e ReadWriteOncePod. Deve essere la stessa modalità di accesso specificata in PersistentVolume del passaggio precedente. Per le differenze e i casi d'uso di ogni modalità di accesso, consulta Modalità di accesso ai volumi persistenti.

5. Applica PersistentVolumeClaim che fa riferimento al PersistentVolume che hai creato in precedenza:

   kubectl apply -f pvc-example.yaml
   

Utilizzo di un volume multi-writer in modalità a blocchi

Per utilizzare un volume in modalità blocco, devi specificare volumeBlock anziché volumeMounts nel pod di consumo. Un pod di esempio che utilizza PersistenVolumeClaim introdotto in precedenza dovrebbe avere il seguente aspetto:

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

Dischi permanenti a livello di regione

Come per i dischi permanenti a livello di zona, i dischi permanenti a livello di regione possono essere sottoposti a provisioning dinamico in base alle necessità o a provisioning manuale in anticipo da parte dell'amministratore del cluster, anche se è consigliato il provisioning dinamico. Per utilizzare i dischi permanenti a livello di regione di tipo pd-standard, imposta l'attributo spec.resources.requests.storage di PersistentVolumeClaim su un minimo di 200 GiB. Se il tuo caso d'uso richiede un volume inferiore, valuta la possibilità di utilizzare pd-balanced o pd-ssd.

Provisioning dinamico

Per abilitare il provisioning dinamico dei dischi permanenti a livello di regione, crea un StorageClass con il parametro replication-type e specifica i vincoli di zona in allowedTopologies.

Ad esempio, il seguente manifest descrive un StorageClass denominato regionalpd-storageclass che utilizza dischi permanenti standard e che replica i dati nelle zone europe-west1-b e 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

Se utilizzi un cluster regionale, puoi lasciare allowedTopologies non specificato. Se lo fai, quando crei un pod che utilizza un PersistentVolumeClaim che utilizza questo StorageClass, viene eseguito il provisioning di un disco permanente a livello di regione con due zone. Una zona è la stessa in cui è pianificato il pod. L'altra zona viene scelta in modo casuale tra le zone disponibili per il cluster.

Nota: puoi omettere allowedTopologies in StorageClass solo se i pool di nodi hanno nodi attivi in almeno due zone diverse. In questo modo, GKE può selezionare automaticamente le zone primaria e secondaria corrette per i dischi permanenti a livello di regione.

Quando utilizzi un cluster di zona, è necessario impostare allowedTopologies.

Una volta creato StorageClass, crea un oggetto PersistentVolumeClaim utilizzando il campo storageClassName per fare riferimento a StorageClass. Ad esempio, il seguente manifest crea un PersistentVolumeClaim denominato regional-pvc e fa riferimento a regionalpd-storageclass:

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

Poiché StorageClass è configurato con volumeBindingMode: WaitForFirstConsumer, PersistentVolume non viene provisionato finché non viene creato un pod che utilizza PersistentVolumeClaim.

Il seguente manifest è un pod di esempio che utilizza il PersistentVolumeClaim creato in precedenza:

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

Provisioning manuale

Innanzitutto, crea un disco permanente a livello di regione utilizzando il comando gcloud compute disks create. L'esempio seguente crea un disco denominato gce-disk-1 replicato nelle zone europe-west1-b e europe-west1-c:

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

Puoi quindi creare un PersistentVolume che fa riferimento al disco permanente a livello di regione che hai appena creato. Oltre agli oggetti in Utilizzo di dischi permanenti preesistenti come PersistentVolume, PersistentVolume per un disco permanente a livello di regione deve specificare anche un node-affinity. Se utilizzi un StorageClass, deve specificare il driver CSI per il disco permanente.

Ecco un esempio di manifest StorageClass che utilizza dischi permanenti standard e che replica i dati nelle zone europe-west1-b e 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

Ecco un esempio di manifest che crea un PersistentVolume denominato pv-demo e fa riferimento 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

Nota quanto segue per l'esempio PersistentVolume:

• Il campo volumeHandle contiene i dettagli della chiamata gcloud compute disks create, incluso il tuo PROJECT_ID.
• Il campo claimRef.namespace deve essere specificato anche quando è impostato su default.

Denominazione dei dischi permanenti

Kubernetes non può distinguere tra Persistent Disk zonali e regionali con lo stesso nome. Come soluzione alternativa, assicurati che i dischi permanenti abbiano nomi univoci. Questo problema non si verifica quando si utilizzano dischi permanenti con provisioning dinamico.

Passaggi successivi

• Segui un tutorial per scoprire di più sul deployment di WordPress su GKE con Persistent Disk e Cloud SQL.