Desplegar una aplicación en Kubernetes local exige traducir lo que ya conoces de Docker Compose a manifiestos YAML con deployments y services. Aquí verás cómo orquestar un frontend en nginx y un backend en Flask dentro de Minikube, resolviendo el detalle clave: exponer ambos contenedores al exterior sin romper la comunicación entre capas.

¿Cómo se estructura la aplicación de prueba antes de Kubernetes?

El proyecto, heredado del curso de Docker avanzado, tiene dos contenedores muy bien definidos. Uno hace la lógica, el otro pinta la interfaz.

• Backend en Python: un archivo .py con Flask, Flask-CORS y Waitress que expone una ruta get_my_info, devuelve un JSON y escucha en el puerto 5001 [03:00].
• Frontend en nginx: un Dockerfile mínimo que copia la carpeta sitio a usr/share/nginx/html y sirve un HTML estilo Linktree [04:12].
• Consumo cruzado: el archivo request.js hace un fetch GET a localhost:5001 y reemplaza enlaces como www.facebook.com con el resultado del JSON [04:45].

Con Docker Compose basta un docker compose build seguido de docker compose up para levantar ambos contenedores en los puertos 8080 y 5001. La pregunta interesante viene después: ¿cómo replicas esto solo con Kubernetes?

¿Por qué docker-compose ya no funciona en versiones nuevas? Porque Compose dejó de ser un binario independiente y pasó a ser un subcomando de Docker. Ahora se ejecuta como docker compose build, sin guion.

¿Qué recursos de Kubernetes necesitas para un frontend y un backend?

La carpeta K8s del proyecto contiene dos subcarpetas, una por componente, y cada una incluye dos archivos: un deployment y un service. Esa es la mínima expresión funcional.

¿Qué hace cada deployment?

El deployment del backend define un label app: backend y expone el contenedor en el puerto 5001, exactamente el mismo puerto donde Flask escucha tráfico. El del frontend mantiene la misma estructura, pero ajusta nombre, imagen y deja el puerto en 80, que es el estándar HTTP [10:30].

Usar labels claros como backend o frontend en lugar de genéricos como nginx o hello te ayuda a filtrar pods rápido cuando el clúster crece.

¿Qué tipo de servicio usar al inicio?

La primera versión utiliza NodePort, un tipo de service que abre un puerto en cada nodo del clúster y lo hace accesible desde fuera. Apunta el puerto del nodo al puerto del contenedor: 5001 para el backend y 80 para el frontend [11:45].

¿Qué es un NodePort en Kubernetes? Es un servicio que expone un puerto fijo en cada nodo del clúster hacia el exterior, redirigiendo el tráfico al pod correspondiente. Sirve para pruebas locales, pero limita la flexibilidad cuando necesitas exponer múltiples servicios.

¿Cómo aplicar manifiestos por carpeta en kubectl?

En lugar de aplicar archivo por archivo, puedes pasarle a kubectl una carpeta completa y dejar que procese todos los YAML que encuentre.

bash kubectl apply -f k8s/backend kubectl apply -f k8s/frontend

La salida confirma que se crearon dos recursos por carpeta: un deployment y un service [13:20]. Después validas con kubectl get pods y kubectl get services que todo esté corriendo.

Minikube ofrece un atajo para abrir un túnel hacia un servicio puntual: minikube service frontend-service. Eso te da una URL local lista para usar en el navegador.

¿Por qué falla la conexión del frontend al backend con NodePort?

Al abrir el frontend con la URL que generó Minikube, la página carga, pero la consola del navegador muestra un error claro: connection refused al hacer fetch a localhost:5001 [16:50]. El frontend está expuesto, el backend no.

Aquí aparece la limitación: minikube service abre un túnel para un solo servicio a la vez. Tendrías que abrir otra terminal y tunelar el backend por separado, o cambiar de estrategia.

¿Cuándo conviene migrar de NodePort a LoadBalancer?

La solución elegante es cambiar el tipo de ambos services de NodePort a LoadBalancer. Editas el campo type en los dos archivos YAML y vuelves a aplicar:

bash kubectl apply -f k8s/frontend kubectl apply -f k8s/backend

Kubernetes responde con configured para los services que cambiaron y unchanged para los deployments que no tocaste [18:40]. Esa diferencia es útil para confirmar que solo se aplicaron los cambios reales.

¿Cómo expongo un LoadBalancer en Minikube? Ejecuta minikube tunnel en una terminal aparte. El comando pide contraseña, no devuelve output y queda en espera, abriendo una IP externa simulada para todos los servicios LoadBalancer del clúster.

Con el túnel activo, abres localhost:80, navegas a linktree.html y el frontend ya consume el backend sin errores. La petición get_my_info responde el JSON completo y los enlaces de Facebook, Instagram y X se renderizan correctamente.

¿Cómo hacer que Minikube use tus imágenes locales de Docker?

Un detalle silencioso pero crítico: el clúster solo encuentra tus imágenes locales si está configurado con el driver correcto.

• Inicia Minikube con minikube start --driver=docker para reiniciar el clúster apuntando al daemon de Docker [21:30].
• Ejecuta minikube docker-env para que la terminal use el contexto de Docker dentro de Minikube.
• Valida con minikube ssh y luego docker ps que ves los pods de frontend, backend y core DNS corriendo como contenedores reales.

Con docker images confirmas que el repositorio local incluye las imágenes de frontend y backend que vas a referenciar desde los manifiestos. Si trabajas en otro sistema operativo, el driver puede cambiar a Hyper-V, KVM o QEMU, así que revisa el markdown de recursos.

El reto que te dejo: conecta la base de datos que desplegaste antes (Postgres o MySQL) a este backend para que el frontend muestre datos reales. ¿Qué tipo de servicio usarías para la base de datos y por qué? Cuéntamelo en los comentarios.