Utiliser le pilote CSI de disque persistant Compute Engine

Autopilot Standard

Google Kubernetes Engine (GKE) offre un moyen facile de déployer et gérer automatiquement le pilote CSI (Container Storage Interface) de disque persistant Compute Engine dans vos clusters. Le pilote CSI de disque persistant Compute Engine est toujours activé dans les clusters Autopilot et ne peut pas être désactivé ou modifié. Dans les clusters standards, vous devez activer le pilote CSI de disque persistant Compute Engine.

La version du pilote CSI de disque persistant Compute Engine est liée aux numéros de version de GKE. La version du pilote CSI de disque persistant Compute Engine est généralement le dernier pilote disponible au moment de la publication de la version de GKE. Les pilotes sont mis à jour automatiquement lorsque le cluster est mis à niveau afin d'intégrer le dernier correctif GKE.

Remarque : Étant donné que le pilote CSI de disque persistant Compute Engine et certains des autres composants CSI associés sont déployés en tant que conteneurs distincts, ils utilisent des ressources (processeur des VM, mémoire et disque de démarrage) sur les nœuds Kubernetes. L'utilisation du processeur des VM est généralement de plusieurs dizaines de millicores, et celle de la mémoire est généralement de l'ordre de plusieurs dizaines de Mo. L'utilisation du disque de démarrage est principalement entraînée par les journaux du pilote CSI et d'autres conteneurs système dans le déploiement.

Avantages

L'utilisation du pilote CSI de disque persistant Compute Engine offre les avantages suivants :

• Cela permet de déployer et de gérer automatiquement le pilote de disque persistant sans avoir à le configurer manuellement.
• Vous pouvez utiliser des clés de chiffrement gérées par le client (CMEK). Ces clés permettent de chiffrer les clés de chiffrement de données qui chiffrent vos données. Pour en savoir plus sur les clés CMEK sur GKE, consultez la page Utiliser des clés de chiffrement gérées par le client (CMEK).
• Vous pouvez utiliser des instantanés de volume avec le pilote CSI de disque persistant Compute Engine. Les instantanés de volume permettent de créer une copie d'un volume à un moment précis. Cette copie peut servir à revenir à un état antérieur ou à provisionner un nouveau volume.
• Vous pouvez utiliser le clonage de volume avec le pilote CSI de disque persistant Compute Engine dans les clusters exécutant GKE version 1.22 ou ultérieure. Vous pouvez ainsi créer un double de votre volume à un moment précis, provisionné avec toutes les données du volume source.
• Les corrections de bugs et les mises à jour des fonctionnalités sont déployées indépendamment des versions mineures de Kubernetes. Ce calendrier de publication se traduit généralement par une cadence de publication de versions plus rapide.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

• Activez l'API Google Kubernetes Engine.
Activer l'API Google Kubernetes Engine
• Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
  Remarque : Pour les installations de la gcloud CLI existantes, veillez à définir la propriété compute/region. Si vous utilisez principalement des clusters zonaux, définissez plutôt compute/zone. En définissant un emplacement par défaut, vous pouvez éviter les erreurs gcloud CLI de ce type : One of [--zone, --region] must be supplied: Please specify location. Vous devrez peut-être spécifier l'emplacement dans certaines commandes si celui de votre cluster diffère de l'emplacement par défaut que vous avez défini.

Activer le pilote CSI de disque persistant Compute Engine

Pour activer le pilote CSI de disque persistant Compute Engine dans des clusters standards existants, utilisez Google Cloud CLI ou la console Google Cloud .

Pour activer le pilote sur un cluster existant, procédez comme suit :

gcloud

gcloud container clusters update CLUSTER-NAME \
   --update-addons=GcePersistentDiskCsiDriver=ENABLED

Remplacez CLUSTER-NAME par le nom du cluster existant.

Console

1. Accédez à la page Google Kubernetes Engine dans la console Google Cloud .

   Accéder à Google Kubernetes Engine

2. Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.

3. Sous Fonctionnalités, à côté du champ Pilote CSI de disque persistant Compute Engine, cliquez sur Modifier le pilote CSI Compute Engine.

