Trident: Fallos aleatorios de montaje de pvc debido a tiempos de espera de blkid

Creado en 14 oct. 2020  ·  4Comentarios  ·  Fuente: NetApp/trident

Describa el error
Observamos muchos pods atascados aleatoriamente en el estado ContainerCreating porque no pueden montar pvc de netapp. La descripción de los pods apunta a tiempos de espera mientras se obtiene información del dispositivo iSCSI y los registros de trident daemonset sugieren que esto se debe a tiempos de espera mientras se ejecuta el comando blkid en el host.
Esta es una ocurrencia aleatoria y aún no puede correlacionarse con ciertos pvc y hosts.

Ambiente

  • Tridente versión: 20.07.1
  • Banderas de instalación de Trident utilizadas: tridentctl install -n sys-trident --generate-custom-yaml (luego kubectl apply -f - para los manifiestos generados)
  • Tiempo de ejecución del contenedor: docker://19.3.12
  • Versión de Kubernetes: v1.19.2
  • Orquestador de Kubernetes: ninguno
  • Puertas de funciones habilitadas para Kubernetes: solo valores predeterminados de Kubernetes
  • Sistema operativo: Flatcar Container Linux de Kinvolk 2605.6.0 (Oklo) 5.4.67-flatcar
  • Tipos de back-end de NetApp: ontap-san, ONTAP 9.7.0

Reproducir
Podemos observarlo aleatoriamente en nuestros nodos de clúster (no parece estar relacionado con un grupo particular de hosts)

Comportamiento esperado
Un comportamiento de montaje consistente dentro de una ventana de tiempo razonable.

Contexto adicional
Al describir un pod "atascado", 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

en el mismo nodo de los respectivos registros de pod de trident daemonset:

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 no puede regresar en la ventana de tiempo permitida (?)
si hacemos ssh en el host y probamos el mismo 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

nuestra configuración json backend:
```
{
"versión 1,
"storageDriverName": "ontap-san",
"gestiónLIF": "10.20.50.6",
"dataLIF": "10.20.50.4",
"svm": "dev_kube",
"igroupName": "dev_kube_trident",
"nombre de usuario": "xxxxxxxxx",
"contraseña": "xxxxxxxxxxxx",
"predeterminados": {
"cifrado": "verdadero"
}
}
````

¡Estamos realmente atrapados aquí, por lo que cualquier ayuda en este caso será muy apreciada!

bug

Comentario más útil

Cerrando este porque no lo hemos visto desde que depuramos la velocidad de nuestros enlaces de red. ¡Muchas gracias por la ayuda! :))

Todos 4 comentarios

Hola @ffilippopoulos ,

Como señaló, blkid es un comando de nivel de host. La capacidad de este comando para regresar antes de que se agote el tiempo no es algo que Trident pueda controlar. Trident básicamente está haciendo lo mismo que haces cuando ingresas al host y ejecutas blkid desde un shell. ¿Ha examinado la carga en el host?

Además, si necesita ayuda inmediata con este problema, póngase en contacto con el soporte de NetApp.

Para abrir un caso con NetApp, vaya a https://mysupport.netapp.com/site/.
Abajo a la izquierda, haga clic en 'Contactar con soporte'
Encuentre el número apropiado de su región para llamar o iniciar sesión.
Nota: Trident no aparece en la página, pero es un producto admitido por NetApp basado en un SN de almacenamiento de Netapp admitido.
Abra el caso en el SN de almacenamiento de NetApp y proporcione la descripción del problema.
Asegúrese de mencionar que el producto es Trident en Kubernetes y proporcione los detalles. Menciona este GitHub.
El caso se dirigirá a los ingenieros de soporte de Trident para que respondan.

hola @gnarl gracias por la rápida respuesta. Sin embargo, por lo que puedo ver, hay un tiempo de espera de 5 segundos en este comando, que está en el campo tridents: https://github.com/NetApp/trident/blob/0a245d3895af31f910a58c2f26e5a0f8b25f34f8/utils/osutils.go#L2306

por lo que puedo ver, nuestros nodos no están cargados en absoluto (por ejemplo, en el nodo ahora vemos el problema load average: 0.54, 0.62, 0.61 ) y no creo que esto explique el comportamiento que observamos.
¿Hay alguna razón para el tiempo de espera codificado? ¿Está previniendo algún caso del que no somos conscientes?

@ffilippopoulos , blkid no debería tardar ni cerca de 5 segundos en ejecutarse. Si la carga en su host se ve bien, ¿puede examinar la latencia de la red entre el host y el dataLIF de NetApp?

Tenemos un tiempo de espera difícil en blkid ya que si blkid no funciona, entonces Trident no puede adjuntar el volumen de manera segura.

Cerrando este porque no lo hemos visto desde que depuramos la velocidad de nuestros enlaces de red. ¡Muchas gracias por la ayuda! :))

¿Fue útil esta página
0 / 5 - 0 calificaciones