ADR-0011 — Nube (fase 1): traslado directo a Kubernetes gestionado

Contexto

La plataforma corre de extremo a extremo sobre un clúster de Kubernetes local. El objetivo es llevarla a un proveedor de nube para demostrar portabilidad y aprender operación de nube, con un presupuesto muy ajustado y preferencia por minimizar el gasto en reposo.

Dos restricciones técnicas condicionan el diseño:

• La base de datos usa capacidades de series temporales (hipertablas, compresión, retención) que el servicio de base de datos gestionada del proveedor no soporta. Sustituirla no sería un traslado directo, sino una reescritura del modelo de datos.
• La capa de streaming y su procesamiento hablan el protocolo de Kafka. Cambiar al servicio de mensajería gestionado obligaría a reescribir todos los agentes de procesamiento.

Por tanto, un traslado directo real mantiene la base de datos y la capa de streaming autohospedadas dentro del clúster.

Decisión

Fase 1: mover el clúster entero a Kubernetes gestionado sin tocar los manifiestos ni el código.

• Clúster de una sola zona, en modo estándar (no automático), para tener control y aprender la operación.
• Grupo de nodos de tipo interrumpible (spot), mucho más barato; las interrupciones se toleran porque la pila se recrea.
• Encendido bajo demanda: el clúster se escala a cero nodos en reposo, conservando el clúster y los discos persistentes, de modo que los datos sobreviven y en reposo solo se paga el almacenamiento.
• Sin balanceador de carga: se accede mediante redirección de puertos. Un balanceador con coste fijo no se justifica para un laboratorio.
• Almacenamiento y registro de imágenes por defecto, reutilizando lo que ya existe, para no cambiar los manifiestos.
• Infraestructura como código para aprovisionar la red, el clúster y el grupo de nodos, con scripts de encendido y apagado.

Consecuencias

Positivas:

• Portabilidad demostrada con esfuerzo mínimo y riesgo bajo: los mismos manifiestos y la misma integración continua.
• Coste acotado y en gran parte apagable; el modelo bajo demanda enseña a operar el ciclo de vida de la infraestructura.
• Base para iterar hacia una arquitectura nativa de nube pieza a pieza.

Negativas o deuda asumida:

• La base de datos y la capa de streaming siguen siendo responsabilidad propia (copias de seguridad, alta disponibilidad): un solo nodo de datos, sin réplica. Aceptable para un laboratorio, no para producción.
• Los nodos interrumpibles pueden desalojarse, lo que puede provocar cortes en los componentes con estado.
• Sin URL pública ni cifrado en tránsito hasta la siguiente fase.

Alternativas descartadas

• Base de datos gestionada en lugar de la propia: no soporta la extensión de series temporales, lo que supondría una reescritura en vez de un traslado directo. Candidata para una fase posterior si se renuncia a esas capacidades.
• Mensajería gestionada en lugar de Kafka: obligaría a reescribir el procesamiento. Fase posterior.
• Modo automático del clúster gestionado: más simple, pero con menos control (y menos aprendizaje de operación) y una facturación que para una carga casi siempre activa puede salir peor.
• Clúster multizona: alta disponibilidad real, pero paga gestión y más nodos; innecesario en un laboratorio.
• Balanceador de carga con IP fija: coste fijo mensual aunque se apaguen los nodos; se pospone a la siguiente fase.