Kubernetes para proyectos pequeños: ¿realmente hace falta?

En un equipo pequeño, de hasta cinco desarrolladores, Kubernetes suele aparecer no como resultado de un cálculo, sino por la sensación de que «es lo que hacen los equipos serios». En la práctica, un orquestador es un producto en sí mismo: hay que actualizarlo, monitorizarlo, repararlo de madrugada y explicárselo a cada persona que se incorpora al equipo. Para una sola API y archivos estáticos detrás de nginx, rara vez compensa. Con cinco microservicios y despliegues semanales, ya existe margen para debatirlo.

Lo que se está contratando en realidad

Kubernetes ofrece una API unificada para despliegues, descubrimiento de servicios, health checks, actualizaciones progresivas y escalado horizontal. No se está contratando un «alojamiento barato», sino:

un plano de control — gestionado o administrado por el propio equipo;
un modelo operativo — quién responde cuando algo entra en CrashLoopBackOff a las tres de la madrugada;
componentes adicionales — Ingress, cert-manager, external-dns, secretos y clases de almacenamiento;
observabilidad — sin métricas ni alertas, el clúster está prácticamente ciego (véase monitorización para servidores y Kubernetes).

Si estos componentes no forman parte del plan, el «clúster mínimo de tres nodos» se convierte en un riesgo.

Cuándo Kubernetes resulta excesivo

Conviene seguir con una máquina virtual, una PaaS o Docker Compose si se cumplen la mayoría de estos puntos:

solo hay uno o dos artefactos desplegables, como un monolito y un worker;
los despliegues se hacen menos de una vez por semana y no existen requisitos estrictos de disponibilidad sin interrupciones;
no hay una persona asignada a las guardias de la plataforma;
el presupuesto se parece más al de una infraestructura MVP de 50 dólares al mes que al salario de un platform engineer de nivel intermedio.

Compose en una sola máquina, junto con systemd, un proxy inverso y copias de seguridad automatizadas, es aburrido pero predecible. Muchos productos B2B SaaS siguen funcionando así durante sus primeros miles de dólares de MRR.

Una PaaS gestionada como Fly.io, Render o una alternativa equivalente de un proveedor cloud se encarga de los despliegues progresivos y TLS. Se pierde cierta flexibilidad para usar patrones sidecar y políticas de red detalladas, pero se ganan meses de desarrollo desde el primer momento.

Cuándo Kubernetes empieza a tener sentido

Señales difíciles de fingir:

Varios servicios independientes son desplegados por personas distintas, y los conflictos de puertos y los scripts manuales se han vuelto habituales.
Los despliegues son frecuentes, varias veces al día, y hacen falta estrategias canary o blue-green sin interrupciones.
El escalado horizontal debe responder a métricas como el uso de CPU o la profundidad de una cola, en lugar de depender de que alguien inicie manualmente una segunda máquina virtual.
Las políticas comunes de red, seguridad de los pods y cuotas ya son un requisito de seguridad o cumplimiento normativo.
Ya se paga por Kubernetes gestionado y está claro quién atiende sus alertas.

k3s y otras distribuciones ligeras reducen la barrera de entrada para laboratorios domésticos y sistemas edge. Sin embargo, en producción, trabajar sin un runbook para «actualizar el clúster / restaurar etcd» implica la misma responsabilidad operativa, aunque con un menor consumo de RAM.

Gestionado o autoadministrado: coste y riesgo

Kubernetes gestionado tiene un coste fijo por el plano de control, además del coste de los nodos de trabajo. Alojarlo en servidores propios puede resultar más barato en hardware, pero más caro en horas de ingeniería. Esta disyuntiva también aparece en la comparación entre self-hosting y cloud en 2026.

Un error habitual en los proyectos pequeños es comparar únicamente el coste mensual de los nodos. También hay que sumar:

las horas dedicadas a configurar Ingress y DNS;
el coste de un despliegue defectuoso, incluido el tiempo de inactividad;
las herramientas de CI que crean imágenes y las envían al registro;
la retención de logs y trazas del clúster.

Si las horas de trabajo cuestan más que el ahorro frente a una PaaS, conviene posponer Kubernetes.

Lista práctica antes de usar `kubectl`

Responda por escrito:

Pregunta	Un «no» apunta a que probablemente no hace falta K8s
¿Cuántos servicios habrá en producción dentro de seis meses?	1–2
¿Quién está de guardia para el clúster?	«De momento, nadie»
¿Hace falta escalado automático según la cola o las RPS?	No
¿Hay un registro y una canalización de CI para las imágenes?	No
¿Está el equipo preparado para actualizar Kubernetes cada pocos meses?	No

Si la mayoría de las respuestas apuntan en contra de Kubernetes, conviene empezar con una máquina virtual, Compose o una PaaS. Prepare una ruta de migración: ejecute la aplicación en contenedores, traslade la configuración a variables de entorno y configure health checks. Así, un futuro cambio a Kubernetes será una migración y no una reescritura desde cero.

Si la mayoría de las respuestas indican que Kubernetes sí está justificado, pero no hay un ingeniero interno de guardia, se puede asignar la responsabilidad del clúster a un equipo externo como Ecooz. Conviene definir de antemano el ámbito de responsabilidad, el SLA, el proceso de escalado y los permisos de acceso, para que la «guardia externa» no se limite a un acuerdo verbal.

Soluciones intermedias que funcionan

Un único clúster gestionado con espacios de nombres separados para staging y producción cuesta menos que dos clústeres, pero exige disciplina con RBAC.
Helm o Kustomize desde el primer día evita que los archivos YAML diverjan entre entornos.
GitOps con Argo CD o Flux tiene sentido cuando hay muchos despliegues; para un solo servicio, CI más kubectl set image suele ser suficiente.

No cree un equipo de plataforma de dos personas para mantener un solo pod.

Conclusión

Un proyecto pequeño necesita Kubernetes no cuando el equipo quiere una arquitectura moderna, sino cuando el coste de los despliegues y el escalado manuales supera el de mantener el clúster. Hasta ese momento, resulta más sencillo y honesto conservar una infraestructura mínima, añadir monitorización y decidir después si el orquestador es el siguiente paso lógico y no la última moda.

Fuentes

Kubernetes Documentation — Production environment considerations. https://kubernetes.io/docs/setup/production-environment/
Kubernetes Documentation — Cluster administration overview. https://kubernetes.io/docs/concepts/cluster-administration/
CNCF — Cloud Native Definition. https://github.com/cncf/toc/blob/main/DEFINITION.md