Este artículo de Nubificus relata una experiencia de depuración en un entorno de demostración de MLSysOps, revelando una causa inesperada de fallos en pods: problemas de rendimiento del disco que afectaban a etcd. El objetivo de la demostración era mostrar cómo las políticas basadas en telemetría pueden mover dinámicamente una carga de trabajo de detección de objetos de un Raspberry Pi a un Jetson AGX Orin para mejorar el rendimiento. La infraestructura involucraba Karmada como orquestador, k3s para los clusters Kubernetes y hardware diverso (NUC, Raspberry Pi, Jetson).
El problema surgió con fallos recurrentes y predecibles de los pods de Karmada. Tras una exhaustiva investigación, se descubrió que etcd, el almacén de clave-valor distribuido utilizado por Karmada para persistir su estado, experimentaba timeouts. Esto no se debía a un error en Karmada, sino a la lentitud del almacenamiento subyacente. etcd es extremadamente sensible a la latencia de I/O; su funcionamiento depende de que las operaciones de escritura (fsync) se completen rápidamente para mantener la consistencia y la elección del líder. En este caso, los pods se ejecutaban en máquinas virtuales en un NUC que compartía el almacenamiento del host, lo que provocaba una latencia inconsistente.
La solución implicó optimizar el almacenamiento ZFS en el NUC. Se aplicaron ajustes como deshabilitar la sincronización de escritura (sync=disabled), habilitar la compresión LZ4 (compression=lz4), desactivar el registro del tiempo de acceso (atime=off) y ajustar el tamaño del registro (recordsize=8k). sync=disabled es el ajuste más crítico, ya que permite que las operaciones de escritura se confirmen inmediatamente, reduciendo drásticamente la latencia, aunque con el riesgo de pérdida de datos en caso de fallo de energía. Los otros ajustes optimizan aún más el rendimiento del almacenamiento.
La lección principal es que, al depurar fallos de pods en entornos Kubernetes que utilizan etcd, es crucial investigar el rendimiento del almacenamiento. etcd es sensible a la latencia de I/O, y un almacenamiento lento puede provocar timeouts, fallos en la elección del líder y, en última instancia, la inestabilidad del clúster. El artículo recomienda monitorear métricas de etcd como etcd_disk_wal_fsync_duration_seconds y etcd_disk_backend_commit_duration_seconds para detectar problemas de rendimiento del disco.