Família de drivers da interface de armazenamento de contêiner: Quando um nó fica inativo, os volumes de bloco que estão conectados ao nó não podem ser conectados a outro nó

Resumo: Quando um nó fica inativo (devido a um cenário de falha, nó inativo, desligamento), os volumes de bloco que estão conectados ao nó não podem ser conectados a outro nó.

Este artigo aplica-se a Este artigo não se aplica a Este artigo não está vinculado a nenhum produto específico. Nem todas as versões do produto estão identificadas neste artigo.

Sintomas

Quando um nó fica inativo (devido a um cenário de falha, nó inativo, desligamento), os volumes de bloco que estão conectados ao nó não podem ser conectados a outro nó. 

O problema é específico para volumes de bloco apenas.

O problema não ocorre para volumes NFS.

O problema afeta os seguintes drivers:

  • Driver de CSI para PowerFlex
  • Driver CSI para PowerMax
  • Driver CSI para PowerScale
  • Driver CSI para Unity

Esse problema não afeta o driver de CSI do PowerStore.

O problema é relatado em GitHub #282Esse hiperlink direcionará você para um site fora da Dell Technologies.

Etapas para reprodução: 

  1. Crie um PVC1 e um POD1.
  2. Verifique o nó em que o POD1 foi criado e desligue o nó do vSphere.
  3. Quando o nó não estiver pronto, tente excluir o POD1 (ele fica preso no estado de encerramento, pois o nó não está pronto.)
  4. Tente criar POD2 usando o mesmo PVC1. O POD2 está no estado de criação do contêiner com este erro na saída descrita.
Warning FailedAttachVolume 43s attachdetach-controller Multi-Attach error for volume "csivol-18eb3daee0" Volume is already used by pod(s) iscsipod1-p 

Resultado esperado: O POD deve ser excluído mesmo quando o nó não estiver pronto.

Resultado: O POD está preso no estado de encerramento porque o nó não está pronto.

O resultado abaixo mostra o pod original terminando e o novo pod preso na criação de contêiner:

kubectl get pods -o wide

NAME        READY STATUS            RESTARTS AGE   IP     NODE    NOMINATED NODE READINESS GATES
iscsipod1-p 1/1   Terminating       0        9m43s <IP>   <Node3> <none>         <none>
iscsipod2-p 0/1   ContainerCreating 0        55s   <none> <Node2> <none>         <none>


O comando a seguir mostra que o nó não está pronto:

kubectl get nodes

NAME  STATUS   ROLES                AGE  VERSION
Node1 Ready    control-plane,master 163d v1.23.0
Node2 Ready    <none>               162d v1.23.0
Node3 NotReady <none>              162d v1.23.0


O comando a seguir mostra que o PVC ainda está vinculado ao PV:

kubectl get pvc -n <namespace>

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
iscsipvc1-p Bound csivol-18eb3daee0 5Gi RWO powerstore-iscsi 10m


O seguinte comando mostra a advertência:

kubectl describe pod -n <namespace>

...
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 108s default-scheduler Successfully assigned default/iscsipod2-p to lglw3178
Warning FailedAttachVolume 108s attachdetach-controller Multi-Attach error for volume "csivol-18eb3daee0" Volume is already used by pod(s) iscsipod1-p

Causa

A causa raiz é que o sidecar do attacher não é capaz de enviar ControllerUnpublishVolume() para o nó que ficou inativo. Veja as informações contidas no GitHub #215 Esse hiperlink direcionará você para um site fora da Dell Technologies.

Resolução

Solução temporária:
  1. Force a exclusão do pod que estava em execução no nó que ficou inativo.
kubectl delete po <pod name> --force --grace-period=0
  1. Exclua o anexo de volume ao nó que ficou inativo.
kubectl delete volumeattachment <volumeattachment>

Agora, o volume pode ser conectado ao novo nó.

Resolução:
 Essa solução será atualizada quando uma correção for lançada.
Propriedades do artigo
Número do artigo: 000200778
Tipo de artigo: Solution
Último modificado: 07 jul. 2023
Versão:  8
Encontre as respostas de outros usuários da Dell para suas perguntas.
Serviços de suporte
Verifique se o dispositivo está coberto pelos serviços de suporte.