Hit #2

Arquitectura de Despliegue

En esta implementación completamente en la nube usamos un único clúster GKE con dos node pools para separar:

• Control: servicios críticos que siempre deben estar activos.
• Cómputo masivo: workers Sobel que escalan según demanda.

Servicio	Node Pool	Rol & Ubicación	Función principal
Master	base (1–2 nodos)	Eureka Server @ GKE (us-central1-a)	Divide la imagen en N partes y publica cada fragmento (bytes + metadata) en la cola “sobel-task”.
Workers Sobel	workers (0–5 nodos)	GKE (us-central1-a, taints “worker”)	Consumen “sobel-task”, aplican el filtro Sobel, suben el fragmento procesado a GCS y publican un mensaje en “sobel-metadata”.
Reconstructor	base (1–2 nodos)	Eureka Client @ GKE (us-central1-a)	Escucha “sobel-metadata”, registra el estado en Redis y, al recibir todos los fragmentos, descarga desde GCS y une la imagen final.
RabbitMQ (sobel-task / sobel-metadata)	base (1–2 nodos)	GKE (us-central1-a)	Cola de tareas: Master → Workers / Cola de estado: Workers → Reconstructor
Redis	base (1–2 nodos)	GKE (us-central1-a)	Guarda el progreso y recuento de fragmentos procesados
GCS Bucket	—	Google Cloud Storage	Almacenamiento duradero de fragmentos y de la imagen final

Decisiones clave

1. Eureka para descubrimiento

   • El Master expone un Eureka Server para que clientes (Reconstructor) descubran dinámicamente su endpoint.
   • El Reconstructor actúa como Eureka Client, facilitando desacoplo y futura replicación horizontal.

2. Doble cola RabbitMQ

   • sobel-task: Master envía fragmentos + metadata a los workers.
   • sobel-metadata: comunica al reconstructor el estado/progreso de cada fragmento para coordinar el ensamblado.

3. Control de estado en Redis

   • El Reconstructor lleva control de cada solicitud. Cuando todos los fragmentos están procesados, inicia la descarga de cada parte desde GCS y ensambla la imagen final.

4. Node pools especializados

   • base (1–2 nodos): servicios permanentes + mensajería + caché.
   • workers (0–5 nodos): procesamiento Sobel bajo demanda (autoscaling).

5. Almacenamiento desacoplado

   • Google Cloud Storage ofrece durabilidad y aisla cargas de I/O del clúster de cómputo.

6. Infraestructura declarativa con Terraform

   • Cluster, node pools y bucket se versionan y reproducen fácilmente.

Este diseño garantiza un flujo claro Master→Workers→Reconstructor, con control de estado en Redis y almacenamiento duradero en GCS, optimizando disponibilidad, escalabilidad y coste en GKE.

Flujo de ejecución para testeo

1. Ingresar al directorio de Terraform:

   cd terraform

2. Agregar credenciales:

   cp path/to/terraform-sa-keys.json .

3. Inicializar Terraform:

   terraform init

4. Planificar la infraestructura:

   terraform plan -out plan.tfplan

5. Aplicar el plan:

   terraform apply "plan.tfplan"

6. Configurar kubectl:

   gcloud container clusters get-credentials gke-cluster

7. Desplegar manifiestos de Kubernetes:

   kubectl apply -f k8s-manifests/

8. Verificar el servicio maestro:

   kubectl get svc master   # Obtener la IP pública del master

9. Consumir la API REST desde Postman o curl:

Endpoint	Método	Parámetros	Respuesta
POST /task/processAndPublish	POST	• Request param: partes (int) • Form-data: image (file)	• id • message • links.statusUrl • links.imageUrl
GET /task/status/{id}	GET	• Path param: id	• id • status
GET /task/images/{id}	GET	• Path param: id	• Binary (imagen procesada)

---

Ejemplo curl

curl  "http://{{IP_ASIGNADA}}:8761/task/processAndPublish?partes=2" \
  --form "image=@/ruta/a/imagen.jpg"

  curl "http://{{IP_ASIGNADA}}:8761/task/status/{id-imagen}"

  curl  "http://{{IP_ASIGNADA}}:8761/task/images/{id-imagen}"