Este documento fornece orientações para a solução de problemas de armazenamento.
Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.Falha ao anexar o volume
Esse problema poderá ocorrer se um disco virtual estiver anexado à máquina virtual errada e poderá ser devido ao problema 32727 no Kubernetes 1.12.
A saída de gkectl diagnose cluster
vai ser semelhante ao exemplo a seguir:
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
Neste exemplo, um ou mais pods estão presos no estado ContainerCreating
e mostram avisos como o exemplo de saída a seguir:
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 um disco virtual estiver anexado à máquina virtual errada, é possível desanexá-lo manualmente usando as seguintes etapas:
Drene um nó. Opcionalmente, as sinalizações
--ignore-daemonsets
e--delete-local-data
podem ser incluídas no comando kubectl Dren..Edite a configuração de hardware da VM no vCenter para remover o volume.
O volume foi perdido
Esse problema poderá ocorrer se um disco virtual for excluído permanentemente. Essa situação poderá acontecer se um operador excluir manualmente um disco virtual ou excluir a VM à qual o disco está conectado.
Se você vir um erro "não encontrado" relacionado ao seu arquivo VMDK, é provável que o disco virtual tenha sido excluído permanentemente.
A saída de gkectl diagnose cluster
vai ser semelhante a esta:
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
Um ou mais pods estão travados no estado ContainerCreating
, conforme mostrado no
exemplo de saída a seguir:
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 esse problema ocorra, gerencie as máquinas virtuais conforme descrito em Como redimensionar um cluster de usuário e Como fazer upgrade de clusters.
Para resolver esse problema, limpe manualmente os recursos relacionados do Kubernetes:
Execute
kubectl delete pvc [PVC_NAME]
para excluir o PVC que fez referência ao PV.Execute
kubectl delete pod [POD_NAME]
para excluir o pod que fez referência ao PVC.Repita a etapa 2 devido ao problema 74374 do Kubernetes.
Não é possível remover o volume do CSI do vSphere
Esse problema ocorrerá se o privilégio CNS > Searchable
não tiver sido concedido ao
usuário do vSphere.
Se você encontrar pods parados na fase ContainerCreating
com
avisos FailedAttachVolume
, pode ser devido a uma falha de remoção em
um nó diferente.
Para verificar se há erros de remoção do CSI, execute o seguinte comando:
kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message
A resposta será semelhante a:
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 esse problema, adicione o privilégio CNS > Searchable
à sua
conta de usuário do vCenter.
Essa operação é repetida automaticamente até ser concluída.
O driver CSI do vSphere não é compatível com o host ESXi
Esse problema ocorre quando um host ESXi no cluster do vSphere está executando uma versão anterior à ESXi 6.7U3.
A saída de gkectl check-config
inclui o seguinte aviso:
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 esse problema, faça upgrade dos hosts ESXi para a versão 6.7U3 ou posterior.
Falha na criação do volume CSI com erro NotSupported
Esse problema ocorre quando um host ESXi no cluster do vSphere está executando uma versão anterior à ESXi 6.7U3.
A saída de kubectl describe pvc
inclui o seguinte erro:
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 esse problema, faça upgrade dos hosts ESXi para a versão 6.7U3 ou posterior.
Falha ao anexar o volume CSI do vSphere
Esse problema conhecido do Kubernetes no driver CSI de código aberto do vSphere ocorre quando um nó é encerrado, excluído ou falha.
A saída de kubectl describe pod
é semelhante a esta:
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 esse problema, siga estas etapas:
Anote o nome do PersistentVolumeClaim (PVC) na saída anterior e encontre os VolumeAttachments associados ao PVC:
kubectl get volumeattachments | grep pvc-xxxxx
O exemplo de saída a seguir mostra os nomes dos VolumeAttachments:
csi-yyyyy csi.vsphere.vmware.com pvc-xxxxx node-zzzzz ...
Descreva os VolumeAttachments:
kubectl describe volumeattachments csi-yyyyy | grep "Deletion Timestamp"
Anote o carimbo de data/hora da exclusão, como no exemplo de saída a seguir:
Deletion Timestamp: 2021-03-10T22:14:58Z
Aguarde até o horário especificado pelo carimbo de data/hora de exclusão e force a exclusão do VolumeAttachment. Para fazer isso, edite o objeto VolumeAttachment e exclua o finalizador.
kubectl edit volumeattachment csi-yyyyy
Exclua o finalizador:
[...] Finalizers: external-attacher/csi-vsphere-vmware-com
O VolumeSnapshot do CSI do vSphere não está pronto por causa da versão
Esse problema ocorre quando a versão do host do vCenter ou do host ESXi é inferior à 7.0 atualização 3.
A saída de kubectl describe volumesnapshot
inclui erros como o
exemplo abaixo:
rpc error: code = Unimplemented desc = VC version does not support snapshot operations.
Para resolver esse problema, faça upgrade dos hosts do vCenter Server e ESXi para a versão 7.0 Atualização 3 ou mais recente.
O VolumeSnapshot do CSI do vSphere não está pronto, máximo de snapshots por volume
Esse problema ocorre quando o número de snapshots por volume atinge o valor máximo do driver do vSphere Container Storage. O valor padrão é três.
A saída de kubectl describe volumesnapshot
inclui os erros, como no
exemplo a seguir:
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 esse problema, use as seguintes etapas para atualizar o número máximo de snapshots por volume:
Descubra o nome do secret que fornece a configuração do vSphere para o controlador CSI do 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'
Substitua:
- ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador;
- USER_CLUSTER_NAME: o nome do cluster de usuário
Descubra o valor de
data.config
do secret, decodifique-o em base64 e salve-o em um arquivo chamadoconfig.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
Substitua o SECRET_NAME pelo nome do secret da etapa anterior.
Abra
config.txt
para edição:Edite ou adicione o campo
global-max-snapshots-per-block-volume
na seção[Snapshot]
, como no exemplo a seguir:[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
Exclua e recrie o 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
Reinicie a implantação
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>