Résoudre les problèmes de stockage

Ce document fournit des conseils de dépannage pour les problèmes de stockage.

Impossible d'associer un volume

Ce problème peut se produire si un disque virtuel est associé à la mauvaise machine virtuelle. Il peut être dû au problème #32727 dans Kubernetes 1.12.

Le résultat de gkectl diagnose cluster ressemble à ceci :

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-776459c3-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-776459c3-d350-11e9-9db8-e297f465bc84.vmdk" IS attached to machine "gsl-test-user-9b46dbf9b-9wdj7" but IS NOT listed in the Node.Status
1 storage errors

Un ou plusieurs pods sont bloqués à l'état ContainerCreating avec des avertissements de ce type:

Events:
  Type     Reason              Age               From                     Message
  ----     ------              ----              ----                     -------
  Warning  FailedAttachVolume  6s (x6 over 31s)  attachdetach-controller  AttachVolume.Attach failed for volume "pvc-776459c3-d350-11e9-9db8-e297f465bc84" : Failed to add disk 'scsi0:6'.

Pour remédier à ce problème :

Si un disque virtuel est associé à la mauvaise machine virtuelle, vous devrez peut-être le dissocier manuellement :

  1. Drainez le nœud. Consultez la page Drainer un nœud en toute sécurité. Vous pouvez inclure les options --ignore-daemonsets et --delete-local-data dans votre commande kubectl drain.

  2. Mettez la VM hors tension.

  3. Modifiez la configuration matérielle de la VM dans vCenter pour supprimer le volume.

  4. Mettez la VM sous tension.

  5. Marquer le nœud comme non ordonnançable

Le volume est perdu

Ce problème peut se produire si un disque virtuel a été définitivement supprimé. Cela peut se produire si un opérateur supprime manuellement un disque virtuel ou la machine virtuelle à laquelle ce disque est associé. Si une erreur "introuvable" s'affiche pour votre fichier VMDK, cela signifie vraisemblablement que le disque virtuel a été définitivement supprimé.

Le résultat de gkectl diagnose cluster ressemble à ceci :

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-52161704-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk" IS NOT found
1 storage errors

Un ou plusieurs pods sont bloqués dans l'état ContainerCreating:

Events:
  Type     Reason              Age                   From                                    Message
  ----     ------              ----                  ----                                    -------
  Warning  FailedAttachVolume  71s (x28 over 42m)    attachdetach-controller                 AttachVolume.Attach failed for volume "pvc-52161704-d350-11e9-9db8-e297f465bc84" : File []/vmfs/volumes/43416d29-03095e58/kubevols/
  kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk was not found

Pour éviter que ce problème ne se produise, gérez vos machines virtuelles, comme décrit dans les pages Redimensionner un cluster utilisateur et Mettre à niveau les clusters.

Pour résoudre ce problème, vous devrez peut-être nettoyer manuellement les ressources Kubernetes associées:

  1. Supprimez le PVC associé au PV en exécutant la commande kubectl delete pvc [PVC_NAME].

  2. Supprimez le pod associé au PVC en exécutant la commande kubectl delete pod [POD_NAME].

  3. Répétez l'étape 2. (Oui. Consultez le problème Kubernetes 74374.

Échec de la dissociation du volume CSI vSphere

Ce problème se produit si le privilège CNS > Searchable n'a pas été accordé à l'utilisateur vSphere.

Si vous constatez que des pods sont bloqués dans la phase ContainerCreating avec des avertissements FailedAttachVolume, cela peut être dû à un échec de dissociation sur un autre nœud.

Pour rechercher les erreurs de dissociation CSI:

kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message

Le résultat ressemble à ce qui suit :

NAME                                                                   DETACH_ERROR
csi-0e80d9be14dc09a49e1997cc17fc69dd8ce58254bd48d0d8e26a554d930a91e5   rpc error: code = Internal desc = QueryVolume failed for volumeID: "57549b5d-0ad3-48a9-aeca-42e64a773469". ServerFaultCode: NoPermission
csi-164d56e3286e954befdf0f5a82d59031dbfd50709c927a0e6ccf21d1fa60192d   
csi-8d9c3d0439f413fa9e176c63f5cc92bd67a33a1b76919d42c20347d52c57435c   
csi-e40d65005bc64c45735e91d7f7e54b2481a2bd41f5df7cc219a2c03608e8e7a8   

Pour résoudre ce problème, ajoutez le privilège CNS > Searchable à votre compte utilisateur vCenter. L'opération de dissociation fait automatiquement l'objet de plusieurs tentatives jusqu'à ce qu'elle aboutisse.

Le pilote CSI vSphere n'est pas compatible avec l'hôte ESXi

Ce problème se produit lorsqu'un hôte ESXi du cluster vSphere exécute une version antérieure à ESXi 6.7U3.

Le résultat de gkectl check-config inclut cet avertissement :

The vSphere CSI driver is not supported on current ESXi host versions.
CSI requires ESXi 6.7U3 or above. See logs for ESXi version details.

Pour résoudre ce problème, mettez à niveau vos hôtes ESXi vers la version 6.7U3 ou ultérieure.

Échec de la création du volume CSI avec l'erreur NotSupported

