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 :
Drainez le nœud. Consultez la page Drainer un nœud en toute sécurité. Vous pouvez inclure les options
--ignore-daemonsetset--delete-local-datadans votre commande kubectl drain.Modifiez la configuration matérielle de la VM dans vCenter pour supprimer le volume.
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:
Supprimez le PVC associé au PV en exécutant la commande
kubectl delete pvc [PVC_NAME].Supprimez le pod associé au PVC en exécutant la commande
kubectl delete pod [POD_NAME].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-164d56e3286e954befdf0f5a82d59031dbfd50709c927a0e6ccf21d1fa60192dcsi-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 :
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 ...
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
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:
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
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.
Ouvrez
config.txtpour y apporter des modifications :Modifiez ou ajoutez le champ
global-max-snapshots-per-block-volumedans 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
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
Redémarrez le déploiement
vsphere-csi-controller:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG rollout restart deployment vsphere-csi-controller \ --namespace USER_CLUSTER_NAME