Ruta de aprendizaje Kubernetes 3

Exposición Interna de un Microservicio con ClusterIP

Enunciado

Se ha desplegado una base de datos MongoDB como un Deployment llamado db-mongo. Esta base de datos debe ser accesible únicamente para otros Pods dentro del clúster, sin exposición externa.

Asignación

1. Crear un Deployment db-mongo con la imagen mongo:4.4.
2. Crear un Service de tipo ClusterIP llamado db-service que exponga el puerto 27017 de MongoDB.
3. Desplegar un Pod de prueba (por ejemplo, busybox) y verificar la conectividad a la base de datos usando el nombre del Service (db-service) como hostname.

Herramientas

• Docker
• Kubernetes

Requisitos previos

Se utiliza Minikube para simular el cluster K8s en un servidor, en primer lugar lo iniciamos:

Procedimiento y comandos

1. Generación del Deployment
   Se creó el manifiesto YAML del Deployment mediante el siguiente comando:

   kubectl create deployment db-mongo --image=mongo:4.4 --dry-run=client -o yaml > db-mongo-deployment.yaml
   

   

   Luego se aplicó el recurso al clúster:

   kubectl apply -f db-mongo-deployment.yaml
   

2. Creación del Service ClusterIP
   Se expuso el Deployment como un Service de tipo ClusterIP, mapeando el puerto 27017 del contenedor al mismo puerto en el Service:

   kubectl expose deployment db-mongo --type=ClusterIP --port=27017 --target-port=27017 --name=db-service --dry-run=client -o yaml > db-service.yaml
   kubectl apply -f db-service.yaml
   

   

3. Prueba de conectividad interna
   Se lanzó un Pod temporal con la imagen busybox para realizar pruebas:

   kubectl run test-pod --image=busybox --restart=Never -- sleep 3600
   

Desde dentro del Pod, se comprobó el estado de MongoDB usando el nombre del Service como dirección:

kubectl exec -it test-pod -- sh
# nc -zv db-service 27017

La salida confirmó que el puerto está abierto y accesible, validando la correcta comunicación interna mediante ClusterIP.

Acceso Externo a la Aplicación con NodePort

Enunciado

Se requiere que la aplicación frontend-web (del ejercicio anterior) sea accesible desde el navegador local para realizar pruebas rápidas sin necesidad de Ingress.

Asignación

1. Asegurar que el Deployment web-deployment esté en ejecución.
2. Crear un Service de tipo NodePort para este Deployment.
3. Identificar el puerto NodePort asignado (en el rango 30000-32767) y acceder a la aplicación desde el navegador usando la IP de Minikube y ese puerto.

Procedimiento y comandos

1. Verificación del Deployment
   Se confirmó que el Deployment web-deployment (basado en la imagen Apache) estuviera activo:

   kubectl get deployment web-deployment
   kubectl describe deployment web-deployment
   

   

2. Exposición mediante NodePort
   Se creó un Service de tipo NodePort, especificando el puerto del contenedor (en este caso, el puerto 80 de Apache):

   kubectl expose deployment web-deployment --type=NodePort --port=80 --target-port=80 --name=web-service --dry-run=client -o yaml > web-service.yaml
   kubectl apply -f web-service.yaml
   

   

3. Obtención del puerto asignado
   Se listaron los Services para ver el puerto NodePort asignado automáticamente:

   kubectl get svc web-service
   

   

   La salida mostró un puerto en el rango 30000-32767 (por ejemplo, 32123).

4. Acceso desde el navegador
   Se obtuvo la IP de Minikube:

   minikube ip
   

   

   ---

   

Con la IP y el puerto NodePort, se abrió el navegador en http://<ip-minikube>:<nodeport> y se comprobó que la aplicación respondía correctamente.

Enrutamiento Inteligente con Ingress

Enunciado

La empresa desea alojar múltiples aplicaciones bajo el mismo dominio: frontend-web debe ser accesible desde tudominio.com/web y una nueva API desde tudominio.com/api.

Asignación

1. Habilitar el addon de Ingress en Minikube.
2. Crear un segundo Deployment llamado api-deployment con la imagen nginx que sirva un mensaje “API v1”.
3. Crear un Service api-service para este nuevo Deployment.
4. Crear un recurso Ingress que enrute el tráfico de /web al web-service y de /api al api-service.
5. Modificar el archivo /etc/hosts para apuntar tudominio.com a la IP de Minikube y probar el enrutamiento.

Procedimiento y comandos

