Saltar al contenido principal

Lab 7.4 - Init Containers y Sidecars

Objetivos del Lab​

Al final de este laboratorio, usted será capaz de:

  • Comprender el concepto de Init Container.
  • Crear Pods con Init Containers.
  • Utilizar Init Containers para la preparación del entorno.
  • Comprender el patrón Sidecar.
  • Implementar un patrón Sidecar para logging.

Duración Estimada​

45-60 minutos

Prerrequisitos​

  • kubectl instalado y configurado.
  • Cluster Kubernetes local funcional (minikube o kind).
  • Conocimientos sobre Init Containers y Sidecars (Capítulo 7.4).

Parte 1: Comprender los Init Containers​

Los Init Containers se ejecutan antes que los contenedores principales de un Pod. Son útiles para:

  • Inicializar datos o configuraciones
  • Esperar a que las dependencias estén listas
  • Preparar el entorno antes del inicio de la aplicación

Características:​

  • Se ejecutan secuencialmente (uno tras otro)
  • Todos deben completarse exitosamente antes de que inicien los contenedores principales
  • Tienen acceso a los mismos volúmenes que los contenedores principales

Parte 2: Creación de un Pod con Init Container​

Vamos a crear un Pod con un Init Container que prepara archivos antes del inicio de la aplicación.

Paso 2.1: Crear el Pod con Init Container​

Cree un archivo pod-init-container.yaml:

# pod-init-container.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  volumes:
  - name: shared-data
    emptyDir: {} # Volumen compartido entre Init Container y contenedor principal
  initContainers:
  - name: init-setup
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Init Container: Préparation de l'environnement..."
      echo "Configuration initialisée" > /shared/config.txt
      echo "Données préparées" > /shared/data.txt
      echo "Init Container terminé avec succès"
    volumeMounts:
    - name: shared-data
      mountPath: /shared
  containers:
  - name: app-container
    image: nginx:1.20
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Application: Lecture des fichiers préparés par Init Container"
      cat /shared/config.txt
      cat /shared/data.txt
      echo "Application démarrée"
      nginx -g "daemon off;"
    volumeMounts:
    - name: shared-data
      mountPath: /shared
    ports:
    - containerPort: 80

Explicación:

  • El Init Container prepara archivos en el volumen compartido.
  • El contenedor principal lee estos archivos después de iniciar.

Aplique el Pod:

kubectl apply -f pod-init-container.yaml

Paso 2.2: Verificar la Ejecución​

Verifique el estado del Pod:

kubectl get pods app-with-init

Debería ver el Pod pasar por las fases:

  1. Init:0/1 (Init Container en ejecución)
  2. PodInitializing
  3. Running (contenedor principal iniciado)

Verifique los logs del Init Container:

kubectl logs app-with-init -c init-setup

Verifique los logs del contenedor principal:

kubectl logs app-with-init -c app-container

Debería ver que el contenedor principal ha leído los archivos creados por el Init Container.

Parte 3: Init Container con Espera de Dependencia​

Los Init Containers pueden esperar a que servicios externos estén disponibles.

Paso 3.1: Crear un Pod que Espera un Servicio​

Cree un archivo pod-init-wait.yaml:

# pod-init-wait.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-wait-service
spec:
  initContainers:
  - name: wait-for-service
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Attente que le service soit disponible..."
      until nslookup kubernetes.default.svc.cluster.local; do
        echo "Service non disponible, attente..."
        sleep 2
      done
      echo "Service disponible!"
  containers:
  - name: app-container
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args: ["echo 'Application démarrée après vérification du service' && sleep 3600"]

Aplique el Pod:

kubectl apply -f pod-init-wait.yaml

Verifique los logs del Init Container:

kubectl logs app-wait-service -c wait-for-service

Parte 4: Patrón Sidecar​

Un Sidecar es un contenedor auxiliar que se ejecuta en el mismo Pod que el contenedor principal para proporcionar funcionalidades complementarias (logging, monitoring, proxy, etc.).

Paso 4.1: Crear un Pod con Patrón Sidecar para Logging​

Cree un archivo pod-sidecar-logging.yaml:

# pod-sidecar-logging.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  volumes:
  - name: shared-logs
    emptyDir: {} # Volumen compartido para los logs
  containers:
  - name: app-container
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      counter=0
      while true; do
        echo "[$(date)] Log entry $counter from application" >> /logs/app.log
        counter=$((counter+1))
        sleep 5
      done
    volumeMounts:
    - name: shared-logs
      mountPath: /logs
  - name: log-collector
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Sidecar: Collecte des logs de l'application..."
      while true; do
        if [ -f /logs/app.log ]; then
          echo "=== Nouveaux logs ==="
          tail -n 5 /logs/app.log
        fi
        sleep 10
      done
    volumeMounts:
    - name: shared-logs
      mountPath: /logs
      readOnly: true # El sidecar solo lee los logs

Explicación:

  • El contenedor principal escribe logs en un volumen compartido.
  • El sidecar lee estos logs y los procesa (en este caso, los muestra).

Aplique el Pod:

kubectl apply -f pod-sidecar-logging.yaml

Paso 4.2: Verificar el Patrón Sidecar​

Verifique que ambos contenedores se estén ejecutando:

kubectl get pods app-with-sidecar

Verifique los logs del contenedor principal:

kubectl logs app-with-sidecar -c app-container

Verifique los logs del sidecar:

kubectl logs app-with-sidecar -c log-collector

Debería ver que el sidecar muestra los logs recolectados del contenedor principal.

Parte 5: Sidecar para Monitoring​

Vamos a crear otro ejemplo con un sidecar para monitoring.

Paso 5.1: Crear un Pod con Sidecar de Monitoring​

Cree un archivo pod-sidecar-monitoring.yaml:

# pod-sidecar-monitoring.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-monitored
spec:
  containers:
  - name: app-container
    image: nginx:1.20
    ports:
    - containerPort: 80
  - name: metrics-collector
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Sidecar: Collecte de métriques..."
      while true; do
        # Simuler la collecte de métriques
        echo "[$(date)] Métriques collectées: CPU, Memory, Network"
        sleep 15
      done

Aplique el Pod:

kubectl apply -f pod-sidecar-monitoring.yaml

Verifique los logs del sidecar:

kubectl logs app-monitored -c metrics-collector

Parte 6: Ventajas de los Patrones​

Init Containers:​

  • Separación de responsabilidades: Preparación vs ejecución
  • Orden garantizado: Se ejecutan antes que los contenedores principales
  • Reutilizabilidad: El mismo Init Container para varios Pods

Sidecars:​

  • Cohesión: Los contenedores en el mismo Pod comparten red y almacenamiento
  • Flexibilidad: Añadir funcionalidades sin modificar la aplicación principal
  • Aislamiento: Cada contenedor puede tener sus propios recursos

Parte 7: Limpieza​

Elimine los Pods creados:

kubectl delete pod app-with-init app-wait-service app-with-sidecar app-monitored

Resumen del Lab​

En este laboratorio, usted exploró los Init Containers y el patrón Sidecar. Aprendió a utilizar Init Containers para preparar el entorno antes del inicio de las aplicaciones, a implementar sidecars para logging y monitoring, y a comprender las ventajas de estos patrones para la arquitectura de aplicaciones.

Próximos Pasos​

Este módulo sobre Workloads Avanzados está ahora completo. Puede continuar con el Módulo 8 sobre Ingress y Load Balancing.

Módulo 8: Ingress y Load Balancing

Lab creado el: Diciembre 2024