Kubernetes tiene un problema de reputación: la mitad del sector lo luce como una insignia y la otra mitad lo considera un impuesto. Para mí es una herramienta con un punto de entrada claro. Un sitio de marketing o un MVP funciona perfectamente en un único servidor con un gestor de procesos y una tarea de CI; así está desplegado este mismo sitio. Kubernetes empieza a tener sentido cuando hay varios servicios, carga irregular y más de un equipo desplegando en la misma infraestructura.
Todo empieza por el contenedor. Dockerfiles multi-stage, una imagen de ejecución pequeña, sin dependencias de desarrollo, un usuario sin privilegios y un proceso por contenedor. Una aplicación Next.js se compila en modo standalone; una API NestJS solo incluye dist y node_modules de producción. La misma imagen pasa de CI a staging y a producción. Solo cambia la configuración, mediante variables de entorno, ConfigMaps y Secrets; nunca se reconstruye para cada entorno.
Los objetos que utilizo a diario son pocos: un Deployment por servicio, un Service delante, un Ingress con TLS para el tráfico público y un HorizontalPodAutoscaler para las partes cuya carga realmente tiene picos. Cada contenedor recibe requests y limits de recursos; sin ellos, el scheduler tiene que adivinar. Separo a propósito las sondas readiness y liveness: readiness dice «aún no me envíes tráfico» y liveness, «reiníciame». Confundirlas convierte una base de datos lenta en una tormenta de reinicios. Además, cada servicio Node.js procesa SIGTERM y termina las solicitudes en curso para que una actualización progresiva no interrumpa un pago a la mitad.
No todo es un servidor web. Los workers de cola tienen sus propios Deployments y escalan según el retraso de la cola, no según la CPU. Las tareas programadas —informes, limpiezas y conciliaciones con un proveedor de pagos— se ejecutan como CronJobs con concurrencyPolicy: Forbid, para que una ejecución lenta no se solape con la siguiente. Las migraciones de base de datos se ejecutan como un Job antes del despliegue, no al iniciar la aplicación: cinco réplicas que arrancan a la vez no deberían intentar migrar el esquema simultáneamente. Prefiero PostgreSQL gestionado, como RDS, en vez de un StatefulSet; el clúster es para servicios sin estado.
Los manifiestos viven en Git y se revisan como código. El despliegue se hace mediante una pipeline de CI con Helm o Kustomize, o con GitOps y Argo CD; así, revertir es hacer un revert, no abrir una sesión de kubectl a medianoche. kubectl apply desde un portátil sirve para aprender, no para producción. Los logs van a stdout y luego a un almacén central; las métricas, a Prometheus y Grafana. Vigilo los despliegues con kubectl rollout status, sin limitarme a esperar que todo salga bien. En AWS suele significar EKS con grupos de nodos gestionados, para que el equipo dedique su tiempo al producto y no al control plane.
No usaría Kubernetes para un sitio de dos páginas, un service mesh antes de tener varios servicios, secretos en YAML sin cifrar dentro del repositorio ni pods sin límites porque «funcionó en staging». Si no tienes claro si necesitas un clúster, envíame tus servicios, el tráfico y el tamaño del equipo. Te diré con franqueza si te conviene Kubernetes, unos cuantos contenedores en un único host o una plataforma como Vercel, y cuánto cuesta al mes cada opción, aproximadamente.
Dale al próximo producto alguien que se quede.
¿Listo para empezar? Envíame un mensaje: puedo comenzar ahora y quedarme. Colaboraciones a largo plazo, no una entrega de dos semanas. Hablemos de tu proyecto, requisitos y la mejor forma de avanzar.