Trident: Falhas aleatórias de montagem de pvc devido a tempos limite de blkid

Criado em 14 out. 2020  ·  4Comentários  ·  Fonte: NetApp/trident

Descreva o erro
Observamos muitos pods presos aleatoriamente no estado ContainerCreating porque eles não podem montar pvcs netapp. A descrição de pods aponta para tempos limite ao obter informações do dispositivo iSCSI e logs do trident daemonset sugerem que isso se deve a tempos limite durante a execução do comando blkid no host.
Esta é uma ocorrência aleatória e ainda não pode se correlacionar com determinados pvcs e hosts.

Ambiente

  • Versão tridente: 20.07.1
  • Sinalizadores de instalação do Trident usados: tridentctl install -n sys-trident --generate-custom-yaml (então kubectl apply -f - para os manifestos gerados)
  • Tempo de execução do contêiner: docker://19.3.12
  • Versão do Kubernetes: v1.19.2
  • Orquestrador do Kubernetes: nenhum
  • Gates de recursos habilitados para Kubernetes: apenas padrões do kubernetes
  • SO: Flatcar Container Linux por Kinvolk 2605.6.0 (Oklo) 5.4.67-flatcar
  • Tipos de back-end da NetApp: ontap-san, ONTAP 9.7.0

Reproduzir
Podemos observá-lo aleatoriamente em nossos nós de cluster (não parece estar relacionado a um determinado grupo de hosts)

Comportamento esperado
Um comportamento de montagem consistente dentro de uma janela de tempo razoável.

Contexto adicional
Ao descrever um pod "preso", podemos ver:

Events:
  Type     Reason       Age                  From     Message
  ----     ------       ----                 ----     -------
  Warning  FailedMount  51m (x5 over 72m)    kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[data thanos-storage vault-tls thanos-store-token-lj9j5]: timed out waiting for the condition
  Warning  FailedMount  42m (x3 over 56m)    kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[thanos-storage vault-tls thanos-store-token-lj9j5 data]: timed out waiting for the condition
  Warning  FailedMount  17m (x15 over 74m)   kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[vault-tls thanos-store-token-lj9j5 data thanos-storage]: timed out waiting for the condition
  Warning  FailedMount  14m (x22 over 74m)   kubelet  MountVolume.MountDevice failed for volume "pvc-e22cdf07-acfc-42af-a46a-bffd5ac32514" : rpc error: code = Internal desc = error getting iSCSI device information: process killed after timeout
  Warning  FailedMount  4m11s (x4 over 69m)  kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[thanos-store-token-lj9j5 data thanos-storage vault-tls]: timed out waiting for the condition

no mesmo nó dos respectivos logs do pod do daemonset trident:

time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.execCommandWithTimeout." args="[if=/dev/sdc bs=4096 count=1 status=none]" command=dd timeoutSeconds=5s
time="2020-10-14T14:32:41Z" level=debug msg="<<<< osutils.execCommandWithTimeout." command=dd error="<nil>"
time="2020-10-14T14:32:41Z" level=debug msg="<<<< osutils.ensureDeviceReadable"
time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.getFSType" device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.waitForDevice" device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg="Device found." device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg="<<<< osutils.waitForDevice" device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.execCommandWithTimeout." args="[/dev/sdc]" command=blkid timeoutSeconds=5s
time="2020-10-14T14:32:46Z" level=error msg="process killed after timeout" process=blkid
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.execCommandWithTimeout." command=blkid error="process killed after timeout"
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.getFSType"
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.getDeviceInfoForLUN" iSCSINodeName="iqn.1992-08.com.netapp:sn.0205ffce026911ebb4d9d039ea1a7953:vs.9" lunID=1 needFSType=true
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.AttachISCSIVolume"
time="2020-10-14T14:32:46Z" level=debug msg="<<<< NodeStageVolume" Method=NodeStageVolume Type=CSI_Node
time="2020-10-14T14:32:46Z" level=debug msg="Released shared lock (NodeStageVolume-pvc-e22cdf07-acfc-42af-a46a-bffd5ac32514)." lock=csi_node_server
time="2020-10-14T14:32:46Z" level=error msg="GRPC error: rpc error: code = Internal desc = error getting iSCSI device information: process killed after timeout"

parece que blkid não pode retornar na janela de tempo permitida (?)
se fizermos ssh no host e tentarmos o mesmo comando:

$ time sudo blkid /dev/sdc
/dev/sdc: UUID="f593b708-ed88-47b7-88ce-f9b8c85ab96b" TYPE="ext4"

real    0m36.393s
user    0m0.016s
sys     0m0.021s

nossa configuração json de back-end:
```
{
"versão 1,
"storageDriverName": "ontap-san",
"gerenciamentoLIF": "10.20.50.6",
"dataLIF": "10.20.50.4",
"svm": "dev_kube",
"igroupName": "dev_kube_trident",
"username": "xxxxxxxxx",
"senha": "xxxxxxxxxxx",
"padrões": {
"criptografia": "verdadeiro"
}
}
````

Estamos realmente presos aqui, então qualquer ajuda neste será muito apreciada!

bug

Comentários muito úteis

Fechando este como não o vimos desde que depuramos a velocidade dos nossos links de rede. Muito obrigado pela ajuda! :))

Todos 4 comentários

Olá @ffilippopoulos ,

Como você apontou, blkid é um comando de nível de host. A capacidade deste comando de retornar antes de expirar não é algo que o Trident possa controlar. Trident está basicamente fazendo a mesma coisa que você está fazendo quando você ssh no host e executa blkid de um shell. Você examinou a carga no host?

Além disso, se você precisar de assistência imediata com esse problema, entre em contato com o Suporte da NetApp.

Para abrir um caso com a NetApp, acesse https://mysupport.netapp.com/site/.
No canto inferior esquerdo, clique em 'Contatar Suporte'
Encontre o número apropriado de sua região para ligar ou fazer login.
Observação: o Trident não está listado na página, mas é um produto compatível com a NetApp com base em um SN de armazenamento Netapp compatível.
Abra o caso no SN de armazenamento da NetApp e forneça a descrição do problema.
Certifique-se de mencionar que o produto é Trident no Kubernetes e forneça os detalhes. Mencione este GitHub.
O caso será encaminhado aos engenheiros de suporte da Trident para resposta.

ei @gnarl obrigado pela resposta rápida. Até onde posso ver, há um tempo limite de 5 segundos neste comando, que está no campo tridents: https://github.com/NetApp/trident/blob/0a245d3895af31f910a58c2f26e5a0f8b25f34f8/utils/osutils.go#L2306

até onde posso ver, nossos nós não são carregados (por exemplo, no nó, agora vemos o problema load average: 0.54, 0.62, 0.61 ) e não acho que isso explicaria o comportamento que observamos.
Existe uma razão para o tempo limite codificado? está prevenindo algum caso que não temos conhecimento?

@ffilippopoulos , o blkid não deve levar nem perto de 5 segundos para ser executado. Se a carga em seu host estiver boa, você pode examinar a latência de rede entre o host e o NetApp dataLIF?

Temos um tempo limite difícil no blkid, pois se o blkid não funcionar, o Trident não poderá anexar o volume com segurança.

Fechando este como não o vimos desde que depuramos a velocidade dos nossos links de rede. Muito obrigado pela ajuda! :))

Esta página foi útil?
0 / 5 - 0 avaliações