Desplegar una aplicación en un clúster de EKS conectado a una base de datos RDS requiere preparar namespaces, secretos, imágenes multiplataforma y servicios de tipo LoadBalancer. Aquí encontrarás el flujo práctico para llevar un proyecto desde Minikube a producción en AWS, con backend en Python, frontend estático y persistencia gestionada fuera del clúster.

Qué prerequisitos necesitas antes de desplegar en EKS

Antes de tocar kubectl, asegúrate de tener la infraestructura mínima lista en AWS. Sin estos componentes, el despliegue falla en los primeros pasos.

• Un clúster de EKS activo dentro de tu cuenta de AWS.
• Una base de datos RDS ya creada, con conectividad hacia los pods del clúster.
• Dos registries en ECR, uno para las imágenes del backend y otro para el frontend.

¿Qué es EKS? Es el servicio gestionado de Kubernetes en AWS. Tú defines los workloads y AWS administra el plano de control del clúster.

Con esto en mano, puedes validar el estado inicial corriendo kubectl get namespaces [01:30]. Si no aparece nada propio, estás en el punto de partida correcto.

Cómo organizar namespaces y conectar RDS con un external name

La separación lógica por namespaces mantiene el clúster ordenado y facilita aplicar políticas distintas a cada capa. Para este proyecto se crean tres: backend, frontend y storage.

Dentro del namespace de storage se crea un Service de tipo ExternalName, que actúa como puente hacia servicios de terceros. En este caso, apunta al endpoint de la RDS:

bash kubectl -n storage create service externalname mysql --external-name=<endpoint-rds>

El ExternalName no enruta tráfico ni hace proxy, simplemente resuelve un nombre DNS interno hacia el host externo. Eso permite que tu backend hable con mysql.storage.svc.cluster.local aunque la base esté fuera del clúster.

Por qué usar un secreto en lugar de variables planas

Las credenciales de base de datos nunca deben vivir en un deployment en texto plano. La buena práctica es crear un Secret en el namespace del backend con el password y el host:

bash kubectl -n backend create secret generic mysql --from-literal=DB_PASSWORD=admin_k8s --from-literal=DB_HOST=<endpoint>

Al hacer describe sobre ese secreto, los valores aparecen codificados en base64, lo que evita que cualquier persona con acceso de lectura los vea de forma directa [04:30].

Cómo inicializar la base de datos con un Job de Kubernetes

Para crear la tabla y poblar los valores iniciales, se usa un objeto de tipo Job. Este Job monta un ConfigMap con el script SQL y consume el Secret para autenticarse contra RDS.

¿Para qué sirve un Job en Kubernetes? Ejecuta una tarea hasta completarla y luego termina. Es ideal para migraciones, seeders o cualquier proceso one-shot.

El flujo de aplicación es directo:

1. kubectl -n backend apply -f config.yaml para registrar el script.
2. kubectl -n backend apply -f initjob.yaml para lanzar el Job.
3. Esperar a que el pod del Job pase a estado Completed [07:45].

Cuando el Job termina, la base ya tiene la tabla y los registros que el API responderá más adelante.

Cómo construir imágenes multiplataforma con buildx para ECR

Si desarrollas en una máquina ARM (como un Mac con chip Apple) pero tu clúster corre en AMD64, las imágenes nativas no son compatibles. La solución es docker buildx, que permite compilar para arquitecturas distintas a la del host.

El script .sh del backend ejecuta tres pasos: build con buildx --platform linux/amd64, tag contra el repositorio de ECR y push final. Antes de correrlo, necesitas autenticarte con el comando de login que ECR muestra en View Push Commands.

Cómo ajustar el deployment para apuntar a tu imagen

En el deployment.yaml del backend hay que actualizar el tag de la imagen (por ejemplo v1), confirmar el puerto 5001, y asegurar que el DB_HOST referencie el secreto mysql. Después aplicas todo con:

bash kubectl -n backend apply -f .

Esto crea el Deployment, el HPA y el Service tipo LoadBalancer, que AWS aprovisiona como un balanceador real en uno a cinco minutos [13:20].

Cómo conectar el frontend al backend desplegado

Una vez que el balanceador del backend devuelve respuesta en /get_my_info, copias esa URL al archivo request.js del frontend, incluyendo el puerto 5001 y el esquema HTTP. Si intentas consumir por el puerto 443 sin TLS configurado, los navegadores bloquean la petición.

Luego compilas la imagen del frontend con su propio script frontendbuild.sh, la subes a su ECR y aplicas los manifiestos:

bash kubectl -n frontend apply -f .

El frontend queda expuesto por otro LoadBalancer en el puerto 80, sirviendo el archivo linktree.html. Al inspeccionar el navegador, las llamadas XHR confirman que el cliente habla con el balanceador del backend, no con el del frontend.

Por qué separar balanceadores entre frontend y backend

Usar un solo LoadBalancer para ambas capas parece más simple, pero rompe la segregación de responsabilidades. Si el frontend recibe un pico de tráfico y comparte balanceador con el API, ambos componentes se saturan al mismo tiempo.

Lo recomendable en producción es:

• Un endpoint dedicado para el frontend.
• Un endpoint independiente para el backend.
• Eventualmente, un Ingress unificado con enmascaramiento por Route 53 y reglas internas que enruten por path.

Otro detalle pendiente: el DB_HOST del secreto apunta directo al endpoint de RDS, cuando lo ideal sería que referencie el ExternalName del namespace storage. Así centralizas el cambio de host en un solo recurso.

¿Qué otras optimizaciones aplicarías para que este clúster esté listo para servir aplicaciones reales? Cuéntame en los comentarios cómo migrarías la URL de la base hacia el ExternalName y qué patrones de Ingress usarías.