4. Cochez la case Activer le pilote CSI de disque persistant Compute Engine.

5. Cliquez sur Enregistrer les modifications.

Après avoir activé le pilote CSI de disque persistant Compute Engine, vous pouvez l'utiliser dans les volumes Kubernetes en indiquant le nom du pilote et de l'approvisionneur : pd.csi.storage.gke.io.

Désactiver le pilote CSI de disque persistant Compute Engine

Vous pouvez désactiver le pilote CSI de disque persistant Compute Engine pour les clusters standards à l'aide de Google Cloud CLI ou de la console Google Cloud .

Si vous désactivez le pilote, tous les pods qui utilisent actuellement les PersistentVolume appartenant au pilote ne s'arrêteront pas. En outre, les nouveaux pods tentant d'utiliser ces PersistentVolume ne pourront pas démarrer.

Remarque : Étant donné que le type de volume gcePersistentDisk est migré vers le pilote CSI de disque persistant Compute Engine dans les versions 1.22 et ultérieures, si vous désactivez le pilote CSI de disque persistant, le type de volume gcePersistentDisk cesse également de fonctionner.

Avertissement : Dans GKE 1.21 et versions antérieures, un problème peut survenir si vous utilisez le pilote de disque persistant "in-tree" et que vous souhaitez supprimer des disques régionaux. Un disque régional Compute Engine peut faire l'objet de fuites lorsque sa ressource PersistentVolume associée est supprimée. Ce problème peut être détecté lorsque votre appel d'API pour supprimer le disque régional échoue et renvoie un code d'erreur autre que NotFound. Pour en savoir plus, consultez cette demande sur GitHub.

Pour désactiver le pilote sur un cluster standard existant, procédez comme suit :

gcloud

gcloud container clusters update CLUSTER-NAME \
    --update-addons=GcePersistentDiskCsiDriver=DISABLED

Remplacez CLUSTER-NAME par le nom du cluster existant.

Console

1. Accédez à la page Google Kubernetes Engine dans la console Google Cloud .

   Accéder à Google Kubernetes Engine

2. Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.

3. Sous Fonctionnalités, à côté du champ Pilote CSI de disque persistant Compute Engine, cliquez sur Modifier le pilote CSI Compute Engine.

4. Cochez la case Activer le pilote CSI de disque persistant Compute Engine.

5. Cliquez sur Enregistrer les modifications.

Utiliser le pilote CSI de disque persistant Compute Engine pour les clusters Linux

Les sections suivantes décrivent la procédure d'utilisation standard d'un volume Kubernetes reposant sur un pilote CSI dans GKE. Ces sections sont spécifiques aux clusters Linux

Créer un objet StorageClass

Une fois le pilote CSI de disque persistant Compute Engine activé, GKE installe automatiquement les ressources StorageClasses suivantes :

• standard-rwo, avec un disque persistant avec équilibrage
• premium-rwo, avec un disque persistant SSD

Pour les clusters Autopilot, la ressource StorageClass par défaut est standard-rwo, qui utilise le pilote CSI de disque persistant Compute Engine. Pour les clusters standards, la ressource StorageClass par défaut utilise le plug-in de volume gcePersistentDisk "in-tree" Kubernetes.

Exécutez la commande suivante pour trouver le nom de vos ressources StorageClasses installées :

kubectl get sc

Vous pouvez également installer une autre StorageClass qui utilise le pilote CSI de disque persistant Compute Engine en ajoutant pd.csi.storage.gke.io dans le champ de l'approvisionneur.

Par exemple, vous pouvez créer un objet StorageClass à l'aide du fichier suivant nommé pd-example-class.yaml.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-example
provisioner: pd.csi.storage.gke.io
# Recommended setting. Delays the binding and provisioning of a PersistentVolume until a Pod that uses the
# PersistentVolumeClaim is created and scheduled on a node.
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-balanced

Vous pouvez spécifier les types de disques persistants suivants dans le paramètre type :

• pd-balanced
• pd-ssd
• pd-standard
• pd-extreme (compatible avec les versions 1.26 et ultérieures de GKE)

Si vous utilisez pd-standard ou pd-extreme, consultez la section Types de machines non compatibles pour connaître les restrictions d'utilisation supplémentaires.

