Ruta de aprendizaje Kubernetes 1

Despliegue de una Aplicación Legacy en un Pod

Enunciado

Tu empresa está migrando una aplicación monolítica legacy llamada “inventario-app” a Kubernetes. El equipo de desarrollo te ha proporcionado la imagen inventario-api:v1.

Tu tarea es desplegar el primer pod de prueba.

Asignación:

1. Crea un Pod llamado inventario-pod usando la imagen nginx:alpine simulando la app legacy.
2. El Pod debe tener la etiqueta app: inventario.
3. Una vez que el Pod esté corriendo, ejecuta un comando dentro del contenedor para crear un archivo llamado /usr/share/nginx/html/inventario.html con el contenido “Inventario API - v1”.
4. Expón el puerto 80 del Pod usando port-forward y verifica desde tu navegador o con curl que el contenido se muestra correctamente.

Herramientas

• Docker
• Kubernetes

Requisitos previos

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

Ejecución

1. Crear el Pod con la etiqueta requerida

Generamos el manifiesto YAML del Pod con el comando kubectl run en modo dry-run:

kubectl run inventario-pod --image=nginx:alpine --dry-run=client -o=yaml > inventario-pod.yaml

Editamos el archivo inventario-pod.yaml para añadir la etiqueta app: inventario:

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: inventario-pod
    app: inventario
  name: inventario-pod
spec:
  containers:
  - image: nginx:alpine
    name: inventario-pod
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

Aplicamos el manifiesto:

kubectl apply -f inventario-pod.yaml

Verificamos que el Pod esté corriendo:

kubectl get pods -o wide
kubectl get all --selector app=inventario

2. Crear el archivo dentro del contenedor

Accedemos al contenedor del Pod:

kubectl exec -it inventario-pod -- /bin/sh

Dentro del contenedor, creamos el archivo:

echo "Inventario API - v1" > /usr/share/nginx/html/inventario.html
exit

3. Exponer el puerto y verificar

Realizamos un port‑forward para acceder al servicio desde el host:

kubectl port-forward pod/inventario-pod 9090:80

Abrimos otra terminal y comprobamos con curl:

curl http://localhost:9090/inventario.html

Vemos el mensaje: Inventario API - v1

Aislamiento de Entornos con Namespaces

Contexto:
Para organizar mejor los recursos, la política de la empresa dicta que cada equipo debe tener su propio namespace. El equipo de desarrollo (Dev) y el de calidad (QA) necesitan espacios separados.

Asignación:

1. Crea dos namespaces: dev y qa.
2. En el namespace dev, despliega un Pod llamado app-dev con la imagen nginx.
3. En el namespace qa, despliega un Pod llamado app-qa con la imagen nginx.
4. Verifica que los Pods están en sus respectivos namespaces y que no puedes ver los Pods de qa desde el contexto de dev sin especificar el namespace.
5. Cambia el contexto por defecto de kubectl para que siempre use el namespace dev y prueba que kubectl get pods solo muestra los de ese namespace.

Respuestas

1. Crear los namespaces

kubectl create ns dev
kubectl create ns qa

2. Desplegar Pods en cada namespace

Generamos los YAML para cada Pod (opcional, también podemos desplegar directamente con kubectl run):

kubectl run app-dev --image=nginx -n dev --dry-run=client -o=yaml > app-dev.yaml
kubectl run app-qa --image=nginx -n qa --dry-run=client -o=yaml > app-qa.yaml

Aplicamos los manifiestos:

kubectl apply -f app-dev.yaml
kubectl apply -f app-qa.yaml

Verificamos que los Pods estén en sus respectivos namespaces:

kubectl get pods -n dev
kubectl get pods -n qa

3. Comprobar el aislamiento

Desde el contexto actual (sin especificar namespace), kubectl get pods no mostrará ninguno de los Pods porque están en namespaces diferentes.

kubectl get pods
# (No mostrará ningún Pod)

Si intentamos ver los Pods del namespace qa desde el contexto de dev (sin cambiar de contexto), debemos especificar el namespace:

kubectl get pods -n qa
# Muestra app-qa

4. Cambiar el contexto por defecto

Para que kubectl siempre use el namespace dev por defecto:

kubectl config set-context --current --namespace=dev

Ahora kubectl get pods mostrará solo los Pods del namespace dev:

kubectl get pods
# Muestra app-dev

Solución de Problemas de un Pod Fallido

Contexto:
El equipo de desarrollo te reporta que el nuevo microservicio “procesador-pagos” no se está iniciando. El pod está en estado CrashLoopBackOff.

Asignación:

1. Crea un Pod llamado procesador-pagos con la imagen busybox que ejecute el comando sleep 10 (lo que hará que termine y falle).
2. Investiga el estado del Pod y encuentra la razón del fallo.
3. Corrige el problema modificando el comando del Pod para que ejecute sleep 3600 (o un comando que no termine) y vuelve a desplegarlo.
4. Utiliza kubectl logs y kubectl describe para documentar el proceso de troubleshooting.

Respuesta

1. Crear un Deployment que falla

Creamos un Deployment que ejecuta el comando sleep 10, el cual finaliza y provoca el reinicio del contenedor:

kubectl create deployment procesador-pagos --image=busybox -- /bin/sh -c "sleep 10"

Observamos que el Pod entra en estado CrashLoopBackOff:

kubectl get pods

2. Investigar la causa del fallo

Obtenemos los logs del Pod para ver qué ocurrió:

kubectl logs procesador-pagos-67db5bd9-kdkds
# (No mostrará errores, pero el comando sleep 10 termina correctamente)

Con kubectl describe podemos ver el historial de reinicios y eventos:

kubectl describe pod procesador-pagos-67db5bd9-kdkds

En la salida vemos que el Pod se ha reiniciado varias veces y que el motivo del fallo es que el contenedor finalizó correctamente, pero al no tener un proceso que se ejecute indefinidamente, Kubernetes lo reinicia (política de reinicio por defecto).

3. Corregir el problema

Editamos el Deployment para cambiar el comando por sleep 3600:

KUBE_EDITOR="nano" kubectl edit deployment procesador-pagos

Modificamos la sección spec.template.spec.containers[0].command para que sea:

command:
  - /bin/sh
  - -c
  - "sleep 3600"

Guardamos y salimos. El Deployment actualizará el Pod automáticamente.

Verificamos que el nuevo Pod esté en estado Running:

kubectl get pods
kubectl describe pod/procesador-pagos-79c9cd6845-mb4c4

Ahora el Pod permanece en ejecución y no se reinicia.

See also