TPTito Pinardo Gutiérrez
← Volver al rack
English
1U · OKDOKD 4.19 · 3 nodos · 33 operadores Laboratorio

Posición 22 de 25 en el rack · Laboratorio

Unidad 1U · Laboratorio

Clúster OKD (OpenShift)

3/3 nodos · 33/33 operadores

Para practicar OpenShift de verdad: tres nodos de plano de control que también ejecutan cargas, instalados con el Agent-Based Installer sobre VMs creadas por Terraform. Llegar a 3 de 3 nodos listos y 33 de 33 operadores sanos costó una sesión entera de averías, casi todas por ser discos mecánicos.

Por qué
OpenShift es lo que usan muchas empresas encima de Kubernetes. Instalarlo uno mismo enseña lo que el instalador hace por debajo.
Cómo
Las VMs las crea Terraform; el instalador genera una ISO con la configuración de red de cada nodo y el clúster se monta solo a partir de ahí.
El reto
Todo está pensado para SSD. En discos mecánicos, tres veces un tiempo de espera por defecto se quedó corto.
  • 10configuraciones probadas hasta culpar a la ISO
  • 16 → 32 GBde RAM por nodo para el arranque
  • 6,6 sde escritura en etcd, frente a 200 ms
  • 33/33operadores sanos al terminar

Su código, en abierto Versión pública del repositorio: sin IPs ni secretos.

El clúster por dentro

Tres máquinas virtuales que hacen a la vez de plano de control y de trabajo. Elige un recorrido para ver la instalación o una aplicación.

Hermesde visita en la unidad

