Questo documento fornisce indicazioni per la risoluzione dei problemi relativi allo spazio di archiviazione.
Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.Impossibile collegare il volume
Questo problema può verificarsi se un disco virtuale è collegato alla macchina virtuale sbagliata e potrebbe essere dovuto al Problema n. 32727 in Kubernetes 1.12.
L'output di gkectl diagnose cluster
è simile al seguente esempio:
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
In questo esempio, uno o più pod sono bloccati nello stato ContainerCreating
e mostrano avvisi come l'output di esempio seguente:
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'.
Se un disco virtuale è collegato alla macchina virtuale sbagliata, puoi scollegarlo manualmente seguendo questa procedura:
Svuota un nodo. Facoltativamente, puoi includere i flag
--ignore-daemonsets
e--delete-local-data
nel tuo comando kubectl dry.Modifica la configurazione hardware della VM in vCenter per rimuovere il volume.
Il volume è stato perso
Questo problema può verificarsi se un disco virtuale è stato eliminato definitivamente. Questa situazione può verificarsi se un operatore elimina manualmente un disco virtuale o elimina la VM a cui è collegato il disco.
Se visualizzi un errore "non trovato" relativo al file VMDK, è probabile che il disco virtuale sia stato eliminato definitivamente.
L'output di gkectl diagnose cluster
è simile al seguente:
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
Uno o più pod sono bloccati nello stato ContainerCreating
, come mostrato nell'output di esempio seguente:
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
Per evitare che questo problema si verifichi, gestisci le macchine virtuali come descritto in Ridimensionare un cluster utente e Upgrade dei cluster.
Per risolvere il problema, puoi eseguire manualmente la pulizia delle risorse Kubernetes correlate:
Elimina la PVC che ha fatto riferimento al PV eseguendo
kubectl delete pvc [PVC_NAME]
.Elimina il pod che ha fatto riferimento alla PVC eseguendo
kubectl delete pod [POD_NAME]
.Ripeti il passaggio 2 a causa del problema di Kubernetes n. 74374.
Impossibile scollegare il volume CSI vSphere
Questo problema si verifica se il privilegio CNS > Searchable
non è stato concesso all'utente vSphere.
Se trovi pod bloccati nella fase ContainerCreating
con
FailedAttachVolume
avvisi, la causa potrebbe essere uno scollegamento non riuscito su
un altro nodo.
Per verificare la presenza di errori di scollegamento CSI, esegui questo comando:
kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message
L'output è simile all'esempio seguente:
NAME DETACH_ERROR
csi-0e80d9be14dc09a49e1997cc17fc69dd8ce58254bd48d0d8e26a554d930a91e5 rpc error: code = Internal desc = QueryVolume failed for volumeID: "57549b5d-0ad3-48a9-aeca-42e64a773469". ServerFaultCode: NoPermission
csi-164d56e3286e954befdf0f5a82d59031dbfd50709c927a0e6ccf21d1fa60192d <none>
csi-8d9c3d0439f413fa9e176c63f5cc92bd67a33a1b76919d42c20347d52c57435c <none>
csi-e40d65005bc64c45735e91d7f7e54b2481a2bd41f5df7cc219a2c03608e8e7a8 <none>
Per risolvere il problema, aggiungi il privilegio CNS > Searchable
al tuo account utente vCenter.
L'operazione di scollegamento riprova automaticamente finché non viene eseguita correttamente.
Driver CSI vSphere non supportato sull'host ESXi
Questo problema si verifica quando un host ESXi nel cluster vSphere esegue una versione inferiore a ESXi 6.7U3.
L'output di gkectl check-config
include il seguente avviso:
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.
Per risolvere il problema, eseguire l'upgrade degli host ESXi alla versione 6.7U3 o successiva.
La creazione del volume CSI non riesce e restituisce NotSupported
errore
Questo problema si verifica quando un host ESXi nel cluster vSphere esegue una versione inferiore a ESXi 6.7U3.
L'output di kubectl describe pvc
include il seguente errore:
Failed to provision volume with StorageClass <standard-rwo>: rpc error:
code = Internal desc = Failed to create volume. Error: CnsFault error:
CNS: Failed to create disk.:Fault cause: vmodl.fault.NotSupported
Per risolvere il problema, eseguire l'upgrade degli host ESXi alla versione 6.7U3 o successiva.
Impossibile collegare il volume CSI vSphere
Questo problema noto di Kubernetes nel driver CSI vSphere open source si verifica quando un nodo viene arrestato, eliminato o guasto.
L'output di kubectl describe pod
è simile al seguente:
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
Per risolvere il problema, completa i seguenti passaggi:
Prendi nota del nome dell'oggetto PersistentVolumeClaim (PVC) nell'output precedente e trova i VolumeAttachment associati a quest'ultima:
kubectl get volumeattachments | grep pvc-xxxxx
L'output di esempio seguente mostra i nomi degli oggetti VolumeAttachments:
csi-yyyyy csi.vsphere.vmware.com pvc-xxxxx node-zzzzz ...
Descrivi i VolumeAttachments:
kubectl describe volumeattachments csi-yyyyy | grep "Deletion Timestamp"
Prendi nota del timestamp di eliminazione, come nell'output di esempio che segue:
Deletion Timestamp: 2021-03-10T22:14:58Z
Attendi fino al tempo specificato dal timestamp di eliminazione, quindi forza l'eliminazione del VolumeAttachment. Modifica l'oggetto VolumeAttachment ed elimina il finalizzatore.
kubectl edit volumeattachment csi-yyyyy
Elimina il finalizzatore:
[...] Finalizers: external-attacher/csi-vsphere-vmware-com
vSphere CSI VolumeSnapshot non pronto a causa della versione
Questo problema si verifica quando la versione di vCenter Server o dell'host ESXi precedente alla 7.0 Update 3.
L'output di kubectl describe volumesnapshot
include errori come
nell'esempio seguente:
rpc error: code = Unimplemented desc = VC version does not support snapshot operations.
Per risolvere il problema, eseguire l'upgrade di vCenter Server e degli host ESXi alla versione 7.0 Update 3 o versione successiva.
vSphere CSI VolumeSnapshot non pronto, numero massimo di snapshot per volume
Questo problema si verifica quando il numero di snapshot per volume raggiunge il valore massimo per il driver di vSphere Container Storage. Il valore predefinito è tre.
L'output di kubectl describe volumesnapshot
include gli errori come
nell'esempio seguente:
rpc error: code = FailedPrecondition desc = the number of snapshots on the source volume 5394aac1-bc0a-44e2-a519-1a46b187af7b reaches the configured maximum (3)
Per risolvere il problema, segui questi passaggi per aggiornare il numero massimo di snapshot per volume:
Ottieni il nome del secret che fornisce la configurazione vSphere al controller CSI vSphere:
kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> get deployment vsphere-csi-controller \ --namespace <var class="edit">USER_CLUSTER_NAME</var> \ --output json \ | jq -r '.spec.template.spec.volumes[] \ | select(.name=="vsphere-secret") .secret.secretName'
Sostituisci quanto segue:
- ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione
- USER_CLUSTER_NAME: il nome del cluster utente
Ottieni il valore
data.config
dal secret, decodificalo in base64 e salvalo in un file denominatoconfig.txt
:kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> get secret <var class="edit">SECRET_NAME</var> \ --namespace <var class="edit">USER_CLUSTER_NAME </var> \ --output json | jq -r '.data["config"]' | base64 -d > config.txt
Sostituisci SECRET_NAME con il nome del secret del passaggio precedente.
Apri
config.txt
per la modifica:Modifica o aggiungi il campo
global-max-snapshots-per-block-volume
nella sezione[Snapshot]
, come nell'esempio seguente:[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
Elimina e ricrea il secret:
kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> delete secret <var class="edit">SECRET_NAME</var> \ --namespace <var class="edit">USER_CLUSTER_NAME</var> kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> create secret generic <var class="edit">SECRET_NAME</var> \ --namespace <var class="edit">USER_CLUSTER_NAME</var> \ --from-file=config
Riavvia il deployment
vsphere-csi-controller
:kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> rollout restart deployment vsphere-csi-controller \ --namespace <var class="edit">USER_CLUSTER_NAME</var>