Voy a ser directo: durante el \u00faltimo a\u00f1o cambi\u00e9 de opini\u00f3n dos veces sobre este tema. Empec\u00e9 convencido de que Kubernetes era la respuesta correcta para casi todo. Despu\u00e9s migr\u00e9 tres proyectos de vuelta a Docker Compose. Y ahora, con la cabeza m\u00e1s fr\u00eda, creo que puedo darte algo m\u00e1s \u00fatil que un vago “depende del caso de uso”.<\/p>\n
Trabajo con un equipo de cuatro personas. Manejamos una plataforma SaaS con entre 8.000 y 12.000 usuarios activos seg\u00fan el mes, con picos bastante predecibles los martes y jueves. No somos Netflix. Tampoco somos un side project de fin de semana. Estamos exactamente en esa zona gris donde la elecci\u00f3n importa de verdad<\/a>.<\/p>\n Hay una narrativa muy extendida que dice que Compose es “solo para desarrollo local” y que en cuanto quieres hacer algo serio tienes que saltar a Kubernetes. Eso es, con todo el respeto, una simplificaci\u00f3n bastante da\u00f1ina.<\/p>\n Corr\u00ed Docker Compose en producci\u00f3n<\/a> durante 14 meses. Un VPS de Hetzner, 8 vCPUs, 32 GB de RAM, backups diarios con restic y un nginx actuando de reverse proxy delante de todo. El uptime fue del 99.7%. Los deployments tardaban unos 40 segundos. Y el Nada glamoroso. Pero funcionaba. Los deployments eran Lo que s\u00ed me cost\u00f3: cuando empezamos a necesitar m\u00e1s de una instancia del servicio Dicho esto: si tienes una sola m\u00e1quina, un equipo peque\u00f1o y menos de 50.000 usuarios, Compose en producci\u00f3n<\/a> no es una locura. Es una decisi\u00f3n pragm\u00e1tica perfectamente v\u00e1lida.<\/p>\n Migr\u00e9 a Kubernetes en octubre del a\u00f1o pasado. Usamos EKS en AWS (en aquel momento con Kubernetes 1.31, aunque ya vamos por 1.33). El razonamiento era s\u00f3lido: necesit\u00e1bamos escalar horizontalmente de forma autom\u00e1tica, hacer deployments sin downtime con m\u00e1s control, y prepararnos para a\u00f1adir m\u00e1s servicios sin que la infraestructura se volviera un spaghetti.<\/p>\n Lo que no calcul\u00e9 bien fue el coste de operaci\u00f3n.<\/p>\n El cl\u00faster m\u00ednimo viable en EKS nos sal\u00eda por unos 180\u2013220 d\u00f3lares al mes solo en nodos (sin contar el control plane, que en AWS son 70 d\u00f3lares fijos). A\u00f1ade el Application Load Balancer, los vol\u00famenes EBS, las transferencias de datos<\/a>, y llegas f\u00e1cil a 350\u2013400 d\u00f3lares al mes solo de infraestructura. En el<\/a> VPS de Hetzner est\u00e1bamos pagando 39 euros. La diferencia es significativa cuando eres una startup peque\u00f1a.<\/p>\n Pero el coste econ\u00f3mico es casi lo de menos. El coste en tiempo de ingenier\u00eda fue lo que realmente<\/a> doli\u00f3.<\/p>\n El primer mes post-migraci\u00f3n lo pas\u00e9 \u2014 okay, lo pasamos (somos cuatro, pero el tema infra recay\u00f3 principalmente en m\u00ed) \u2014 b\u00e1sicamente apagando fuegos de configuraci\u00f3n. El cluster RBAC, los secrets con External Secrets Operator porque los nativos de k8s son demasiado b\u00e1sicos, los PodDisruptionBudgets para que los deployments no bajaran el servicio, las NetworkPolicies, los resource limits que hab\u00eda que afinar porque sin ellos un worker se com\u00eda toda la memoria del nodo y desalojaba pods de producci\u00f3n…<\/p>\n El error que m\u00e1s me doli\u00f3, porque era evitable: estuve dos horas debuggeando por qu\u00e9<\/a> un pod se reiniciaba cada 15 minutos. El No digo que Kubernetes sea malo. Digo que tiene una superficie de configuraci\u00f3n enorme que hay que gestionar activamente, y para un equipo peque\u00f1o eso tiene un coste real que los tutoriales no mencionan.<\/p>\n Pasado el trauma inicial, hay tres \u00e1reas donde la comparaci\u00f3n entre Compose y k8s no est\u00e1 tan clara como parece.<\/p>\n Networking.<\/strong> En Compose, todos los servicios del mismo fichero comparten una red por defecto y se resuelven por nombre de servicio. Punto. En Kubernetes tienes namespaces, Services de tipo ClusterIP\/NodePort\/LoadBalancer, Ingress controllers (elige el tuyo: nginx-ingress, Traefik, Cilium Gateway API…), NetworkPolicies opcionales pero recomendadas. M\u00e1s potencia, m\u00e1s cosas que configurar. Lo que<\/a> s\u00ed te da k8s que Compose no puede igualar: service discovery entre m\u00faltiples equipos en el<\/a> mismo cl\u00faster, y routing sofisticado tipo canary releases con Argo Rollouts.<\/p>\n Secrets.<\/strong> Aqu\u00ed Kubernetes tiene fama de hacer las cosas bien, pero los Secrets nativos son simplemente base64 \u2014 no es cifrado. En 2026<\/a> ya no tienes excusa para no usar External Secrets Operator con AWS Secrets Manager o HashiCorp Vault, pero eso a\u00f1ade m\u00e1s piezas al puzzle. Con Compose en producci\u00f3n<\/a>, nosotros pas\u00e1bamos los secrets como variables de entorno desde un fichero Rollbacks.<\/strong> Este es donde Kubernetes gana sin discusi\u00f3n. Aqu\u00ed viene la parte que la verdad no hab\u00eda anticipado cuando escrib\u00ed mi primer draft de este art\u00edculo.<\/p>\n A principios de este a\u00f1o empec\u00e9 a experimentar con k3s \u2014 la distribuci\u00f3n ligera de Kubernetes de Rancher \u2014 en un VPS de Hetzner de 8 vCPUs y 16 GB de RAM. Lo que<\/a> encontr\u00e9 fue que la experiencia de operaci\u00f3n es considerablemente m\u00e1s cercana a Compose de lo que<\/a> imaginaba. Un solo binario. Control plane y worker en la misma m\u00e1quina. Incluye Traefik como ingress por defecto, SQLite en lugar de etcd para cl\u00fasteres peque\u00f1os, y el consumo de recursos en idle es sorprendentemente bajo \u2014 alrededor de 500MB de RAM para el control plane completo.<\/p>\n El coste: el mismo VPS que us\u00e1bamos con Compose, a 39 euros al mes, corriendo k3s en nodo \u00fanico. Y ya tienes No estoy 100% seguro de que esto escale bien m\u00e1s all\u00e1 de dos<\/a> o tres nodos workers sin empezar a necesitar etcd en alta disponibilidad \u2014 que ya es otra conversaci\u00f3n. Pero para ese punto dulce entre “Compose se queda corto” y “EKS es demasiado”, k3s en 2026<\/a> merece estar en la conversaci\u00f3n.<\/p>\n Despu\u00e9s de haber migrado proyectos en ambas direcciones, este es el proceso que ahora aplico.<\/p>\n \u00bfNecesitas escalar horizontalmente de forma autom\u00e1tica?<\/strong> \u00bfTienes m\u00e1s de un servicio que necesita escalar de forma independiente?<\/strong> \u00bfTu equipo tiene ancho de banda para aprender y mantener esto?<\/strong> Esta es la que m\u00e1s gente ignora. Kubernetes no es un deployment de un d\u00eda \u2014 es un sistema que requiere atenci\u00f3n continua. Los upgrades de versi\u00f3n (k8s depreca APIs con bastante regularidad, mira lo que<\/a> pas\u00f3 con PodSecurityPolicy en 1.25), los certificados que caducan, los nodos que necesitan mantenimiento. Si tu equipo de DevOps eres t\u00fa solo, o si el backend es un tercio de lo que tu equipo hace, ese tiempo tiene un coste de oportunidad alto que se subestima mucho.<\/p>\n Mi recomendaci\u00f3n sin rodeos: menos de 50.000 usuarios activos, equipo de menos de seis personas y un solo servidor o VPS \u2014 usa Docker Compose en producci\u00f3n<\/a>. Si ya se te queda peque\u00f1o o necesitas multi-nodo de verdad<\/a>, prueba k3s antes de comprometerte con EKS. Y si tienes un equipo de plataforma dedicado, m\u00faltiples servicios con requisitos de escala distintos y presupuesto para la complejidad operativa, entonces Kubernetes managed tiene todo el sentido.<\/p>\n
\nPor Qu\u00e9 Docker Compose Llega M\u00e1s Lejos de lo que<\/a> la Mayor\u00eda Cree<\/h2>\n
docker-compose.yml<\/code> que manejaba todo esto ten\u00eda menos de 120 l\u00edneas.<\/p>\n# docker-compose.yml (producci\u00f3n, versi\u00f3n simplificada)\nservices:\n api:\n image: registry.example.com\/api:${IMAGE_TAG}\n restart: unless-stopped\n environment:\n - DATABASE_URL=${DATABASE_URL}\n - REDIS_URL=redis:\/\/cache:6379\n depends_on:\n db:\n condition: service_healthy\n cache:\n condition: service_started\n healthcheck:\n test: ["CMD", "curl", "-f", "http:\/\/localhost:3000\/health"]\n interval: 30s\n timeout: 10s\n retries: 3\n\n worker:\n image: registry.example.com\/api:${IMAGE_TAG}\n command: ["node", "worker.js"]\n restart: unless-stopped\n depends_on:\n - cache\n - db\n\n db:\n image: postgres:16.3\n volumes:\n - postgres_data:\/var\/lib\/postgresql\/data\n healthcheck:\n test: ["CMD-SHELL", "pg_isready -U postgres"]\n interval: 10s\n timeout: 5s\n retries: 5\n\n cache:\n image: redis:7.4-alpine\n volumes:\n - redis_data:\/data\n\nvolumes:\n postgres_data:\n redis_data:\n<\/code><\/pre>\ndocker compose pull && docker compose up -d --no-deps api worker<\/code> y listo. Cero downtime si lo hac\u00edas bien \u2014 rolling update manual, s\u00ed, pero en 14 meses solo met\u00ed la pata una vez. Un viernes<\/a> por la tarde, c\u00f3mo no.<\/p>\napi<\/code>, las cosas se pusieron inc\u00f3modas. Compose no tiene balanceo de carga nativo entre r\u00e9plicas del mismo servicio de forma que realmente<\/a> te f\u00edes. Puedes usar --scale api=3<\/code> pero entonces tienes que configurar nginx manualmente para distribuir la carga entre los contenedores, y eso se vuelve fr\u00e1gil. Ese fue el primer momento en que empec\u00e9 a mirar k8s con m\u00e1s inter\u00e9s.<\/p>\n
\nEl Momento en que Kubernetes Pasa de Soluci\u00f3n a Problema<\/h2>\n
kubectl describe pod<\/code> mostraba OOMKilled<\/code>. Pens\u00e9 que era un memory leak. Result\u00f3 que el l\u00edmite de memoria del pod era demasiado bajo (512Mi) para un servicio que necesitaba 700Mi en los picos. Lo habr\u00eda visto antes si hubiera tenido Prometheus + Grafana bien configurados desde el d\u00eda uno. No los ten\u00eda.<\/p>\n
\nLas Diferencias que Importan en<\/a> 2026: Networking, Secrets y Rollbacks<\/h2>\n
.env<\/code> que no sub\u00edamos al repositorio. Menos elegante, pero funciona y es comprensible al 100%.<\/p>\nkubectl rollout undo deployment\/api<\/code> y en 30 segundos est\u00e1s en la versi\u00f3n anterior. Con Compose, el rollback es docker compose up -d<\/code> con el tag de imagen anterior \u2014 lo cual funciona, pero requiere que tengas ese tag anotado en alg\u00fan sitio y lo ejecutes manualmente. El domingo a las<\/a> 3am esto marca la diferencia.<\/p>\n
\nLa Sorpresa que No Esperaba: k3s Cambia el C\u00e1lculo<\/h2>\n
kubectl rollout undo<\/code>, HPA (Horizontal Pod Autoscaler), health checks declarativos, y la posibilidad de a\u00f1adir nodos workers cuando los necesites.<\/p>\n
\nEl Filtro Real: Las Tres Preguntas que Yo Me Har\u00eda<\/h2>\n
\nSi no \u2014 si un servidor bien especificado aguanta tu carga con margen, si tus picos son predecibles y manejables manualmente \u2014 entonces Compose. Punto. No te<\/a> vendas la complejidad de k8s como una inversi\u00f3n en el<\/a> futuro si ese futuro no existe todav\u00eda en tus m\u00e9tricas actuales.<\/p>\n
\nSi la API puede tener diez instancias pero el worker de procesamiento de PDFs solo necesita dos, Kubernetes gestiona esto de forma natural. Con Compose empiezas a hacer malabares con nginx y scripts bash. Si est\u00e1s en este punto, el salto tiene sentido<\/a> \u2014 pero mira k3s antes de ir directo a EKS o GKE.<\/p>\n