Solução de problemas de armazenamento

Este documento fornece orientações para a solução de problemas de armazenamento.

Falha ao anexar o volume

Esse problema pode ocorrer se um disco virtual estiver anexado à máquina virtual errada. Isso pode ser devido ao Problema 32727 do Kubernetes 1.12.

A saída do gkectl diagnose cluster tem esta aparência:

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

Um ou mais pods estão parados no estado ContainerCreating com avisos como este:

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'.

Para resolver o problema:

Se um disco virtual estiver anexado à máquina virtual errada, talvez seja necessário desanexá-lo manualmente:

  1. Drene o nó. Consulte Como drenar um nó com segurança. Convém incluir as sinalizações --ignore-daemonsets e --delete-local-data no comando kubectl drain.

  2. Desligue a VM.

  3. Edite a configuração de hardware da VM no vCenter para remover o volume.

  4. Ligue a VM

  5. Desfaça o nó

O volume foi perdido

Esse problema poderá ocorrer se um disco virtual for excluído permanentemente. Isso pode acontecer se um operador excluir manualmente um disco virtual ou a máquina virtual a que estiver anexado. Se você vir um erro "não encontrado" relacionado ao arquivo VMDK, é provável que o disco virtual tenha sido excluído permanentemente.

A saída do gkectl diagnose cluster tem esta aparência:

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 parados no estado 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

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, pode ser necessário limpar manualmente os recursos relacionados ao Kubernetes:

  1. Execute kubectl delete pvc [PVC_NAME] para excluir o PVC que fez referência ao PV.

  2. Execute kubectl delete pod [POD_NAME] para excluir o pod que fez referência ao PVC.

  3. Repita a etapa 2. Isso mesmo. Consulte o 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 de CSI:

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   
csi-8d9c3d0439f413fa9e176c63f5cc92bd67a33a1b76919d42c20347d52c57435c   
csi-e40d65005bc64c45735e91d7f7e54b2481a2bd41f5df7cc219a2c03608e8e7a8

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 este 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 este erro:

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

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 no driver CSI de código aberto do vSphere ocorre quando um nó é encerrado, excluído ou falha.

A saída do kubectl describe pod tem esta aparência:

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 o problema:

  1. Anote o nome do PersistentVolumeClaim (PVC) na saída anterior e encontre os VolumeAttachments associados ao PVC. Exemplo:

    kubectl get volumeattachments | grep pvc-xxxxx

    A saída mostra os nomes dos VolumeAttachments. Exemplo:

    csi-yyyyy   csi.vsphere.vmware.com   pvc-xxxxx   node-zzzzz ...

  2. Descreva os VolumeAttachments. Exemplo:

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

    Anote o carimbo de data/hora de exclusão na saída:

    Deletion Timestamp:   2021-03-10T22:14:58Z

  3. 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. Exemplo:

    kubectl edit volumeattachment csi-yyyyy
 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 este:

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 este:

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:

  1. Descubra o nome do secret que fornece a configuração do vSphere para o controlador CSI do 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'

    Substitua:

    • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador;
    • USER_CLUSTER_NAME: o nome do cluster de usuário

  2. Descubra o valor de data.config do secret, decodifique-o em base64 e salve-o em um arquivo chamado 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

    Substitua o SECRET_NAME pelo nome do secret da etapa anterior.

  3. Abra config.txt para edição:

    Edite ou adicione o campo global-max-snapshots-per-block-volume na seção [Snapshot]. Exemplo:

    [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. Exclua e recrie o 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. Reinicie a implantação vsphere-csi-controller:

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