Kubernetes para equipos pequeños: ¿vale la complejidad operativa?

Kubernetes es la herramienta correcta para orquestar contenedores a escala con equipos que tienen experiencia operando plataformas complejas. Para un startup con tres ingenieros o una empresa mediana sin un equipo de plataforma dedicado, la pregunta honesta es: ¿estamos adoptando Kubernetes porque resuelve nuestro problema, o porque es lo que se supone que hay que usar?

Lo que Kubernetes resuelve bien

Cuando funciona y está bien configurado, Kubernetes brilla en estos escenarios:

• Decenas de microservicios con diferentes necesidades de recursos, patrones de escala y frecuencias de despliegue
• Alta disponibilidad real: rescheduling automático en caso de fallo de nodo, rolling updates sin downtime, health checks nativos
• Multi-tenant: múltiples aplicaciones o equipos comparten la misma infraestructura con aislamiento de namespaces y resource quotas
• Ecosistema de herramientas: la mayoría de herramientas de observabilidad, service mesh y seguridad tienen integración nativa con Kubernetes

El costo real para equipos pequeños

La complejidad de Kubernetes no es solo técnica —es operativa. Un cluster de producción bien configurado requiere:

• Networking: elegir y configurar un CNI (Calico, Cilium, Flannel), entender cómo funciona el DNS interno, configurar NetworkPolicies
• Storage: CSI drivers, StorageClasses, gestión de PersistentVolumes para aplicaciones stateful
• Seguridad: RBAC, Pod Security Standards, gestión de secrets (idealmente integrado con Vault o Secrets Manager), image scanning
• Observabilidad: métricas (Prometheus + Grafana), logs (Loki o EFK stack), trazas (OpenTelemetry)
• Updates del cluster: actualizar Kubernetes sin downtime es un proceso que requiere planificación

Para un equipo de 2-3 ingenieros que también desarrolla producto, mantener todo esto bien es una carga considerable.

Las alternativas que vale considerar

ECS en AWS: Si ya estás en AWS, ECS (Elastic Container Service) da orquestación de contenedores con una fracción de la complejidad operativa de Kubernetes. Sin etcd, sin control plane que gestionar, integración nativa con ALB, IAM y CloudWatch. La contra: lock-in con AWS y menos portabilidad.

Managed Kubernetes (EKS, GKE, AKS): Si Kubernetes es la decisión correcta, usa la versión managed. El control plane es responsabilidad del proveedor cloud, los upgrades son asistidos y la integración con los servicios del ecosistema es nativa. El costo del control plane (~$70-150/mes en EKS) se justifica si de todas formas ibas a operar Kubernetes.

Fly.io, Render o Railway: Para aplicaciones más simples —APIs, workers, servicios web— estas plataformas ofrecen despliegues con contenedores Docker, escalado automático y zero-ops sin que el equipo tenga que pensar en infraestructura. Son significativamente más caras por recurso que Kubernetes self-hosted, pero el costo de ingeniería que ahorran puede justificar la diferencia.

La regla práctica

Si tienes menos de 10 servicios en producción y un equipo de ingeniería de menos de 8 personas, empieza sin Kubernetes y migra cuando la complejidad de lo que estás construyendo justifique la inversión en operaciones. La migración a Kubernetes cuando la necesitas es un proyecto manejable. La deuda operativa de un cluster mal gestionado desde el inicio es mucho más costosa.