Ce problème se produit lorsqu'un hôte ESXi du cluster vSphere exécute une version antérieure à ESXi 6.7U3.

Le résultat de kubectl describe pvc inclut l'erreur suivante :

Failed to provision volume with StorageClass : rpc error:
code = Internal desc = Failed to create volume. Error: CnsFault error:
CNS: Failed to create disk.:Fault cause: vmodl.fault.NotSupported

Pour résoudre ce problème, mettez à niveau vos hôtes ESXi vers la version 6.7U3 ou ultérieure.

Échec de l'association du volume CSI vSphere

Ce problème connu dans le pilote Open Source CSI vSphere se produit lorsqu'un nœud est arrêté, supprimé ou échoue.

Le résultat de kubectl describe pod ressemble à ceci :

Events:
 Type    Reason                 From                     Message
 ----    ------             ... ----                     -------
 Warning FailedAttachVolume ... attachdetach-controller  Multi-Attach error for volume
                                                         "pvc-xxxxx"
                                                         Volume is already exclusively attached to one
                                                         node and can't be attached to another

Pour remédier à ce problème :

  1. Notez le nom de l'objet PersistentVolumeClaim (PVC) indiqué dans le résultat précédent et recherchez l'objet VolumeAttachments associé à au PVC. Exemple :

    kubectl get volumeattachments | grep pvc-xxxxx
    

    Le résultat affiche les noms de l'objet VolumeAttachments. Exemple :

    csi-yyyyy   csi.vsphere.vmware.com   pvc-xxxxx   node-zzzzz ...
    
  2. Décrivez l'objet VolumeAttachments. Exemple :

    kubectl describe volumeattachments csi-yyyyy | grep "Deletion Timestamp"
    

    Notez l'horodatage de suppression dans le résultat :

    Deletion Timestamp:   2021-03-10T22:14:58Z
    
  3. Attendez l'heure spécifiée par l'horodatage de suppression, puis forcez la suppression de l'objet VolumeAttachments. Pour ce faire, modifiez l'objet VolumeAttachments et supprimez le finaliseur. Exemple :

    kubectl edit volumeattachment csi-yyyyy
     Finalizers:
      external-attacher/csi-vsphere-vmware-com
    

vSphere CSI VolumeSnapshot n'est pas prêt en raison de la version

Ce problème se produit lorsque la version de vCenter Server ou de l'hôte ESXi est antérieure à la version 7.0, mise à jour 3.

Le résultat de kubectl describe volumesnapshot inclut des erreurs de ce type:

rpc error: code = Unimplemented desc = VC version does not support snapshot operations.

Pour résoudre ce problème, mettez à niveau vCenter Server et les hôtes ESXi vers la version 7.0 Update 3 ou une version ultérieure.

vSphere CSI VolumeSnapshot n'est pas prêt, nombre maximal d'instantanés par volume

Ce problème se produit lorsque le nombre d'instantanés par volume atteint la valeur maximale du pilote de stockage de conteneurs vSphere. La valeur par défaut est trois.

Le résultat de kubectl describe volumesnapshot inclut les erreurs de ce type:

rpc error: code = FailedPrecondition desc = the number of snapshots on the source volume 5394aac1-bc0a-44e2-a519-1a46b187af7b reaches the configured maximum (3)

Pour résoudre ce problème, procédez comme suit afin de mettre à jour le nombre maximal d'instantanés par volume:

  1. Obtenez le nom du secret qui fournit la configuration vSphere au contrôleur CSI vSphere:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get deployment vsphere-csi-controller \
       --namespace USER_CLUSTER_NAME \
       --output json \
       | jq -r '.spec.template.spec.volumes[] \
       | select(.name=="vsphere-secret") .secret.secretName'
    

    Remplacez les éléments suivants :

    • ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
    • USER_CLUSTER_NAME : nom de votre cluster d'utilisateur
  2. Obtenez la valeur de data.config à partir du secret, décodez-le en base64 et enregistrez-le dans un fichier nommé config.txt:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret SECRET_NAME \
       --namespace USER_CLUSTER_NAME  \
       --output json | jq -r '.data["config"]' | base64 -d > config.txt
    

    Remplacez SECRET_NAME par le nom du secret obtenu à l'étape précédente.

  3. Ouvrez config.txt pour y apporter des modifications :

    Modifiez ou ajoutez le champ global-max-snapshots-per-block-volume dans la section [Snapshot]. Exemple :

    [Global]
    cluster-id = "my-user-cluster"
    insecure-flag = "0"
    user = "my-account.local"
    password = "fxqSD@SZTUIsG"
    [VirtualCenter "my-vCenter"]
    port = "443"
    datacenters = "my-datacenter1"
    [Snapshot]
    global-max-snapshots-per-block-volume = 4
    
  4. Supprimez et recréez le secret:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete secret SECRET_NAME \
       --namespace USER_CLUSTER_NAME
    
    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG create secret generic SECRET_NAME \
       --namespace USER_CLUSTER_NAME \
       --from-file=config
    
  5. Redémarrez le déploiement vsphere-csi-controller:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG rollout restart deployment vsphere-csi-controller \
       --namespace USER_CLUSTER_NAME