Provisioning dei dischi permanenti a livello di regione

In questa pagina viene spiegato come abilitare il provisioning dinamico di servizi permanenti a livello di regione dischi e come eseguirne manualmente il provisioning in Google Kubernetes Engine (GKE).

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

Dischi permanenti a livello di regione

Come per i dischi permanenti a livello di zona, i dischi permanenti a livello di regione possono essere in base alle esigenze o manualmente in anticipo dal cluster ma è consigliato il provisioning dinamico. Per utilizzare i dischi permanenti a livello di area geografica di tipo pd-standard, imposta invece "spec.resources.requests.storageattribute to a minimum of200 GiB. If your use case requires a smaller volume, consider usingpd-balancedorpd-ssd" di PersistentVolumeClaim.

Provisioning dinamico

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

Ad esempio, il seguente manifest descrive un StorageClass denominato regionalpd-storageclass che utilizza dischi permanenti standard e che esegue la replica dei 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. 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 tra due zone. Una zona è uguale alla zona in cui è pianificato il pod. La un'altra zona viene scelta in modo casuale tra quelle disponibili per il cluster.

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

Una volta creato StorageClass, crea un oggetto PersistentVolumeClaim utilizzando il campo storageClassName per fare riferimento a StorageClass. Per Ad esempio, il seguente manifest crea un PersistentVolumeClaim denominato regional-pvc e fa riferimento ai 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 lo stato creato in precedenza PersistentVolumeClaim:

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

Innanzitutto, crea un disco permanente regionale utilizzando il comando gcloud compute disks create. L'esempio seguente crea un disco denominato gce-disk-1 replicata 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

Potrai quindi creare un PersistentVolume che faccia riferimento alla regione un disco permanente appena creato. Oltre agli oggetti descritti in Utilizzo di dischi permanenti preesistenti come PersistentVolume, il PersistentVolume per un disco permanente regionale deve specificare anche un node-affinity. Se utilizzi un'istruzione StorageClass, dovrebbe essere specificato il driver CSI del disco permanente.

Ecco un esempio di manifest StorageClass che utilizza dischi permanenti standard e che esegue la replica dei 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

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:
  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

Tieni presente 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 se è impostato su default.

Assegnare un nome ai 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 utilizzi i dischi permanenti.

Passaggi successivi