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
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!
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! :))
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! :))