Técnico
Docker Compose o Kubernetes: costo, secretos y salida
Guía práctica para decidir entre Docker Compose y Kubernetes en pymes: servicios, secretos, RBAC, backups, costos, restauración y prueba de salida.
Docker Compose v5.5.1 fue publicado el 3 de septiembre de 2026. La fecha importa porque muchas pymes siguen discutiendo contenedores desde la moda técnica. En realidad, la decisión es más corta: ¿el sistema necesita levantar pocos servicios con una operación simple o necesita controles de clúster, RBAC, despliegues y namespaces?
Dónde termina Docker Compose
La documentación oficial de Docker Compose lo define para crear y ejecutar aplicaciones multi-contenedor. El archivo YAML reúne servicios, redes y volúmenes, y los comandos permiten iniciar, detener, reconstruir, ver estado, leer logs y ejecutar tareas puntuales. Para una pyme con sistema interno, base de datos, cola, API y proxy, esa superficie puede ser suficiente. El dato que baja la ansiedad de compra viene de la encuesta Stack Overflow 2025: 45,5% de los encuestados usa entre una y cinco aplicaciones o plataformas de trabajo, y 35,4% usa entre seis y diez. Una pila chica rara vez justifica una capa operativa que nadie va a cuidar de lunes a viernes. Un YAML sin restauración es solo arranque prolijo. ## Dónde empieza Kubernetes Kubernetes se presenta como una plataforma abierta para gestionar cargas y servicios en contenedores con configuración declarativa y automatización. Empieza a tener sentido cuando aparecen varios entornos, más de un nodo, equipos separados, permisos granulares, despliegues frecuentes, balanceo interno, autosanación y políticas. La documentación de buenas prácticas RBAC pide privilegio mínimo, permisos por namespace cuando sea posible, RoleBindings antes que ClusterRoleBindings y cuidado con permisos comodín. Ese es el precio oculto: Kubernetes trae controles poderosos, pero exige que alguien revise tokens, cuentas de servicio, roles y permisos residuales.
Cómo trabaja por dentro
El flujo mínimo tiene siete pasos. Primero, inventario de servicios: aplicación, base, cache, cola, proxy, tareas programadas y almacenamiento. Segundo, decisión de entorno: Compose para host único o Kubernetes para clúster y separación fuerte. Tercero, secretos: Compose monta archivos en /run/secrets y Kubernetes usa Secret más política de acceso. Cuarto, datos persistentes: volúmenes locales o almacenamiento de clúster, siempre con prueba de recuperación. Quinto, logs y métricas: journald, Loki, Prometheus o lo que ya use la empresa. Sexto, permisos: usuario deploy, lectura de logs, administración de secretos y aprobación de cambios. Séptimo, backup: base, volúmenes, manifiestos, variables, secretos cifrados y restauración en un entorno separado. Docker Compose Secrets evita guardar contraseñas en variables de entorno y entrega acceso por servicio. En Kubernetes, el riesgo se mueve a RBAC, service accounts y permisos sobre namespaces. La señal de madurez aparece cuando el equipo puede explicar dónde vive cada secreto, quién lo cambia, qué servicio lo lee y cómo se recupera si el host se pierde. Antes de sumar nodos, esa respuesta vale más que el nombre de la plataforma.
Qué se instala o configura primero
La pila inicial para Compose puede usar Docker Engine, Compose v5.5.1, proxy TLS, PostgreSQL 18, Redis, backup con restic y monitoreo básico. Para Kubernetes, el alcance mínimo agrega cluster, ingress, cert-manager, storage class, RBAC, namespaces, manifiestos y pipeline. Con dólar oficial venta de ARS 1545, una puesta Compose para cuatro servicios puede ubicarse entre USD 600 y USD 1.200, es decir entre ARS 927.000 y ARS 1.854.000. Un primer Kubernetes administrado para el mismo sistema puede ubicarse entre USD 1.200 y USD 2.400, es decir entre ARS 1.854.000 y ARS 3.708.000. Incluye configuración, secretos, backup, restauración y documentación operativa. No incluye reescritura de aplicación ni alta disponibilidad real en varios sitios. UMSA puede empezar con Compose cuando la empresa necesita control rápido y equipo chico. El entregable verificable es una prueba que baja el host, restaura base, volúmenes, secretos y proxy, y deja el sistema accesible en otra máquina. La nota sobre Semaphore UI 2.19 completa la operación: playbooks, llaves y bitácora para que los despliegues no dependan de una terminal personal.
Dónde se rompe y cómo probarlo
El primer riesgo es esconder secretos en variables de entorno. La prueba busca claves en logs, history, Compose, manifiestos y paneles de error. El resultado esperado es cero exposición y acceso por archivo o gestor. El segundo riesgo es respaldar solo la base. La prueba restaura base, volúmenes, certificados, configuración y DNS interno. Si el contenedor arranca sin archivos cargados, el backup está incompleto. El tercer riesgo es crear un clúster sin dueño de RBAC. La prueba lista permisos efectivos por usuario y service account, busca comodines y revisa ClusterRoleBindings. El cuarto riesgo es elegir Kubernetes para tapar desorden de aplicación. La prueba mide cuántos servicios existen, cuántas personas operan, cuántos despliegues semanales hay y qué falla se quiere resolver. La regla práctica: Compose gana cuando la operación cabe en una máquina bien respaldada; Kubernetes gana cuando el problema real es control de plataforma. La decisión se valida con restauración, permisos y una salida documentada.
