Provisioning dei dischi permanenti a livello di regione

Questa pagina spiega come abilitare il provisioning dinamico dei dischi permanenti a livello di regione e come eseguire il provisioning manuale in Google Kubernetes Engine (GKE).

Per creare soluzioni end-to-end per applicazioni ad alta disponibilità con dischi permanenti a livello di regione, consulta Aumentare la disponibilità delle app stateful con l'operatore HA stateful.

Dischi permanenti a livello di regione

Come nel caso dei dischi permanenti a livello di zona, il provisioning dinamico dei dischi permanenti a livello di regione può essere eseguito in base alle esigenze o viene eseguito manualmente in anticipo dall'amministratore del cluster, sebbene sia consigliato il provisioning dinamico.

Provisioning dinamico

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

Ad esempio, il seguente manifest descrive un oggetto 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
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - europe-west1-b
    - europe-west1-c

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

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

Dopo aver 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, il provisioning di PersistentVolume non viene eseguito finché non viene creato un pod che utilizza PersistentVolumeClaim.

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

kind: Pod
apiVersion: v1
metadata:
  name: task-pv-pod
spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: regional-pvc
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

Provisioning manuale

Per prima cosa, 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 faccia riferimento al disco permanente a livello di regione che hai appena creato. Oltre agli oggetti in Utilizzo di dischi permanenti preesistenti come PersistentVolume, il PersistentVolume per un disco permanente a livello di regione deve specificare anche un node-affinity. Se usi StorageClass, è necessario specificare il driver CSI del 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
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - europe-west1-b
    - europe-west1-c

Di seguito è riportato un manifest di esempio che crea un PersistentVolume denominato pv-demo e fa riferimento a regionalpd-storageclass:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-demo
spec:
  storageClassName: "regionalpd-storageclass"
  capacity:
     storage: 500Gi
  accessModes:
     - ReadWriteOnce
  claimRef:
    namespace: default
    name: pv-claim-demo
  csi:
    driver: pd.csi.storage.gke.io
    volumeHandle: projects/PROJECT_ID/regions/europe-west1/disks/gce-disk-1
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
          - key: topology.gke.io/zone
            operator: In
            values:
               - europe-west1-b
               - europe-west1-c

Per l'esempio PersistentVolume, tieni presente quanto segue:

  • Il campo volumeHandle contiene i dettagli della chiamata gcloud compute disks create, tra cui la tua PROJECT_ID.
  • Il campo claimRef.namespace deve essere specificato anche quando è impostato su default.

Denominazione dei dischi permanenti

Kubernetes non è in grado di distinguere tra dischi permanenti a livello di zona e di regione 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 di cui è stato eseguito il provisioning dinamico.

Passaggi successivi