Docker y Kubernetes: Guía de alguien que entiende uno y finge entender el otro

Febrero 2025. Mientras todos hablan de IA y el futuro del desarrollo, yo sigo aquí, peleando con un deployment de Kubernetes que no quiere funcionar. "Es fácil cuando le agarras la mano", me dijeron. Mentirosos.

Pero empecemos por el principio. Docker. Docker sí me gusta. Docker tiene sentido. Docker no me hace querer tirar la laptop por la ventana (la mayoría del tiempo).

Docker: El amigo que sí cumple lo que promete

Mi historia con Docker empezó en 2019, justo cuando me mudé a Cuenca. Un proyecto necesitaba PHP 7.4, otro PHP 8.0, y mi máquina local era un desastre de versiones. "Prueba Docker", me dijo un colega. Mejor consejo de mi vida.

La primera vez que escribí docker-compose up y todo funcionó, casi lloro. No más "en mi máquina funciona". No más configurar Apache y MySQL por enésima vez. Solo un archivo YAML y listo.

*Se eliminaron las comillas simples para evitar problemas de compatibilidad

# Mi docker-compose.yml de todos los días
version: "3.8"
services:
  web:
    image: php:8.2-apache
    volumes:
      - ./src:/var/www/html
    ports:
      - "8080:80"
  
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: password123  # Sí, uso passwords básicos en local
      MYSQL_DATABASE: mi_proyecto
    volumes:
      - db_data:/var/lib/mysql

volumes:
  db_data:

Simple, limpio, funcional. En 5 minutos tienes un ambiente completo. Docker es como ese amigo confiable que siempre llega a tiempo y nunca te falla.

Los comandos de Docker que realmente uso

Después de años, estos son los únicos comandos que necesito el 95% del tiempo:

# Los básicos que uso cada día
docker-compose up -d    # Levantar todo en background
docker-compose down     # Apagar todo
docker ps              # Ver qué está corriendo
docker logs [container] # Cuando algo explota

# Los que uso cuando algo sale mal
docker system prune -a  # Borrar todo y empezar de cero
docker-compose build --no-cache  # Rebuild sin cache cuando todo falla

# El que uso cuando el cliente quiere ver el proyecto
docker-compose up      # Sin -d para ver los logs en vivo y parecer hacker

¿Hay más comandos? Sí. ¿Los necesito? No. ¿Los busco en Google cada vez que los necesito? Absolutamente.

Kubernetes: Donde empezó mi sufrimiento

Todo iba bien con Docker hasta que llegó ese cliente. "Necesitamos escalar", dijo. "Kubernetes es el estándar", insistió. "Es como Docker pero mejor", mintió.

Hermano, Kubernetes NO es como Docker. Es como comparar manejar un auto con pilotear un Boeing 747. Sí, ambos te llevan a lugares, pero uno requiere 3 años de entrenamiento y una licencia especial.

Mi primer archivo de Kubernetes:

# deployment.yaml - 50 líneas para hacer lo mismo que 10 en Docker Compose
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mi-app
  labels:
    app: mi-app
spec:
  replicas: 3  # "Para escalar", dijeron
  selector:
    matchLabels:
      app: mi-app
  template:
    metadata:
      labels:
        app: mi-app
    spec:
      containers:
      - name: web
        image: mi-imagen:latest
        ports:
        - containerPort: 80
        # Y aquí siguen 30 líneas más de configuración
        # que copié de StackOverflow sin entender

Tres días. TRES DÍAS me tomó hacer que ese deployment funcionara. Y cuando finalmente funcionó, no tenía idea de por qué.

Lo que nadie te dice de Kubernetes

1. Todo tiene 5 nombres diferentes
Pod, deployment, service, ingress, configmap, secret... Y todos se relacionan entre sí de formas que solo tienen sentido si dibujás un diagrama. Que también vas a perder.

2. Los errores son crípticos
"CrashLoopBackOff". ¿Qué significa? Nadie sabe. Puede ser cualquier cosa desde un typo hasta que Kubernetes decidió odiarte personalmente.

3. kubectl es tu nuevo Google
Vas a escribir kubectl get pods más veces que console.log. Y cada vez vas a rezar para que todos estén en "Running".

# Mi historial de comandos en un día normal con K8s
kubectl get pods
kubectl describe pod mi-pod-roto
kubectl logs mi-pod-roto
kubectl get pods  # Otra vez, por si cambió algo
kubectl delete pod mi-pod-roto
kubectl get pods  # A ver si revivió
kubectl apply -f deployment.yaml
kubectl get pods  # Por favor funciona
kubectl get events  # ¿Por qué no funciona?
docker-compose up  # Me rindo

Cuando Kubernetes tiene sentido (spoiler: casi nunca para mí)