Lorsque vous utilisez l'option pd-extreme, vous devez également ajouter le champ provisioned-iops-on-create à votre fichier manifeste. Ce champ doit être défini sur la même valeur que celle des IOPS provisionnés que vous avez spécifiée lors de la création de votre disque persistant.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-extreme-example
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-extreme
  provisioned-iops-on-create:'10000'

Après avoir créé le fichier pd-example-class.yaml, exécutez la commande suivante :

kubectl create -f pd-example-class.yaml

Créer un objet PersistentVolumeClaim

Vous pouvez créer un PersistentVolumeClaim qui fait référence à la StorageClass du pilote CSI de disque persistant Compute Engine.

Le fichier suivant, nommé pvc-example.yaml, utilise l'objet "classe de stockage" pré-installé standard-rwo :

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: standard-rwo
  resources:
    requests:
      storage: 6Gi

Après avoir créé le fichier manifeste PersistentVolumeClaim, exécutez la commande suivante :

kubectl create -f pvc-example.yaml

Dans l'objet StorageClass pré-installé (standard-rwo), volumeBindingMode est défini sur WaitForFirstConsumer. Lorsque volumeBindingMode est défini sur WaitForFirstConsumer, l'objet PersistentVolume n'est pas provisionné tant qu'aucun pod référençant l'objet PersistentVolumeClaim n'est planifié. Si volumeBindingMode est défini sur Immediate dans l'objet StorageClass (ou s'il est omis), un objet PersistentVolume s'appuyant sur un disque persistant est provisionné après la création d'un objet PersistentVolumeClaim.

Créer un pod qui consomme le volume

Lorsque vous utilisez des pods avec des objets PersistentVolume, nous vous recommandons d'utiliser un contrôleur de charge de travail (tel que Deployment ou StatefulSet). Bien que les pods autonomes soient peu répandus, l'exemple suivant en utilise un pour plus de simplicité.

L'exemple suivant utilise le volume que vous avez créé dans la section précédente :

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  containers:
   - name: web-server
     image: nginx
     volumeMounts:
       # The path in the container where the volume will be mounted.
       - mountPath: /var/lib/www/html
         # The name of the volume that is being defined in the "volumes" section.
         name: mypvc
  volumes:
   - name: mypvc
     persistentVolumeClaim:
       # References the PersistentVolumeClaim created earlier.
       claimName: podpvc
       readOnly: false

Utiliser le pilote CSI de disque persistant Compute Engine pour les clusters Windows

Les sections suivantes décrivent la procédure d'utilisation standard d'un volume Kubernetes reposant sur un pilote CSI dans GKE. Ces sections sont spécifiques aux clusters Windows

Vérifiez les données suivantes :

• La version du cluster est 1.19.7-gke.2000, 1.20.2-gke.2000 ou ultérieure.
• Les versions des nœuds sont 1.18.12-gke.1203, 1.19.6-gke.800 ou ultérieure.

Créer un objet StorageClass

La création d'une StorageClass pour Windows est très semblable à celle de Linux Sachez que la ressource StorageClass installée par défaut ne fonctionnera pas sous Windows, car le type de système de fichiers est différent. Le pilote CSI de disque persistant Compute Engine pour Windows nécessite NTFS en tant que type de système de fichiers.

Par exemple, vous pouvez créer un objet StorageClass à l'aide du fichier suivant nommé pd- windows-class.yaml. Veillez à ajouter csi.storage.k8s.io/fstype: NTFS à la liste des paramètres :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-sc-windows
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-balanced
  csi.storage.k8s.io/fstype: NTFS

Créer un objet PersistentVolumeClaim

Après avoir créé un objet StorageClass pour Windows, vous pouvez maintenant créer un objet PersistentVolumeClaim qui y fait référence :

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc-windows
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: pd-sc-windows
  resources:
    requests:
      storage: 6Gi

Créer un pod qui consomme le volume

