Provisionner des disques persistants régionaux

Cette page explique comment activer le provisionnement dynamique des disques persistants régionaux et comment les provisionner manuellement dans Google Kubernetes Engine (GKE).

Pour créer des solutions de bout en bout pour les applications hautement disponibles dotées de disques persistants régionaux, consultez Augmenter la disponibilité des applications avec état avec l'opérateur HA avec état.

Disques persistants régionaux

Comme pour les disques persistants zonaux, les disques persistants régionaux peuvent être provisionnés de manière dynamique, au besoin, ou manuellement par l'administrateur du cluster. Le provisionnement dynamique est toutefois recommandé.

Provisionnement dynamique

Pour activer le provisionnement dynamique des disques persistants régionaux, créez une StorageClass avec le paramètre replication-type et spécifiez des contraintes de zone dans allowedTopologies.

Par exemple, le fichier manifeste suivant décrit une StorageClass nommée regionalpd-storageclass qui utilise des disques persistants standards et qui réplique les données sur les zones europe-west1-b et 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

Si vous utilisez un cluster régional, vous pouvez laisser allowedTopologies non spécifié. Le cas échéant, lorsque vous créez un pod qui utilise un PersistentVolumeClaim qui utilise cette StorageClass, un disque persistant régional est provisionné avec deux zones. Une zone est identique à celle dans laquelle le pod est programmé. L'autre zone est choisie de manière aléatoire parmi les zones disponibles pour le cluster.

Lorsque vous utilisez un cluster zonal, allowedTopologies doit être défini.

Une fois l'objet StorageClass créé, créez un objet PersistentVolumeClaim en utilisant le champ storageClassName pour faire référence à StorageClass. Par exemple, le fichier manifeste suivant crée un objet PersistentVolumeClaim nommé regional-pvc et fait référence à regionalpd-storageclass :

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

Comme la StorageClass est configurée avec volumeBindingMode: WaitForFirstConsumer, le PersistentVolume n'est provisionné qu'une fois qu'un pod utilisant l'objet PersistentVolumeClaim a été créé.

Le fichier manifeste suivant est un exemple de pod utilisant l'objet PersistentVolumeClaim précédemment créé :

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

Provisionnement manuel

Commencez par créer un disque persistant régional à l'aide de la commande gcloud compute disks create. L'exemple suivant crée un disque nommé gce-disk-1, répliqué sur les zones europe-west1-b et europe-west1-c :

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

Vous pouvez ensuite créer un objet PersistentVolume qui fait référence au disque persistant régional que vous venez de créer. Outre les objets de Utiliser des disques persistants préexistants en tant que ressources PersistentVolume, le PersistentVolume pour un disque persistant régional doit également spécifier unnode-affinity. Si vous utilisez un StorageClass, il doit spécifier le pilote CSI de disque persistant.

Voici un exemple de fichier manifeste StorageClass qui utilise des disques persistants standards et qui réplique les données sur les zones europe-west1-b et 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

Voici un exemple de fichier manifeste qui crée un objet PersistentVolume nommé pv-demo et fait référence à 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

Notez les points suivants pour l'exemple PersistentVolume:

  • Le champ volumeHandle contient des informations sur l'appel gcloud compute disks create, y compris votre PROJECT_ID.
  • Le champ claimRef.namespace doit être spécifié même s'il est défini sur default.

Nommer les disques persistants

Kubernetes n'arrive pas à différencier les disques persistants zonaux et régionaux qui portent le même nom. Pour contourner ce problème, assurez-vous que les disques persistants sont dotés de noms uniques. Ce problème n'apparaît pas lorsque vous utilisez des disques persistants provisionnés dynamiquement.

Étape suivante