Instalar OKD con el Agent-Based Installer sobre discos mecánicos: los cuatro muros
Montar un clúster OKD compacto de tres nodos en Proxmox, con discos mecánicos, llevó una sesión entera. Cada bloqueo parecía un fallo grave y casi todos eran lo mismo: algo pensado para SSD que se quedaba corto.
- OpenShift (OKD)
- Kubernetes / K3s
- Proxmox VE
1 · La ISO que no arrancaba
Las VMs se colgaban siempre en el mismo punto al cargar el arranque desde la ISO del instalador más reciente. Probé SeaBIOS y OVMF, cuatro buses de CD distintos, arranque directo de kernel, tipos de CPU, VMs creadas por Terraform y a mano… e incluso QEMU puro, sin Proxmox y sin KVM. Falló igual en las diez configuraciones, mientras una ISO pequeña de control arrancaba sin problemas.
Conclusión: la ISO de esa versión tenía un fallo en su arranque. Con la versión estable anterior y la misma configuración, arrancó a la primera (con CPU del host: con el modelo genérico de QEMU daba un kernel panic).
2 · «No space left on device» con el disco vacío
Tras escribir el sistema en los tres discos, la instalación se quedó en silencio y la dirección virtual de la API nunca se levantó. El servicio que la gestiona estaba en bucle de reinicios con un «No space left on device».
El nodo que coordina sigue arrancado desde la ISO hasta el final y guarda todo en un sistema de ficheros temporal en RAM, del tamaño de la mitad de la memoria. Con 16 GB eran unos 8, y las imágenes descargadas pasaban de 17.
Arreglo: subir las VMs a 32 GB de RAM desde Terraform. Los requisitos mínimos son para el funcionamiento normal, no para el pico de la instalación; y en discos lentos el pico dura más.
3 · etcd, más de 37 minutos sin quórum
Un miembro de etcd seguía sin estar sano y el resto del plano de control esperaba. Los registros del contenedor de etcd lo decían claro: escrituras que tardaban hasta 6,6 segundos, frente a los 200 ms que espera.
No estaba colgado: estaba lento, con todos los operadores arrancando a la vez sobre discos mecánicos. Con el diagnóstico claro, le di una ventana más antes de tratarlo como un límite de hardware. Se estabilizó solo y no volvió a reiniciarse.
4 · Un nodo que no se unía
Dos nodos listos y el tercero sin unirse: su red no arrancaba y el kubelet fallaba en bucle. rpm-ostree status dijo que seguía en la imagen antigua: el cambio a la nueva se había descartado por un timeout.
Copiar la configuración tardó unos 5 minutos en el disco lento, y el tiempo máximo de parada de ese servicio era exactamente 5 minutos: systemd lo mató a milisegundos de terminar.
# /etc/systemd/system/ostree-finalize-staged.service.d/timeout.conf
[Service]
TimeoutStopSec=20min
Resultado
Con el timeout ampliado y el cambio de imagen rehecho a mano con el mismo identificador exacto, el nodo se unió: 3 de 3 nodos listos, 33 de 33 operadores sanos y la consola accesible. Después, una aplicación de prueba desplegada con Ansible y publicada con una route.