L'exemple suivant utilise le volume que vous avez créé dans la tâche précédente :

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  # Node selector to ensure the Pod runs on a Windows node.
  nodeSelector:
    kubernetes.io/os: windows
  containers:
    - name: iis-server
      # The container image to use.
      image: mcr.microsoft.com/windows/servercore/iis
      ports:
      - containerPort: 80
      volumeMounts:
      # The path in the container where the volume will be mounted.
      - mountPath: /var/lib/www/html
        name: mypvc
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        # References the PersistentVolumeClaim created earlier.
        claimName: podpvc-windows
        readOnly: false

Modifier dynamiquement les IOPS et le débit Hyperdisk à l'aide de VolumeAttributeClass

Vous pouvez utiliser VolumeAttributesClass avec le pilote CSI de disque persistant Compute Engine pour modifier dynamiquement les attributs des disques persistants, y compris les IOPS et le débit. Assurez-vous que la version de votre cluster GKE est 1.34 ou ultérieure.

Cette section explique comment utiliser VolumeAttributesClass pour modifier dynamiquement les performances des volumes. Vous créez deux ressources VolumeAttributesClass, silver et gold, pour définir différents niveaux d'IOPS et de débit. Vous créez ensuite un StorageClass, un PersistentVolumeClaim faisant référence au niveau silver et un pod pour consommer le volume. Enfin, vous mettez à jour PersistentVolumeClaim pour faire référence au niveau gold, ce qui met à jour de manière dynamique les paramètres de performances du volume.

Remarque : Bien que les fichiers manifestes StorageClass et Pod pour l'utilisation générale de Persistent Disk soient abordés plus haut sur cette page, le workflow suivant est nécessaire pour configurer et valider les fonctionnalités de performances spécifiques de Google Cloud Hyperdisk.

Créer un VolumeAttributesClass pour définir les niveaux de performances

Cette section définit les ressources VolumeAttributesClass avec les niveaux d'exemple nommés silver et gold.

1. Enregistrez le manifeste suivant sous le nom vac-classes.yaml :

   apiVersion: storage.k8s.io/v1
   kind: VolumeAttributesClass
   metadata:
     name: silver
   driverName: pd.csi.storage.gke.io
   parameters:
     iops: "3000"
     throughput: "188Mi"
   ---
   apiVersion: storage.k8s.io/v1
   kind: VolumeAttributesClass
   metadata:
     name: gold
   driverName: pd.csi.storage.gke.io
   parameters:
     iops: "6000"
     throughput: "345Mi"
   

2. Appliquez le fichier manifeste :

   kubectl apply -f vac-classes.yaml
   

Créer une StorageClass pour Hyperdisk

Cette section définit une ressource StorageClass pour provisionner des volumes Hyperdisk.

1. Enregistrez le manifeste suivant sous le nom hyperdisk-sc.yaml :

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: hyperdisk-example
   provisioner: pd.csi.storage.gke.io
   volumeBindingMode: WaitForFirstConsumer
   allowVolumeExpansion: true
   parameters:
     type: hyperdisk-balanced
   

2. Appliquez le fichier manifeste :

   kubectl apply -f hyperdisk-sc.yaml
   

Créer un PVC avec un niveau de performances initial

Cette section crée un PVC et utilise le niveau initial nommé silver.

1. Enregistrez le manifeste suivant sous le nom vac-silver-pvc.yaml :

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-pv-claim
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: hyperdisk-example
     volumeAttributesClassName: silver
     resources:
       requests:
         storage: 200Gi
   

2. Appliquez le fichier manifeste :

   kubectl apply -f vac-silver-pvc.yaml
   

3. Pour provisionner un volume persistant, créez un pod qui consomme le PVC. Le StorageClass créé dans la section précédente définit volumeBindingMode: WaitForFirstConsumer, ce qui retarde le provisionnement du volume jusqu'à ce qu'un pod utilise la PVC. Enregistrez le manifeste suivant sous le nom test-pod.yaml :

   apiVersion: v1
   kind: Pod
   metadata:
     name: test-pvc-pod
   spec:
     containers:
       - name: nginx-container
         image: nginx:latest
         ports:
           - containerPort: 80
         volumeMounts:
           - name: pvc-storage
             mountPath: /usr/share/nginx/html
     volumes:
       - name: pvc-storage
         persistentVolumeClaim:
           claimName: test-pv-claim
   

