Saltar a contenido

Errores de I/O de Longhorn en kyrie — 2026-09-24

Reinicios masivos de pods concentrados en el nodo kyrie, con origen en errores de I/O de los volúmenes iSCSI de Longhorn montados en ese nodo.

Estado

Campo Valor
Primera aparición 2026-09-13 (540 errores de I/O)
Estado Resuelto (remediación en PR fix/longhorn-kyrie-io)
Resuelto 2026-09-24
Severidad Alta
Servicios afectados Longhorn, Loki, Prometheus (+ daemonsets de kyrie)

Síntomas

  • Reinicios masivos de pods en muchos namespaces, concentrados en el nodo kyrie.
  • Errores de disco en dmesg de kyrie sobre los dispositivos sdb..sde.
  • Daemonsets de kyrie con reinicios crónicos (vs 1–2 en kobe/kawhi): speaker 915, engine-image 893, longhorn-csi-plugin 657, node-exporter 660, kured 90.

Cronología (2026-09-24, hora local CEST)

Hora Evento Evidencia
14:19:20 Condiciones de kyrie transicionan (Memory/Disk/PID pressure → Ready 14:19:57). kubectl describe node kyrie
14:21–14:23 Errores de I/O en sdb/sdc/sdd/sde (volúmenes iSCSI Longhorn), errores de journal EXT4, umounts forzados. dmesg -T en kyrie
14:22:17 Disco Longhorn de kyrie vuelve a Ready. kubectl get nodes.longhorn.io kyrie
14:27–14:29 CrashLoopBackOff masivo en kyrie (todos los namespaces). journalctl -u k3s-agent

Causa raíz

Errores de I/O en la ruta de datos iSCSI de Longhorn en kyrie:

pod (Loki/Prometheus, kyrie)
   └─▶ initiator iSCSI (kyrie)
         └─▶ target iSCSI 10.42.2.246:3260  (engine/instance-manager local en kyrie)
               └─▶ réplicas: kyrie (local) + kawhi/kobe (remoto, vía flannel)

Los dispositivos sdb..sde son los volúmenes iSCSI montados por CSI (lsblk con TRAN=iscsi). Cuando cae el target iSCSI (engine/instance-manager) o la sesión, el filesystem montado recibe errores de I/O, se fuerza el umount y los pods que usan esos volúmenes caen en cascada.

Evidencia: 

[Thu Sep 24 14:21:31] Buffer I/O error on dev sdb ... lost sync page write
[Thu Sep 24 14:22:00] I/O error, dev sdc, sector ... op 0x0:(READ)
[Thu Sep 24 14:23:31] I/O error, dev sde/sdd ... EXT4-fs error: ext4_put_super
- Recuento por día: 540 errores el 13-sep, 21 el 24-sep (no es aislado). - engine-image en kyrie: 893 reinicios, en ráfagas (772 el 21-sep, estable 3 días, +110 el 24-sep). - Volúmenes afectados (ambos en kyrie): storage-loki-0 (Loki, 10G) y la DB de Prometheus (20G).

Causa raíz confirmada (2026-09-24): kyrie (y kawhi) están subdimensionados (2 vCPU / 4 GB) para la carga de I/O que alojan. kyrie concentra los volúmenes pesados (Prometheus 20 GB + Loki 10 GB), mientras kobe (4 vCPU / 10 GB) y kawhi solo llevan volúmenes pequeños.

  • El pod engine-image-ei-* de kyrie acumula 893 reinicios con exit code 137 (SIGKILL): su liveness probe es /data/longhorn version --client-only con timeout 4s / period 5s (setting Longhorn engine-image-pod-liveness-probe-timeout). Bajo contención de I/O el comando excede los 4s → 3 fallos → SIGKILL.
  • El target iSCSI (engine en el instance-manager) cae con la misma contención de recursos, provocando los errores de I/O en los volúmenes montados y la cascada de reinicios.
  • La hipótesis de red flannel queda descartada: los reinicios son SIGKILL (proceso matado por liveness), no pérdida de red.

Lo que se descartó

Hipótesis Resultado
Reinicio de nodo No: kyrie up 13 días (boot 11-sep 06:13)
Reinicio de kubelet/k3s/containerd No: NRestarts=0, process_start_time_seconds desde el 11-sep
OOM No: 0 kills, ~2 GB libres, load 0.74 (2 vCPU)
kured a las 14:19 No: ventana de kured es 06:00–08:00

Resolución / Plan de acción

  • [x] Revisar kyrie tras el incidente: réplicas Longhorn (running, RW), volúmenes healthy, Loki-0 y Prometheus-0 recuperados (0 reinicios), sin reinicios en la última hora (verificado 2026-09-24 19:00 CEST).
  • [x] Redimensionar workers: kyrie y kawhi de 2 vCPU / 4 GB → 4 vCPU / 6 GB (terraform/variables.tf). lebron bajado de 12 → 10 GB para encajar en los 32 GB del host (lebron 10 + kobe 10 + kyrie 6 + kawhi 6 = 32 GB).
  • [x] Subir el timeout del liveness del engine-image de Longhorn: setting engine-image-pod-liveness-probe-timeout 4s → 10s (y period 5s → 10s), vía defaultSettings en clusters/luka/apps/longhorn/application.yaml.
  • [x] Instrumentar alertas (Grafana Alerting, GrafanaAlertRuleGroup longhorn-io): filesystem read-only (node_filesystem_readonly) y reinicios de pods por nodo (kube_pod_container_status_restarts_total).

Hipótesis (resueltas)

  1. Red flannel inestable en kyrie — descartada: los reinicios son SIGKILL (exit 137, liveness probe), no pérdida de red.
  2. kyrie subdimensionado — confirmada: 2 vCPU insuficientes para la carga de I/O; el liveness del engine-image (4s) excedía el timeout y mataba el pod en cascada.

Referencias

Lecciones aprendidas

  • El monitoring es víctima del incidente: Prometheus corre en kyrie sobre un volumen Longhorn, así que durante la cascada de I/O estuvo caído y no pudo registrar datos ni disparar alertas en tiempo real. Las alertas de reinicios disparan tras la recuperación (el contador salta y increase lo detecta).
  • Señal de I/O limitada: node-exporter no expone contadores de errores de disco (node_disk_*_errors_total) y no ve los filesystems de los volúmenes Longhorn (namespaces de pod). La caída de un volumen se detecta por la cascada de reinicios, no por el read-only del host.