Gestionar un contenedor es sencillo, pero cuando hablamos de decenas, centenas o miles, la complejidad crece de forma exponencial. Aquí es donde entra Kubernetes como plataforma de orquestación, y donde soluciones como Cloud Run y Knative llevan la experiencia un paso más allá al combinar contenedores con el modelo serverless. Entender cómo se relacionan estas piezas es fundamental para diseñar arquitecturas modernas, escalables y eficientes en costos.
¿Qué es Kubernetes y por qué resuelve los problemas del día dos?
Kubernetes es una plataforma open source creada por Google, presentada en sociedad en 2014 y entregada a la Cloud Native Computing Foundation en 2015 [1:00]. Al ser un proyecto donado, cualquier compañía puede tomar el código y ofrecer su propia versión; Google, por ejemplo, tiene Google Kubernetes Engine (GKE), cuyo objetivo es facilitar la administración de un cluster de Kubernetes.
La idea central es una abstracción de la infraestructura [1:30]. En lugar de preocuparte por cuántos servidores tienes o qué sistemas operativos corren, piensas en un pool de recursos de cómputo: tanta memoria RAM, tanto CPU, todo disponible para las aplicaciones desplegadas como contenedores.
¿Cómo funciona la arquitectura interna de Kubernetes?
A alto nivel, Kubernetes expone una API que permite interactuar con el control plane [2:08]. Este control plane es la colección de funcionalidades encargada de gestionar los distintos nodos. Puedes manejarlo desde una interfaz gráfica (UI) o desde la línea de comandos con kubectl [2:50].
Dentro del control plane encontramos componentes clave:
- Scheduler: decide en qué nodo se ejecuta cada carga de trabajo.
- Controller manager: controla políticas de replicación.
- Servicios y namespaces: organizan y aíslan recursos.
¿Qué papel juegan los nodos y los pods?
Cada nodo representa una unidad de cómputo con una cantidad definida de RAM y CPU [3:05]. Dentro de los nodos viven los pods, que son la unidad lógica mínima donde corren tus contenedores. El pod garantiza la asignación de recursos y permite controlar si una aplicación queda expuesta a Internet o solo se comunica con otros servicios dentro del cluster [3:30].
¿Cómo nació Cloud Run a partir de los aprendizajes de Google?
Google no empezó con Kubernetes Engine. Su primer gran producto de plataforma fue App Engine [4:05], un servicio de Platform as a Service (PaaS) donde lanzabas aplicaciones en Java, Python, Node, Ruby o Go sin preocuparte por sistemas operativos. Funcionaba bien, pero no se ajustaba a todas las necesidades.
Después llegaron las Cloud Functions como oferta serverless, y más adelante Kubernetes Engine. Al evaluar las ventajas de cada uno, surgió Cloud Run [4:45]:
- Portabilidad de contenedores heredada de Kubernetes.
- Abstracción de infraestructura al estilo App Engine.
- Modelo serverless similar a Cloud Functions.
Cloud Run es la suma de esos aprendizajes, y su nombre como proyecto open source es Knative [5:15]. Si Kubernetes ya abstrae la infraestructura, Knative es una capa adicional sobre Kubernetes que elimina la necesidad de convertirse en experto para aprovechar los contenedores en modo serverless.
¿Qué ventajas ofrece Knative para arquitecturas de microservicios?
Knative tiene dos grandes componentes: uno orientado a eventos y otro a servir contenido [5:45]. En la parte de servir contenido defines servicios que pueden comunicarse entre sí o quedar expuestos para aplicaciones externas, lo que lo convierte en una opción ideal para arquitecturas basadas en microservicios.
Cada servicio tiene:
- Una ruta (URL) para recibir peticiones.
- Mecanismos para configurar múltiples revisiones o versiones del servicio.
¿Cómo distribuir tráfico entre versiones con Istio?
Istio [6:20] es otro proyecto open source que permite distribuir tráfico y regular la comunicación entre servicios. Dentro de Cloud Run puedes repartir el tráfico entre revisiones: 20 % a la revisión uno, 30 % a la dos y 50 % a la tres. Esto habilita experimentos como probar un nuevo landing page con un grupo de usuarios, hacer un rollout gradual si funciona, o revertir instantáneamente ante una falla [6:50].
La gran ventaja adicional es el escalado a cero [7:20]. Cuando nadie usa tu aplicación, no pagas nada porque no hay cómputo activo. Cuando llega una nueva solicitud, el servicio se activa y atiende las peticiones.
¿Ya has experimentado con Cloud Run o Knative para tus proyectos? Comparte tu experiencia y las dudas que te hayan surgido.
