En este documento, se proporcionan instrucciones para solucionar problemas de almacenamiento.
Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.No se puede conectar el volumen
Este problema se puede generar si un disco virtual está conectado a la máquina virtual incorrecta. Podría deberse al problema n.º 32727 en Kubernetes 1.12.
El resultado de gkectl diagnose cluster
se ve como en el siguiente ejemplo:
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
En este ejemplo, uno o más Pods están atascados en el estado ContainerCreating
y muestran advertencias como la que se muestra en el siguiente resultado de ejemplo:
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'.
Si un disco virtual está conectado a la máquina virtual incorrecta, puedes desconectarlo de forma manual siguiendo estos pasos:
Desvía un nodo. De manera opcional, puedes incluir las marcas
--ignore-daemonsets
y--delete-local-data
en el comando kubectl drain.Edita el archivo de configuración de hardware de la VM en vCenter para quitar el volumen.
Se perdió el volumen
Este problema puede ocurrir si se borró un disco virtual de forma permanente. Esta situación puede ocurrir si un operador borra de forma manual un disco virtual o la VM a la que está conectado.
Si ves un error “no encontrado” relacionado con tu archivo VMDK, es probable que el disco virtual se haya borrado de forma permanente.
El resultado de gkectl diagnose cluster
se ve de la siguiente manera:
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 más Pods se quedan en estado ContainerCreating
, como se muestra en el siguiente resultado de ejemplo:
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
Para evitar que se produzca este problema, administra tus máquinas virtuales como se describe en Cambia el tamaño de un clúster de usuarios y Actualiza clústeres.
Para resolver este problema, puedes limpiar de forma manual los recursos relacionados de Kubernetes:
Ejecuta
kubectl delete pvc [PVC_NAME]
para borrar el PVC que hizo referencia al PV.Ejecuta
kubectl delete pod [POD_NAME]
para borrar el Pod que hizo referencia al PVC.Repite el paso 2 debido al problema n.º 74374 de Kubernetes.
No se puede desconectar el volumen de CSI de vSphere
Este problema se genera si no se otorgó el privilegio CNS > Searchable
al usuario de vSphere.
Si encuentras Pods atascados en la fase ContainerCreating
con advertencias FailedAttachVolume
, podría deberse a una desconexión con errores en un nodo diferente.
Para verificar los errores de desconexión de CSI, ejecuta el siguiente comando:
kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message
El resultado es similar al siguiente ejemplo.
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>
Para resolver este problema, agrega el privilegio CNS > Searchable
a tu cuenta de usuario de vCenter.
La operación de desconexión se reintenta automáticamente hasta que se complete de forma correcta.
El controlador de CSI de vSphere no es compatible con el host de ESXi
Este problema se produce cuando un host ESXi en el clúster de vSphere ejecuta una versión inferior a ESXi 6.7U3.
El resultado de gkectl check-config
incluye la siguiente advertencia:
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.
Para resolver este problema, actualiza tus hosts de ESXi a la versión 6.7U3 o posterior.
No se pudo crear el volumen de CSI con el error NotSupported
Este problema se produce cuando un host ESXi en el clúster de vSphere ejecuta una versión inferior a ESXi 6.7U3.
El resultado de kubectl describe pvc
incluye el siguiente error:
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
Para resolver este problema, actualiza tus hosts de ESXi a la versión 6.7U3 o posterior.
No se pudo adjuntar el volumen de CSI de vSphere
Este problema conocido de Kubernetes en el controlador de CSI de vSphere de código abierto se produce cuando un nodo se cierra, se borra o falla.
El resultado de kubectl describe pod
se parece al siguiente ejemplo:
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
Para resolver este problema, realiza los siguientes pasos:
Toma nota del nombre de PersistentVolumeClaim (PVC) en el resultado anterior y busca los VolumeAttachments asociados con el PVC:
kubectl get volumeattachments | grep pvc-xxxxx
En el siguiente ejemplo de resultado, se muestran los nombres de los VolumeAttachments:
csi-yyyyy csi.vsphere.vmware.com pvc-xxxxx node-zzzzz ...
Describe los VolumeAttachments:
kubectl describe volumeattachments csi-yyyyy | grep "Deletion Timestamp"
Toma nota de la marca de tiempo de eliminación, como en el siguiente ejemplo de resultado:
Deletion Timestamp: 2021-03-10T22:14:58Z
Espera hasta el tiempo especificado en la marca de tiempo de eliminación y, luego, fuerza la eliminación del VolumeAttachment. Para ello, edita el objeto VolumeAttachment y borra el finalizador.
kubectl edit volumeattachment csi-yyyyy
Borra el finalizador:
[...] Finalizers: external-attacher/csi-vsphere-vmware-com
vSphere CSI VolumeSnapshot no está listo debido a la versión
Este problema se produce cuando la versión de vCenter Server o el host ESXi es inferior a la actualización 3 de 7.0.
El resultado de kubectl describe volumesnapshot
incluye errores como el siguiente ejemplo:
rpc error: code = Unimplemented desc = VC version does not support snapshot operations.
Para resolver este problema, actualiza vCenter Server y los hosts de ESXi a la versión 7.0 actualización 3 o posterior.
vSphere CSI VolumeSnapshot no está listo, instantáneas máximas por volumen
Este problema ocurre cuando la cantidad de instantáneas por volumen alcanza el valor máximo del controlador de almacenamiento de contenedores de vSphere. El valor predeterminado es tres.
El resultado de kubectl describe volumesnapshot
incluye los errores como el siguiente ejemplo:
rpc error: code = FailedPrecondition desc = the number of snapshots on the source volume 5394aac1-bc0a-44e2-a519-1a46b187af7b reaches the configured maximum (3)
Para resolver este problema, sigue estos pasos para actualizar la cantidad máxima de instantáneas por volumen:
Obtén el nombre del Secret que proporciona la configuración de vSphere al controlador de CSI de 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'
Reemplaza lo siguiente:
- ADMIN_KUBECONFIG: la ruta de acceso al archivo kubeconfig del clúster de administrador
- USER_CLUSTER_NAME: es el nombre del clúster de usuario.
Obtén el valor de
data.config
del Secret, decodifícalo en Base64 y guárdalo en un archivo llamadoconfig.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
Reemplaza SECRET_NAME por el nombre del Secret del paso anterior.
Abre
config.txt
para editarla:Edita o agrega el campo
global-max-snapshots-per-block-volume
en la sección[Snapshot]
, como en el siguiente ejemplo:[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
Borra y vuelve a crear el 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
Reinicia el 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>