Saltar a contenido

Fundamentos de Pods y Contenedores

La Diferencia Crucial: Contenedor vs. Pod

  • Contenedor: Es un proceso empaquetado con sus dependencias individuales (utilizando motores como Docker, containerd o CRI-O). Es fundamental recordar que Kubernetes NO despliega ni gestiona contenedores directamente.

  • Pod: Es la unidad mínima desplegable en el clúster. Puedes pensar en el Pod como una "envoltura" o un entorno lógico (similar a una máquina virtual pequeñita) que aloja uno o más contenedores.

Reglas de Oro de un Pod (Anatomía Interna)

Cuando agrupas uno o más contenedores dentro de un mismo Pod, estos quedan fuertemente acoplados y comparten de forma inquebrantable las siguientes características:

  • Efímeros por naturaleza: Los Pods son mortales. Si un Pod muere, o el nodo en el que reside falla, el Pod desaparece por completo. Kubernetes creará uno nuevo (si está respaldado por un controlador), pero este tendrá un nuevo ID y una dirección IP completamente diferente.

  • Red Compartida (Network Namespace): Todos los contenedores dentro de un mismo Pod comparten la misma IP y el mismo espacio de puertos. Esto les otorga un superpoder: pueden comunicarse entre sí de forma inmediata simplemente llamando a localhost.

  • Almacenamiento Compartido (Volúmenes): Aunque los contenedores están aislados a nivel de sistema de archivos de forma predeterminada, pueden montar los mismos volúmenes a nivel de Pod. Por ejemplo, mediante un volumen de tipo emptyDir, un contenedor puede escribir datos y el otro leerlos en tiempo real.

  • Destino Compartido (Co-ubicación): Los contenedores dentro de un mismo Pod siempre se programarán (schedule) en el mismo Nodo físico o virtual. Jamás verás un contenedor de un Pod ejecutándose en el Nodo-1 y otro contenedor del mismo Pod en el Nodo-2.

Patrones Avanzados: Múltiples Contenedores en un Pod

Colocar más de un contenedor dentro de la misma "envoltura" es una práctica avanzada para casos específicos. Se estructura mediante el concepto de Contenedor Principal acompañado de un patrón de soporte:

  • Patrón Sidecar: Un contenedor secundario que ayuda al principal de forma continua (por ejemplo, un proceso que recolecta logs de la aplicación principal y los envía a un servidor centralizado).

  • Patrón InitContainer (Contenedores de Inicialización): Son contenedores que se ejecutan antes de que arranquen los contenedores de la aplicación principal. Tienen dos reglas críticas:

    1. Se ejecutan secuencialmente hasta completarse (deben terminar con éxito con un código 0).

    2. Si un InitContainer falla, Kubernetes reiniciará todo el Pod continuamente hasta que tenga éxito.

Tips de Velocidad y Comandos de Supervivencia (Modo Examen)

En los exámenes oficiales, el tiempo es oro y nunca debes escribir un archivo YAML de un Pod desde cero. Domina estos atajos:

  • Generar la plantilla YAML base sin aplicarla (Tu mejor amigo):

    kubectl run web-app --image=nginx --dry-run=client -o yaml > pod.yaml
    

    A partir de aquí, editas el archivo pod.yaml con tu editor (como vi) para agregar elementos complejos como InitContainers, Volúmenes o variables de entorno.

  • Inspección avanzada (Ver la IP y el Nodo asignado):

    kubectl get pods -o wide
    
  • Solución de problemas rápida (Troubleshooting de Logs):

    kubectl logs <nombre-del-pod>
    

Si el Pod tiene varios contenedores, es obligatorio especificar cuál deseas ver añadiendo la bandera -c:

```Bash
kubectl logs <nombre-del-pod> -c <nombre-del-contenedor>
```
  • Entrada interactiva a un Pod (Troubleshooting en vivo):

    kubectl exec -it <nombre-del-pod> -- sh
    

Pods con bloque de código

[!TIP] Indentar visualmente con vim:

  1. :set shiftwidth=1
  2. Presiona V para entrar en modo visual por líneas.
  3. Selecciona las líneas con j / k (o flechas).
  4. Presiona > para indentar o < para des-indentar

Puedes repetirlo varias veces .

apiVersion: v1
kind: Pod
metadata:
  name: busybox-long-command
spec:
  containers:
  - name: busybox-worker
    image: busybox:1.36
    command: ["sh", "-c"]
    args:
    - |
      echo "Iniciando script largo..."
      mkdir -p /var/log/app
      for i in $(seq 1 5); do
        echo "Procesando iteración número $i" >> /var/log/app/output.log
        sleep 1
      done
      echo "¡Script completado con éxito!"