Saltar a contenido

multipathd reclamaba los LUNs de Longhorn y bloqueaba mounts en kobe — 2026-10-29

Al crear un volumen Longhorn nuevo, kobe no podía formatearlo ni montarlo; el pod quedaba en ContainerCreating. Solo afectaba a kobe.

Estado

Campo Valor
Primera aparición 2026-10-29
Estado Resuelto
Resuelto 2026-10-29
Severidad Media
Servicios afectados Longhorn, kubelet, Uptime Kuma

Síntomas

  • Pod en ContainerCreating con FailedMount en kobe.
  • kubelet: mount: /dev/longhorn/pvc-... already mounted or mount point busy.
  • fsck previo: /dev/longhorn/pvc-... is in use.
  • mke2fs: is apparently in use by the system; will not make a filesystem here!.
  • Un PVC de prueba nuevo en kobe sí montaba, pero el volumen de Uptime Kuma (formateado antes en kyrie) no. El montaje manual tampoco funcionaba.

Cronología

Hora (CEST) Evento Evidencia
2026-10-29 18:05 Primer fallo de mount en kobe con el PVC de Uptime Kuma kubectl describe pod → FailedMount
2026-10-29 18:12 El volumen se reasigna a kyrie y monta correctamente pod 1/1 en kyrie
2026-10-29 18:47 Se retira el nodeSelector y el pod vuelve a kobe; falla otra vez FailedMount reproducido
2026-10-29 18:52 multipath -ll muestra mpathb sobre sde dmsetup ls --tree
2026-10-29 18:53 multipathd.socket/service desactivados y mapas vaciados pod 1/1 en kobe

Causa raíz

multipathd (activo por defecto en Ubuntu 24.04) detectaba los LUNs iSCSI que Longhorn expone (IET,VIRTUAL-DISK) y creaba un mapa dm-multipath sobre el dispositivo:

mpathb (360000000000000000e00000000020001) dm-0 IET,VIRTUAL-DISK
`- 6:0:0:1 sde 8:64 active ready running

El dispositivo subyacente quedaba retenido por el mapa (dmesg: multipath: error getting device (-EBUSY)), por lo que fsck/mount lo veían como «in use». El PVC de prueba funcionó porque multipathd no llegó a reclamarlo a tiempo.

Lo que se descartó

Hipótesis Resultado
Mounts/iSCSI sessions huérfanas en kobe o kyrie No había mounts de 8:64 ni sesiones iSCSI activas del volumen
Volumen corrupto e2fsck -fn pasaba; blkid mostraba ext4 válido
Problema de Longhorn o del nodo en general Un PVC nuevo montó bien; el fallo era específico del dispositivo reclamado por multipath

Resolución / Plan de acción

  1. En kobe: multipath -f mpathb, systemctl disable --now multipathd.socket y multipathd.service.
  2. Codificado en k3s/ansible/roles/longhorn-prereqs/ (vaciar mapas + enmascarar multipathd.socket/service) y aplicado a los 3 nodos (PR #159).
  3. Retirado el nodeSelector: kyrie temporal de Uptime Kuma.

Referencias