Por qué existe Kubernetes
Cuando una aplicación corre en contenedores —piezas empaquetadas con todo lo que necesitan para funcionar igual en cualquier servidor—, el siguiente problema es operarlos: levantarlos, reiniciarlos si fallan, repartir el tráfico entre varias copias, y escalarlos cuando sube la demanda. Hacerlo a mano funciona con un contenedor. Con veinte o doscientos, se vuelve imposible de sostener sin errores. Kubernetes nació para resolver justo eso: es un orquestador que decide dónde corre cada contenedor, los reinicia si se caen, y los mueve entre servidores sin que nadie tenga que hacerlo a mano.
Qué es exactamente kubectl
Kubectl es la herramienta de línea de comandos con la que le hablas a un clúster de Kubernetes: «quiero tres copias de esta aplicación corriendo», «muéstrame qué está fallando», «actualiza esta imagen sin tumbar el servicio». Kubernetes lee esas instrucciones como un estado deseado, y se encarga de mantener la realidad del clúster alineada con ese estado todo el tiempo, incluso cuando algo falla a las tres de la mañana y nadie lo está viendo.
Los conceptos mínimos antes de usarlo
Un Pod es la unidad más pequeña: uno o más contenedores que comparten red y almacenamiento. Un Deployment describe cuántas copias de un Pod deben existir y cómo actualizarlas sin causar una caída. Un Service le da una dirección estable a un grupo de Pods que van y vienen. Y un clúster, al final, es un conjunto de servidores —físicos o virtuales— que Kubernetes trata como un solo recurso compartido.
Lo que cuesta tener Kubernetes desde el primer día
Aquí es donde muchos proyectos se meten en un problema que no tenían: Kubernetes resuelve un problema real, pero trae uno nuevo, que es operarlo a él. Configurar un clúster, mantenerlo actualizado y seguro, entender por qué un Pod no arranca a las dos de la mañana, y tener a alguien en el equipo que sepa leer sus logs y su estado interno, es trabajo especializado y constante. Para un equipo chico con dos o tres servicios, ese costo casi nunca se paga solo — es el mismo tipo de decisión que discutimos en nuestro post sobre monolito vs microservicios: el problema no es que la tecnología sea mala, es empezar con más complejidad de la que tu equipo necesita hoy.
Cuándo sí tiene sentido
Kubernetes vale la pena cuando ya tienes varios servicios independientes que necesitan escalar de forma distinta entre sí, cuando el tráfico es lo bastante variable como para necesitar escalamiento automático real, o cuando ya operas en más de un proveedor de nube y quieres una sola forma de desplegar en todos. También tiene sentido si tu equipo de infraestructura ya existe y solo necesita una herramienta más ordenada para lo que ya hace a mano.
Cuándo no lo necesitas todavía
Si tu aplicación es un solo servicio o un puñado de ellos, si tu tráfico es predecible, o si hoy no tienes a nadie dedicado a mantener infraestructura, casi siempre hay una opción más simple —un servicio administrado de contenedores, o incluso un servidor bien configurado— que te da la mayor parte del beneficio sin el costo operativo de un clúster completo. La pregunta correcta no es «necesito Kubernetes», es «qué problema específico tengo hoy que Kubernetes resolvería mejor que lo que ya tengo».
Revisamos cómo corre hoy tu aplicación y te decimos, sin venderte de más, qué tan lejos estás de necesitar un orquestador de contenedores — y qué opción más simple podría resolverlo mientras tanto.