Kubernetes resuelve problemas reales de escala y resiliencia, pero adoptarlo antes de necesitarlo de verdad suele salir más caro que quedarse sin él. Aprenderlo bien lleva meses, no el fin de semana que promete algún tutorial. Esto es lo esencial: los conceptos básicos, cuándo tiene sentido usarlo, y los patrones de debugging más comunes.

El modelo mental básico

Un contenedor (Docker) empaqueta una aplicación junto con sus dependencias y el sistema base necesario para ejecutarla.

Un Pod es la unidad más pequeña de Kubernetes: normalmente envuelve un único contenedor, comparte red entre los contenedores que agrupa, y es efímero por diseño —muere y se recrea con frecuencia.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

Un Deployment gestiona Pods a escala: le dices "quiero 3 réplicas de mi app corriendo" y Kubernetes se encarga de mantenerlas vivas, recreando cualquiera que muera, y de hacer actualizaciones sin downtime.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Un Service expone esos Pods a la red con una dirección estable, porque las IPs de los Pods son efímeras y cambian constantemente:

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

Con esto, curl http://nginx-svc llega a cualquiera de los tres Pods, balanceado automáticamente.

Cuándo lo necesitas de verdad

No lo uses si: el equipo es pequeño, el tráfico es modesto, la app no necesita auto-escalado, y no hay una persona dedicada a operaciones. El coste de entrada —una persona de DevOps prácticamente a tiempo completo, una curva de aprendizaje de varios meses, complejidad operacional considerable— no se justifica en ese escenario.

Sí tiene sentido si: el tráfico es alto y con picos marcados (una campaña, un evento estacional), necesitas auto-escalado real, hay despliegue multi-región, o el equipo ya es lo bastante grande para sostener la curva de aprendizaje sin que se resienta la velocidad de entrega.

Si no estás seguro, una alternativa razonable a medio camino es un servicio serverless gestionado (AWS Lambda, Google Cloud Run): resuelve buena parte del auto-escalado sin el coste operacional completo de Kubernetes.

Desarrollo local: Minikube

minikube start  # crea un cluster K8s local

kubectl apply -f deployment.yaml

minikube service nginx-svc  # abre la app en el navegador

La ventaja es tener un entorno que se comporta igual que producción, para detectar problemas de despliegue antes de que lleguen ahí.

Patrones de debugging habituales

Un Pod no arranca:

kubectl describe pod nginx-pod
# ImagePullBackOff = la imagen no se encuentra
# CrashLoopBackOff = la app se cae al arrancar

kubectl logs nginx-pod  # ver los logs de la aplicación

El Pod corre pero no responde:

kubectl exec -it nginx-pod -- bash
netstat -tlnp | grep LISTEN  # comprobar que la app escucha en el puerto esperado

El Service no llega al Pod:

kubectl run -it debug --image=busybox -- sh
nslookup nginx-svc
wget http://nginx-svc

Configuración: ConfigMaps y Secrets

Un ConfigMap guarda configuración no sensible:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_URL: "postgres://db:5432/app"
  LOG_LEVEL: "debug"

Un Secret guarda datos sensibles como contraseñas o claves de API:

kubectl create secret generic db-secret \
  --from-literal=password='super-secret'

Los Secrets se almacenan cifrados en etcd, pero conviene reforzar con políticas de red basadas en TLS para el tránsito entre nodos.

StatefulSets: cuando el Pod sí tiene estado

Un Deployment asume que los Pods son intercambiables y sin estado. Un StatefulSet está pensado para lo contrario —bases de datos, cachés con datos persistentes:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  replicas: 3
  volumeClaimTemplates:
  - metadata:
      name: postgres-storage
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

En la práctica, correr una base de datos dentro de Kubernetes es posible pero añade complejidad considerable. Lo más habitual es usar un servicio de base de datos gestionado (como RDS) y reservar Kubernetes para la capa de aplicación.

Auto-escalado horizontal (HPA)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app-deploy
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

En palabras simples: mantén entre 2 y 20 réplicas, y si la CPU supera el 70%, añade más. Un pico de tráfico se absorbe automáticamente escalando, y cuando el tráfico baja, vuelve a reducirse solo.

Observabilidad

kubectl logs deployment/app-deploy
kubectl logs -f deployment/app-deploy  # en tiempo real

Para métricas hace falta Prometheus (que Grafana suele visualizar), y para tracing distribuido entre servicios, algo como Jaeger.

Gestionado vs autogestionado

Un cluster autogestionado da control total pero exige mantener parches de seguridad, escalado de nodos y monitoring por tu cuenta —típicamente el trabajo de una persona de DevOps dedicada. Los servicios gestionados (EKS en AWS, GKE en Google, AKS en Azure) delegan la gestión del control plane al proveedor, aunque el despliegue y monitoring de tu aplicación siguen siendo responsabilidad tuya.

Para una startup pequeña, la recomendación práctica es no tocar Kubernetes hasta que de verdad haga falta. Hasta ese punto, plataformas más simples (Heroku, Google Cloud Run, AWS Fargate) resuelven lo mismo con mucho menos overhead.

Árbol de decisión resumido

1. Equipo menor de 10 personas: sáltatelo, usa Heroku o Docker Compose
2. Tráfico bajo: sáltatelo, es sobreingeniería
3. Tráfico medio-alto: considera un Kubernetes gestionado o Cloud Run
4. Tráfico muy alto: Kubernetes empieza a tener sentido, invierte en una persona de DevOps
5. Despliegue multi-región: aquí Kubernetes aporta automatización operacional real

La mayoría de proyectos nunca llega a ese umbral, y eso está bien: Kubernetes es una herramienta para una escala y complejidad concretas, no un sello de "hacer las cosas bien".

Fuentes:

• Documentación oficial de Kubernetes
• Kubernetes the Hard Way — Kelsey Hightower