1. Habilitación del Ingress Controller
   Se verificó si el addon de Ingress estaba activo y, en caso contrario, se habilitó:

   minikube addons list | grep ingress
   minikube addons enable ingress
   

   Se esperó a que el controlador estuviera listo:

   kubectl wait --namespace=ingress-nginx \
     --for=condition=ready pod \
     --selector=app.kubernetes.io/component=controller \
     --timeout=120s
   

   

2. Creación del Deployment y Service para la API
   Se generó el Deployment para la API, editando el YAML para incluir un comando que devuelva el mensaje “API v1”:

   kubectl create deployment api-deployment --image=nginx:latest --dry-run=client -o yaml > api-deployment.yaml
   # Se editó el archivo para agregar el comando: ["/bin/sh", "-c", "echo 'API v1' > /usr/share/nginx/html/index.html && nginx -g 'daemon off;'"]
   kubectl apply -f api-deployment.yaml
   

   

   Luego se creó el Service para la API (tipo ClusterIP, ya que solo será accedido internamente por el Ingress):

   kubectl expose deployment api-deployment --name=api-service --port=80 --target-port=80 --type=ClusterIP --dry-run=client -o yaml > api-service.yaml
   kubectl apply -f api-service.yaml
   

3. Definición del recurso Ingress
   Se creó el archivo ingress.yaml con las reglas de enrutamiento:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: main-ingress
   spec:
     rules:
       - host: tudominio.com
         http:
           paths:
             - path: /web
               pathType: Prefix
               backend:
                 service:
                   name: web-service
                   port:
                     number: 80
             - path: /api
               pathType: Prefix
               backend:
                 service:
                   name: api-service
                   port:
                     number: 80
   

   Se aplicó el recurso:

   kubectl apply -f ingress.yaml
   

   

4. Verificación del Ingress
   Se comprobó que el Ingress se hubiera creado correctamente:

   kubectl get ingress
   

5. Configuración del archivo hosts
   Se obtuvo la IP de Minikube y se agregó la entrada al archivo /etc/hosts (en sistemas Linux/macOS) o C:\Windows\System32\drivers\etc\hosts (en Windows):

   <ip-minikube>   tudominio.com
   

6. Prueba de enrutamiento
   Se realizaron peticiones con curl para validar el enrutamiento:

   curl http://tudominio.com/web
   curl http://tudominio.com/api
   

Las respuestas mostraron el contenido de la aplicación web y el mensaje “API v1” respectivamente, confirmando el correcto funcionamiento del Ingress.

Ejecución de un Proceso por Lote con Jobs

Enunciado

Todos los días a las 3 AM debe ejecutarse un script que limpia la base de datos de logs antiguos. Este proceso debe ejecutarse una sola vez y finalizar correctamente.

Asignación

1. Crear un Job llamado db-cleanup que use la imagen busybox y ejecute el comando echo "Limpiando logs..." && sleep 10.
2. Verificar que el Job cree un Pod, lo ejecute y que el Pod termine en estado Completed.
3. Escalar el Job para que ejecute 5 tareas en paralelo (modificando la propiedad parallelism).

Procedimiento y comandos

1. Creación del Job inicial
   Se generó un Job con un solo Pod:

   kubectl create job db-cleanup --image=busybox -- echo "Limpiando logs..." && sleep 10
   

   Nota: El comando anterior debe ajustarse para que el shell interprete el &&. Para ello, se recomienda usar un YAML o encerrar el comando entre comillas. La forma más limpia es crear un YAML manualmente, pero para simplificar se puede usar:

   kubectl create job db-cleanup --image=busybox -- /bin/sh -c 'echo "Limpiando logs..." && sleep 10'
   

2. Verificación de la ejecución
   Se observó el estado del Job y del Pod:

   kubectl get jobs
   kubectl get pods
   

El Pod pasó a estado Completed tras finalizar el comando, y el Job mostró COMPLETIONS 1/1.

3. Escalado a 5 tareas en paralelo
   Dado que un Job una vez completado no se puede modificar en parallelism, se creó un nuevo Job con la propiedad parallelism: 5 desde el principio. Se preparó un manifiesto YAML como el siguiente:

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: db-cleanup-parallel
   spec:
     parallelism: 5
     template:
       spec:
         containers:
           - name: cleaner
             image: busybox
             command: ["/bin/sh", "-c", "echo 'Limpiando logs...' && sleep 10"]
         restartPolicy: Never
   

   Se aplicó el archivo:

   kubectl apply -f job-parallel.yaml
   

   

   Se comprobó que se lanzaron 5 Pods en paralelo, todos finalizando exitosamente:

   kubectl get pods -l job-name=db-cleanup-parallel
   

   

   La salida mostró 5 Pods en ejecucion y progresivamente en Completed, demostrando la ejecución concurrente.

See also