Orquestación de Contenedores con Kubernetes

1. ¿Por Qué Kubernetes? Escalabilidad y Resiliencia

Si Docker empaqueta una aplicación, **Kubernetes (K8s)** se encarga de que esa aplicación funcione 24/7, escalando automáticamente cuando hay picos de demanda y reiniciándola si falla.

Docker Compose vs. Kubernetes

Docker Compose es para **desarrollo** y entornos de una sola máquina. **Kubernetes** es para **producción** y clústeres de múltiples máquinas (nodos) distribuidos en la nube (AWS, Azure, GCP).

K8s ofrece funcionalidades avanzadas como balanceo de carga automático, auto-reparación y descubrimiento de servicios.

El Concepto de Clúster

Un clúster de Kubernetes es un conjunto de máquinas (Nodos) que trabajan juntas. Se divide en dos componentes principales:

**Master Node (Plano de Control):** El "cerebro". Toma decisiones globales (programación, escalado).
**Worker Nodes (Nodos Trabajadores):** Las "manos". Ejecutan las cargas de trabajo (los contenedores).

2. Objetos Clave: Los Bloques de Construcción de K8s 🧱

Todo lo que se despliega en Kubernetes se define a través de objetos, escritos en archivos de configuración **YAML**.

1. Pod (La Unidad de Ejecución)

Es la unidad más pequeña y más básica que se puede desplegar. Un **Pod** siempre contiene uno o más contenedores que comparten almacenamiento, red y ciclo de vida.

Tu contenedor de ASP.NET Core siempre se ejecuta dentro de un Pod.

2. Deployment (El Gestor de Estado)

Define el estado deseado: cuántas réplicas del Pod quieres y cómo quieres actualizarlas (ej. *rolling update*). Si un Pod muere, el Deployment crea uno nuevo.

3. Service (El Punto de Acceso)

Proporciona una dirección IP y un nombre DNS estable para un conjunto de Pods. Asegura que el tráfico se **balancee** entre todos los Pods saludables del Deployment.

3. Creación de Manifiestos YAML (El Código de Infraestructura) 📝

Los archivos de configuración de Kubernetes son la aplicación más avanzada de tu conocimiento sobre **YAML** (serialización de datos).

Estructura del Manifiesto

Todo manifiesto K8s requiere cuatro campos principales para definir cualquier objeto:

**apiVersion:** Versión de la API de Kubernetes (Ej. `apps/v1`).
**kind:** Tipo de objeto (Ej. `Deployment` o `Service`).
**metadata:** Información del objeto (nombre, etiquetas/labels).
**spec:** Especificación del estado deseado (la clave donde defines el número de réplicas, la imagen Docker, etc.).

Ejemplo Básico de un Deployment

Este código indica a K8s que mantenga siempre **3 réplicas** de tu imagen ASP.NET Core.


apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-backend-deploy
spec:
  replicas: 3 # ¡Escala a tres instancias!
  selector:
    matchLabels:
      app: api-backend
  template:
    metadata:
      labels:
        app: api-backend
    spec:
      containers:
      - name: aspnet-container
        image: tuusuario/aspnetapi:latest # Tu imagen Docker
        ports:
        - containerPort: 80

Práctica Interactiva: Análisis de Escalabilidad 💪

Identifica y corrige el error más común al intentar exponer una aplicación al mundo exterior en Kubernetes.

📝 Desafío de Conexión de Tráfico [K8S_SVC]

Se ha creado un Deployment llamado web-app. Para permitir que el tráfico externo llegue a la aplicación, ¿cuál es el **tipo de objeto** que falta y cuál de las claves de YAML es esencial para conectarlo al Deployment?

✅ Solución: El Objeto Service y la Clave Selector

El objeto que falta es el **Service** (`kind: Service`). Un Deployment solo crea Pods, no los expone de manera estable.

La clave esencial para la conexión es el **selector** dentro de la especificación del Service.


kind: Service
metadata:
  name: web-app-service
spec:
  selector:
    app: web-app # ESTO DEBE COINCIDIR con las labels del Pod en el Deployment
  ports:
  - port: 80
    targetPort: 8080 # Puerto del contenedor
  type: LoadBalancer # Permite tráfico externo

**Conclusión:** El Service usa el `selector` para encontrar los Pods con las etiquetas coincidentes y balancear el tráfico hacia ellos.