4. Appliquez le fichier manifeste :

   kubectl apply -f test-pod.yaml
   

5. Pour vérifier les paramètres de performances des disques, consultez Vérifier les paramètres de performances des disques dans la console Google Cloud . Les valeurs IOPS provisionnées et Débit provisionné doivent être respectivement 3000 et 188.

Mettre à jour la PVC pour utiliser un autre niveau de performances

Cette section met à jour le PVC pour utiliser le niveau gold au lieu du niveau silver.

1. Enregistrez le manifeste suivant sous le nom vac-gold-pvc.yaml :

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-pv-claim
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: hyperdisk-example
     volumeAttributesClassName: gold
     resources:
       requests:
         storage: 200Gi
   

2. Appliquez le fichier manifeste :

   kubectl apply -f vac-gold-pvc.yaml
   

3. Pour vérifier que les paramètres de performances des disques sont à jour, consultez Vérifier les paramètres de performances des disques dans la console Google Cloud . Les valeurs IOPS provisionnées et Débit provisionné doivent être respectivement 6000 et 345.

Vérifier les paramètres de performances du disque dans la console Google Cloud

Vous pouvez vérifier que les paramètres d'IOPS et de débit sont appliqués au disque persistant en consultant les détails du disque dans la console Google Cloud .

1. Obtenez le nom du disque :

   PV_NAME=$(kubectl get pvc test-pv-claim -o=jsonpath='{.spec.volumeName}')
   DISK_NAME=$(kubectl get pv $PV_NAME -o=jsonpath='{.spec.csi.volumeHandle}' | sed 's|.*/||')
   echo "Persistent disk name: $DISK_NAME"
   

2. Dans la console Google Cloud , accédez à la page Disques.

   Accéder à la page Disques

3. Cliquez sur le nom du disque persistant qui correspond au nom du disque indiqué dans la sortie de l'étape précédente.

4. Sur la page Informations du disque, dans la section Performances, consultez les IOPS provisionnées et le débit provisionné.

Pour en savoir plus, consultez Afficher les paramètres de performances provisionnés pour Hyperdisk.

Points à prendre en compte pour la modification dynamique

• Réappliquer les configurations précédentes : si un PVC ne peut pas être associé à une classe d'attributs de volume en raison d'une erreur (par exemple, des ressources indisponibles), vous pouvez réappliquer le PVC précédent sans risque.
• Compatibilité avec les quotas : le plan de contrôle Kubernetes peut appliquer des quotas aux PVC faisant référence à un VolumeAttributesClass spécifique en utilisant scopeSelector dans ResourceQuota.

Utiliser le pilote CSI de disque persistant Compute Engine avec des types de systèmes de fichiers autres que ceux par défaut

Le type de système de fichiers par défaut pour les disques persistants Compute Engine dans GKE est ext4. Vous pouvez également utiliser le type de stockage xfs tant que votre image de nœud le permet. Consultez la section Compatibilité des pilotes de stockage avec la liste des pilotes compatibles par image de nœud.

L'exemple suivant montre comment utiliser xfs comme type de système de fichiers par défaut au lieu de ext4 avec le pilote CSI de disque persistant Compute Engine.

Créer un objet StorageClass

1. Enregistrez le fichier YAML de manifeste suivant dans un fichier nommé pd-xfs-class.yaml :

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: xfs-class
   provisioner: pd.csi.storage.gke.io
   parameters:
     # The type of Compute Engine persistent disk to provision.
     type: pd-balanced
     # Specify "xfs" as the filesystem type.
     csi.storage.k8s.io/fstype: xfs
   volumeBindingMode: WaitForFirstConsumer
   

2. Appliquer le fichier manifeste :

   kubectl apply -f pd-xfs-class.yaml
   

Créer un objet PersistentVolumeClaim

1. Enregistrez le manifeste suivant sous le nom pd-xfs-pvc.yaml :

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: xfs-pvc
   spec:
     # References the StorageClass created earlier.
     storageClassName: xfs-class
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         # The amount of storage requested.
         storage: 10Gi
   

2. Appliquer le fichier manifeste :

   kubectl apply -f pd-xfs-pvc.yaml
   