Pulsa una pieza o elige un recorrido. Si vienes de una habilidad, ya están encendidas las piezas donde la uso.

      La instalación
      1. Mi portátil — Escribo la configuración del clúster.
      2. Configuración del clúster — Con la red de cada nodo.
      3. openshift-install — El instalador la mete en una ISO.
      4. ISO del instalador — Queda lista la imagen de arranque.
      5. VMs creadas con Terraform — Terraform crea las tres VMs.
      6. Orden de arranque — Arrancan desde la ISO.
      7. Nodo 0 (rendezvous) — El nodo 0 coordina.
      8. Registro de imágenes — Los nodos descargan el sistema.
      9. Nodo 1 — Se escribe en el disco del nodo 1.
      10. Nodo 2 — Y en el del nodo 2.
      11. etcd — etcd forma su grupo.
      12. Dirección virtual de la API — La dirección virtual de la API se levanta.
      13. Operadores del clúster — Y los 33 operadores terminan sanos.
      Una ISO que no arrancaba
      1. ISO del instalador — La ISO de la versión más nueva se cuelga al cargar el arranque.
      2. Orden de arranque — Pruebo firmware, buses de CD, tipos de CPU, configuración a mano y por Terraform.
      3. Discos mecánicos — Incluso QEMU puro, sin Proxmox y sin aceleración: falla igual.
      4. Orden de arranque — No es mi servidor: es la ISO.
      5. openshift-install — Cambio a la versión estable anterior.
      6. ISO del instalador — Genero la ISO nueva con la misma configuración.
      7. Nodo 0 (rendezvous) — Y el nodo arranca.
      Abro la aplicación de prueba
      1. Mi portátil — Desde casa abro la aplicación del laboratorio.
      2. DNS de casa — El DNS de casa resuelve su nombre a la dirección virtual de las aplicaciones.
      3. Dirección virtual de las aplicaciones — La entrada del clúster recibe la petición.
      4. Route — La route la manda al servicio.
      5. Aplicación de prueba — Y el panel responde desde el clúster.
      Despliego en el clúster
      1. Mi portátil — Ansible prepara los recursos de la aplicación.
      2. Aplicación de prueba — La aplicación es un panel de servicios.
      3. Dirección virtual de la API — Se envían a la API del clúster.
      4. Operadores del clúster — Los operadores hacen el resto.
      5. Aplicación de prueba — Y la aplicación queda publicada.
      Lo que cuesta un disco mecánico
      1. Discos mecánicos — Los discos tardan en confirmar cada escritura.
      2. etcd — etcd se queja: escrituras de hasta 6,6 segundos.
      3. Sistema inmutable — El cambio de imagen del sistema tarda más de lo que espera systemd.
      4. Nodo 0 (rendezvous) — Un nodo se queda con la imagen vieja.
      5. Operadores del clúster — Y los operadores tardan en ponerse de acuerdo. Con paciencia y timeouts más largos, terminan sanos.
      1. Mi portátil

        Desde aquí se genera todo y se lanza la instalación.

      2. DNS de casa

        Una zona propia para el laboratorio: la API y las aplicaciones del clúster.

        • Technitium DNS
      3. openshift-install

        Genera la ISO del instalador y sigue la instalación desde fuera.

        • OpenShift (OKD)
      4. Registro de imágenes

        De donde los nodos descargan el sistema y los componentes.

      5. Discos mecánicos

        El cuello de botella de toda la instalación.

        • Proxmox VE
      6. Configuración del clúster

        Nombre, redes, direcciones virtuales y la red de cada nodo, en dos ficheros.

        • OpenShift (OKD)
      7. ISO del instalador

        Una imagen de arranque con toda la configuración dentro.

        • OpenShift (OKD)
      8. VMs creadas con Terraform

        Tres VMs con CPU del host, 32 GB de RAM y la ISO como primer arranque.

        • Terraform
        • Proxmox VE
      9. Orden de arranque

        Primero la ISO, luego el disco. Si la ISO sigue la primera al terminar, el nodo vuelve a instalarse.

        • Proxmox VE
      10. Nodo 0 (rendezvous)

        Coordina la instalación de los otros dos y luego se instala él.

        • OpenShift (OKD)
        • Kubernetes / K3s
      11. Nodo 1

        Plano de control y cargas de trabajo.

        • OpenShift (OKD)
        • Kubernetes / K3s
      12. Nodo 2

        Plano de control y cargas de trabajo.

        • OpenShift (OKD)
        • Kubernetes / K3s
      13. Entorno de instalación

        Mientras instala, cada nodo corre desde la ISO con un sistema de ficheros temporal en RAM.

        • OpenShift (OKD)
      14. etcd

        La base de datos del clúster. Muy sensible a lo que tarda el disco en confirmar cada escritura.

        • Kubernetes / K3s
      15. Dirección virtual de la API

        Una dirección que pasa de nodo en nodo: no es una máquina más.

        • OpenShift (OKD)
      16. Operadores del clúster

        Los 33 componentes que forman OpenShift. El clúster está sano cuando todos dicen disponible y no degradado.

        • OpenShift (OKD)
      17. Sistema inmutable

        Cada nodo cambia de imagen del sistema entera al reiniciar. Si el cambio no termina a tiempo, se descarta.

        • OpenShift (OKD)
      18. Dirección virtual de las aplicaciones

        La entrada a todo lo que se publica en el clúster.

        • OpenShift (OKD)
      19. Consola web

        La consola de OpenShift.

        • OpenShift (OKD)
      20. Aplicación de prueba

        Un panel de servicios desplegado en el clúster con Ansible, para comprobar que se puede usar de verdad.

        • Kubernetes / K3s
        • Ansible
      21. Route

        La forma de OpenShift de publicar un servicio por nombre.

        • OpenShift (OKD)

      Lo que uso de mi árbol

      Pulsa una habilidad: se encienden en el mapa las piezas donde la uso y te cuento para qué.

      OpenShift (OKD)
      OKD instalado con el Agent-Based Installer: ISO con la configuración de red, direcciones virtuales para la API y las aplicaciones, operadores y routes.
      Kubernetes / K3s
      Debajo de OpenShift: etcd, kubelet y los recursos de la aplicación de prueba.
      Terraform
      Crea las tres VMs con su CPU, RAM, discos y orden de arranque.
      Ansible
      Despliega la aplicación de prueba en el clúster.
      Proxmox VE
      Las tres VMs del clúster, sobre los discos del servidor.
      Technitium DNS
      Una zona propia del laboratorio en el DNS de casa para la API y las aplicaciones.

      Bitácora de incidencias

      Averías reales. Lee el síntoma, elige la causa que creas y mira cómo se arregló.

      1. #1

        Las VMs no arrancaban la ISO

        14-09-2026 · instalación

        Las VMs se colgaban siempre en el mismo punto al cargar el arranque desde la ISO del instalador.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        Se reproducía con 10 configuraciones distintas, incluido QEMU puro sin Proxmox y sin KVM, mientras que otra ISO pequeña arrancaba sin problema. La ISO de esa versión tenía un fallo en su catálogo de arranque.
        Solución
        Usar la versión estable anterior del instalador, con la misma configuración. Arrancó a la primera con la CPU del host.
        Lección
        Antes de culpar a algo de fuera hay que descartar lo propio, una variable cada vez. Y cuando todo lo propio está descartado, toca cambiar de versión, no seguir probando.
      2. #2

        «No space left on device» en un nodo con disco libre

        14-09-2026 · instalación

        Tras escribir el sistema en los tres discos, la instalación se quedó en silencio. La dirección virtual de la API nunca llegó a levantarse.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        El nodo que coordina sigue en el entorno de la ISO hasta el final, y guarda todo en un sistema de ficheros temporal en RAM de la mitad de la memoria. Con 16 GB, eran 8 GB, y las imágenes descargadas pasaban de 17.
        Solución
        Subir las VMs a 32 GB de RAM con Terraform y reiniciar.
        Lección
        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. #3

        etcd en bucle de reinicios

        14-09-2026 · plano de control

        Un miembro de etcd llevaba más de 37 minutos sin estar sano, y con él el resto del plano de control.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        etcd confirma cada escritura en disco antes de seguir. Con todos los operadores arrancando a la vez sobre discos mecánicos, la espera superaba lo que tolera.
        Solución
        Con el diagnóstico claro, darle una ventana más antes de tratarlo como límite de hardware. Se estabilizó solo y no volvió a reiniciarse.
        Lección
        Saber distinguir «roto» de «lento»: los registros decían exactamente qué tardaba y cuánto. Esperar fue una decisión, no una esperanza.
      4. #4

        Un nodo que no se unía

        14-09-2026 · nodos

        Dos nodos ya estaban listos, pero el tercero no terminaba de unirse: su red no arrancaba y el servicio de Kubernetes fallaba en bucle.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        Al reiniciar, cada nodo pasa a la imagen nueva del sistema. Copiar la configuración tardó unos 5 minutos, y el tiempo máximo de parada de ese servicio era exactamente 5 minutos: se descartó a milisegundos de terminar.
        Solución
        Ampliar ese tiempo a 20 minutos y rehacer el cambio de imagen a mano con el mismo identificador exacto. El nodo se unió.
        Lección
        Tercera vez en un día que un tiempo por defecto pensado para SSD se quedaba corto. Ante algo «colgado» en disco lento, mirar primero los timeouts.

      Contado entero en un artículo:

      Cómo se construyó

      1. Septiembre de 2026

        Preparación

        • Zona DNS propia para el laboratorio y VMs con Terraform.
        • Configuración del clúster con red estática por nodo.
      2. 14-09-2026

        La instalación

        • ISO de la versión nueva descartada tras diez pruebas; la estable anterior arranca.
        • RAM, orden de arranque, etcd lento y un timeout de systemd, resueltos uno a uno.
        • 3/3 nodos listos, 33/33 operadores sanos y consola accesible.
      3. 14-09-2026

        Usarlo

        • Una aplicación de prueba desplegada con Ansible y publicada con una route.

      Decisiones (y por qué)

      • Qué topología

        Compacta: tres nodos que hacen de todo

        Con tres VMs se tiene un plano de control con quórum y sitio para cargas. Más nodos no caben con estos discos.

      • Qué versión

        La estable anterior, no la última

        La última tenía un fallo de arranque en su ISO. Para aprender OpenShift, la versión que funciona vale más que la más nueva.

      • Cómo se crean las VMs

        Con Terraform, como el resto

        Para poder destruir y volver a crear el clúster entero sin pasos manuales, y para que la RAM o el orden de arranque cambien con un commit.

      Lo que aprendí

      • Descartar lo propio, variable a variable, antes de culpar a lo de fuera.
      • En discos lentos, los timeouts por defecto son el primer sospechoso.
      • Distinguir «roto» de «lento» leyendo los registros.

      Lo siguiente

      • Corregir un nodo que quedó degradado tras el arreglo manual de su imagen.
      • Discos SSD para etcd: es lo único que lo arregla de raíz.

      ¿Hablamos?

      Puedo contar cualquiera de estas decisiones en detalle en una entrevista.

      Descargar CV Contactar ← Volver al rack

      Reconstrucción a partir de mi documentación: sin direcciones, dominios ni nombres internos.