Seamos honestos. ¿Necesitas Kubernetes para tu blog? No. ¿Para tu tienda online con 100 visitas al día? Tampoco. ¿Para el sistema ERP de tu empresa mediana? Probablemente no.

Kubernetes tiene sentido cuando:

• Tienes miles de usuarios concurrentes (no tus 50 amigos)
• Necesitas auto-scaling real (no solo parecer cool)
• Tienes un equipo dedicado de DevOps (no tú googleando a las 3 AM)
• El downtime te cuesta miles de dólares por minuto

Para todo lo demás, existe Docker Compose. O mejor aún, un VPS con Apache. Sí, lo dije.

Mi setup actual: Docker en desarrollo, rezar en producción

Después de años de prueba y error (énfasis en error), este es mi approach:

Desarrollo local: Docker Compose para todo. Un archivo, todos los servicios, cero problemas.

Staging: Docker Compose en un VPS. Sí, no es "best practice". No, no me importa. Funciona.

Producción: Depende del cliente. Si insisten en Kubernetes, cobro el triple y subcontrato a alguien que sepa. Si me dejan elegir, Docker Swarm o simplemente Docker Compose con un buen backup strategy.

Herramientas que hacen la vida menos miserable

Portainer: UI para Docker. Porque a veces necesitas ver qué está pasando sin escribir comandos.

Lens: Como Portainer pero para Kubernetes. Sin esto, K8s sería completamente inmanejable para mí.

Docker Desktop: Sí, uso GUI. Júzguenme. Pero funciona y puedo ver los logs con colorcitos.

ChatGPT: Mi consultor personal de Kubernetes. "¿Por qué mi pod está en ImagePullBackOff?" ChatGPT siempre sabe.

Los errores que cometí para que no los cometas

Error 1: Usar :latest en producción
Un día todo funcionaba. Al siguiente, mi app explotó porque :latest ahora era una versión completamente diferente. Siempre usa tags específicos.

Error 2: No entender los límites de recursos
Mi pod pedía 4GB de RAM. El nodo tenía 2GB. Kubernetes no me dijo nada, solo... no funcionaba. Revisa tus recursos.

Error 3: Pensar que más replicas = más rápido
Puse 10 replicas de mi app PHP. La base de datos murió por las conexiones. No todo se soluciona con más replicas.

Error 4: No hacer backups de los volumes
Perdí una base de datos entera porque asumí que Docker guardaba todo mágicamente. Spoiler: no lo hace.

La verdad incómoda sobre DevOps en 2025

Voy a decir algo controversial: el 80% de los proyectos no necesitan Kubernetes. Es como comprar un Ferrari para ir al supermercado. Sí, es cool. Sí, puedes presumir. Pero al final, gastas más en mantenimiento que lo que vale el auto.

Docker, por otro lado, es como un Toyota Corolla. No es sexy, pero te lleva a donde necesitas, es confiable, y cualquier mecánico lo puede arreglar.

El mes pasado, un cliente me pidió migrar su aplicación de Docker Compose a Kubernetes. "¿Por qué?", pregunté. "Porque es más profesional", respondió. Le cobré 5000 dólares para hacer exactamente lo mismo pero más complicado. Ahora paga 300 dólares más al mes en infraestructura y necesita un DevOps part-time para mantenerlo.

¿Funcionaba mejor antes? Sí. ¿Es más "enterprise" ahora? También sí. ¿Vale la pena? Tú decides.

Mis consejos no solicitados

Si estás empezando con containerización:

1. Aprende Docker primero. En serio, no te saltes a Kubernetes.

2. Docker Compose es suficiente para el 90% de los proyectos.

3. Si no entiendes por qué necesitas Kubernetes, no lo necesitas.

4. Los tutoriales de "Kubernetes en 10 minutos" mienten. Budget mínimo 10 horas para entender lo básico.

5. Está bien no saber todo. Yo llevo años y sigo googleando la sintaxis de kubectl.

Docker me salvó incontables horas de configuración. Kubernetes me las devolvió en debugging y frustración. Pero ambos son herramientas, y como toda herramienta, tienen su lugar.

Mi filosofía es simple: usa la herramienta más simple que resuelva tu problema. Si Docker Compose funciona, úsalo. Si necesitas Kubernetes, aprende lo mínimo necesario y reza para que no se rompa.

Y si todo falla, siempre puedes volver a Apache en un VPS. No se lo digas a nadie, pero la mitad de internet todavía funciona así.

¿Ustedes también sufren con Kubernetes o soy el único que prefiere la simplicidad de Docker? ¿Algún consejo para hacer K8s menos doloroso? Acepto cualquier ayuda, en serio, la necesito.