Créer un pod qui consomme le volume

1. Enregistrez le manifeste suivant sous le nom pd-xfs-pod.yaml :

   apiVersion: v1
   kind: Pod
   metadata:
     name: pd-xfs-pod
   spec:
     containers:
     - name: cloud-sdk
       image: google/cloud-sdk:slim
       # Keep the container running for 1 hour.
       args: ["sleep","3600"]
       volumeMounts:
       # The path in the container where the volume will be mounted.
       - mountPath: /xfs
         name: xfs-volume
     # Define the volumes available to the containers in the Pod.
     volumes:
     - name: xfs-volume
       persistentVolumeClaim:
         # References the PersistentVolumeClaim created earlier.
         claimName: xfs-pvc
   

2. Appliquer le fichier manifeste :

   kubectl apply -f pd-xfs-pod.yaml
   

Vérifier que le volume a été correctement installé

1. Ouvrez une session d'interface système dans le pod :

   kubectl exec -it pd-xfs-pod -- /bin/bash
   

2. Recherchez les partitions xfs :

   df -aTh --type=xfs
   

   La sortie devrait ressembler à ce qui suit :

   Filesystem     Type  Size  Used Avail Use% Mounted on
   /dev/sdb       xfs    30G   63M   30G   1% /xfs
   

Afficher les journaux pour le pilote CSI de disque persistant Compute Engine

Vous pouvez utiliser Cloud Logging pour afficher les événements liés au pilote CSI de disque persistant Compute Engine. Les journaux peuvent vous aider à résoudre les problèmes.

Pour en savoir plus sur Cloud Logging, consultez la section Afficher vos journaux GKE.

Pour afficher les journaux du pilote CSI de disque persistant Compute Engine, procédez comme suit :

1. Accédez à la page Cloud Logging dans la console Google Cloud .

   Accéder à Cloud Logging

2. Pour filtrer les entrées de journal afin de n'afficher que celles liées au pilote CSI qui s'exécute dans votre espace de noms, exécutez la requête Cloud Logging suivante :

    resource.type="k8s_container"
    resource.labels.project_id="PROJECT_ID"
    resource.labels.location="LOCATION"
    resource.labels.cluster_name="CLUSTER_NAME"
    resource.labels.namespace_name="kube-system"
    resource.labels.container_name="gce-pd-driver"
   

   Remplacez les éléments suivants :

   • PROJECT_ID : nom de votre projet.
   • LOCATION : région ou zone Compute Engine du cluster.
   • CLUSTER_NAME : nom du cluster.

Problèmes connus

Types de machines non compatibles

Si vous utilisez la famille de machines de la série C3, le type de disque persistant pd-standard n'est pas accepté.

Si vous essayez d'exécuter un pod sur une machine, et que le pod utilise un type de disque persistant non compatible, un message d'avertissement semblable au suivant s'affiche sur le pod :

AttachVolume.Attach failed for volume "pvc-d7397693-5097-4a70-9df0-b10204611053" : rpc error: code = Internal desc = unknown Attach error: failed when waiting for zonal op: operation operation-1681408439910-5f93b68c8803d-6606e4ed-b96be2e7 failed (UNSUPPORTED_OPERATION): [pd-standard] features are not compatible for creating instance.

Si votre cluster comporte plusieurs pools de nœuds avec différentes familles de machines, vous pouvez utiliser des rejets de nœuds et l'affinité de nœud pour limiter là où les charges de travail peuvent être planifiées. Par exemple, vous pouvez utiliser cette approche pour limiter l'exécution d'une charge de travail utilisant pd-standard sur une famille de machines non compatible.

Si vous utilisez le type de disque persistant pd-extreme, vous devez vous assurer que votre disque est associé à une instance de VM avec une forme de machine appropriée. Pour en savoir plus, consultez la page Compatibilité avec les types de machines.

Étapes suivantes

• Découvrez comment utiliser l'expansion du volume.
• Découvrez comment utiliser des instantanés de volume.
• Découvrez comment utiliser le clonage de volume.
• Découvrez comment créer des disques persistants régionaux.
• En savoir plus sur le pilote sur GitHub