Google Cloud ofrece dos plataformas principales para ejecutar aplicaciones en contenedores: GKE, para ejecutar contenedores en clústeres de Kubernetes, y Cloud Run, para ejecutar contenedores directamente en la infraestructura de Google Cloud . Pero, ¿cuándo deberías usar una u otra? ¿Y puedes usar ambas? En esta página se comparan las dos plataformas y sus ventajas, y se explica cómo determinar si una estrategia de una sola plataforma o una híbrida es la más adecuada para ti.
Esta página está dirigida a administradores de infraestructura y operadores de aplicaciones que ejecutan un conjunto diverso de cargas de trabajo en contenedores y quieren aprovechar las ventajas de Google Kubernetes Engine (GKE) y Cloud Run para desplegar aplicaciones en laGoogle Cloud plataforma.
Antes de leer esta página, asegúrate de que conoces los siguientes conceptos:
Cargas de trabajo con y sin reconocimiento del estado
¿Por qué usar GKE y Cloud Run juntos?
GKE y Cloud Run ofrecen diferentes ventajas para ejecutar aplicaciones contenerizadas y se adaptan a distintos niveles de complejidad de las cargas de trabajo. Sin embargo, no tienes que elegir entre las dos plataformas. Puedes aprovechar simultáneamente los puntos fuertes de GKE y Cloud Run migrando tus cargas de trabajo entre las dos plataformas según sea necesario. Una estrategia híbrida como esta puede ayudarte a optimizar los costes, el rendimiento y la sobrecarga de gestión.
A continuación se indican algunas ventajas de usar ambos tiempos de ejecución para desplegar tus cargas de trabajo:
GKE y Cloud Run ofrecen un nivel de portabilidad relativamente alto:
Ambas plataformas usan imágenes de contenedor estándar como artefactos de implementación. Puedes usar la misma imagen para tu aplicación en cualquiera de las dos plataformas sin tener que hacer ninguna modificación, lo que permite migrar cargas de trabajo sin problemas entre GKE y Cloud Run. No es necesario que actualices tu configuración de integración continua para migrar de GKE a Cloud Run siempre que las imágenes de contenedor se almacenen en Artifact Registry.
Tanto GKE como Cloud Run usan un modelo de API declarativo. La API Admin de Cloud Run v1 se ha diseñado para que sea compatible con la API de Kubernetes. Esto significa que puedes usar conceptos de Kubernetes que ya conoces, como los despliegues, los servicios y los escaladores automáticos de pods horizontales, para gestionar tu servicio de Cloud Run. Esta similitud facilita la traducción de configuraciones entre las dos plataformas.
Los recursos se representan en archivos YAML con la misma estructura declarativa y estándar, por lo que se pueden migrar fácilmente entre tiempos de ejecución. Aquí tienes un ejemplo que compara los archivos YAML de un despliegue de Kubernetes y un servicio de Cloud Run.
Tanto GKE como Cloud Run se integran a la perfección con Cloud Logging y Cloud Monitoring, lo que te ofrece una vista centralizada en la consola Google Cloud para observar las métricas de las aplicaciones independientemente de su plataforma. También puedes usar la monitorización de objetivos de nivel de servicio (SLOs) en ambas plataformas y ver una pantalla unificada de los SLOs en el panel de control de Cloud Monitoring.
Puedes implementar la entrega continua en recursos de GKE o servicios de Cloud Run mediante Cloud Deploy. Si lo prefieres, puedes desplegar tu aplicación simultáneamente en GKE y Cloud Run mediante el despliegue paralelo.
Puedes facilitar la gestión avanzada del tráfico mediante balanceadores de carga externos e internos para servicios en GKE y Cloud Run. Esto incluye la posibilidad de exponer endpoints externos para que puedas implementar y ejecutar diferentes URLs de la misma aplicación en ambas plataformas. También puedes dividir el tráfico del mismo servicio entre GKE y Cloud Run, lo que permite migrar fácilmente de una plataforma a otra.
Google Cloud proporciona herramientas de seguridad para mejorar tu posición de seguridad al usar ambos tiempos de ejecución. El análisis del SO te permite analizar contenedores en busca de vulnerabilidades antes de implementarlos en cualquiera de las dos plataformas. Una política de autorización binaria central puede aplicar la integración con el plano de control de GKE y Cloud Run para permitir o bloquear el despliegue de imágenes en función de las políticas que definas. Con Controles de Servicio de VPC, los equipos de seguridad pueden definir controles de perímetro detallados en tus recursos de GKE y Cloud Run.
Comparar GKE y Cloud Run
Para aprovechar las mejores funciones de GKE y Cloud Run, y saber cuándo mover cargas de trabajo entre ellos, es importante entender las diferencias entre los dos servicios.
| Función | GKE | Cloud Run |
|---|---|---|
| Implementación y gestión | Gestionar los clústeres de Kubernetes, incluida la configuración de nodos, las redes, el escalado y las actualizaciones. Google Cloud gestiona la infraestructura subyacente y proporciona herramientas para simplificar las operaciones de los clústeres, pero tú sigues siendo responsable de los aspectos principales de Kubernetes. |
Ejecuta contenedores directamente en la infraestructura escalable de Google Cloud. Solo tienes que proporcionar el código fuente o una imagen de contenedor, y Cloud Run puede compilar el contenedor por ti. No tienes que crear un clúster ni aprovisionar y gestionar la infraestructura. |
| Control y flexibilidad | Control total sobre el clúster de Kubernetes. Puedes crear personalizaciones avanzadas de configuraciones de nodos, políticas de red, ajustes de seguridad y complementos. |
Control limitado sobre la infraestructura subyacente. Puedes configurar aspectos como las variables de entorno, la simultaneidad y las conexiones de red, pero no puedes personalizar la infraestructura ni el entorno subyacentes. Ideal para disfrutar de la sencillez y la velocidad. |
| Tipos de aplicaciones | Es compatible con aplicaciones con y sin reconocimiento del estado, y es ideal para aplicaciones complejas con necesidades de recursos específicas. | Es la opción más adecuada para servicios, servicios web y funciones sin estado, basados en solicitudes o en eventos. |
| Modelo de precios | Se paga por clúster y hora, independientemente del modo de operación (Standard o Autopilot), el tamaño o la topología del clúster. | Paga solo por lo que uses, redondeando a los 100 milisegundos más cercanos. |
Caso práctico
Supongamos que eres administrador de una plataforma de una empresa minorista que está creando una gran plataforma de comercio electrónico. Tienes las siguientes cargas de trabajo en contenedores que quieres implementar:
Sitio web y aplicación móvil de frontend: una aplicación web sin estado que gestiona la búsqueda, la navegación y la compra de productos.
Gestión del inventario de productos: servicio con estado que gestiona la disponibilidad y las actualizaciones de los productos.
Motor de recomendaciones: un microservicio complejo que genera recomendaciones de productos personalizadas para cada usuario.
Trabajos de procesamiento por lotes: incluye tareas periódicas, como actualizar catálogos de productos y analizar el comportamiento de los usuarios.
Estas cargas de trabajo representan una combinación de servicios con y sin reconocimiento del estado, por lo que decides aprovechar tanto GKE como Cloud Run para obtener un rendimiento óptimo. Aquí tienes una forma de implementar un enfoque híbrido para tus cargas de trabajo.
Después de leer los criterios para determinar si las cargas de trabajo de Cloud Run son adecuadas, decides usar Cloud Run para el sitio web, la aplicación móvil y los trabajos de procesamiento por lotes. Desplegar estos servicios en Cloud Run tiene las siguientes ventajas:
El escalado automático se encarga de los picos de tráfico y de los trabajos por lotes grandes sin necesidad de intervención manual.
Rentabilidad con un modelo de pago por uso. Solo pagas cuando los usuarios navegan o completan el proceso de compra, y cuando se usan recursos durante la ejecución de tareas por lotes.
Implementaciones más rápidas, ya que las actualizaciones están disponibles al instante, lo que mejora la experiencia de usuario.
Integración sencilla con otros Google Cloud servicios. Por ejemplo, para el procesamiento basado en eventos, puedes usar funciones de Cloud Run para iniciar tareas de procesamiento por lotes en Cloud Run y habilitar flujos de trabajo fluidos.
La gestión del inventario de productos es un servicio con estado que requiere un control preciso y, posiblemente, soluciones de almacenamiento personalizadas. Decides usar GKE para implementar este servicio, ya que ofrece almacenamiento persistente y te permite adjuntar volúmenes para la persistencia y la fiabilidad de los datos de los productos.
El motor de recomendaciones es un microservicio complejo que se beneficia de GKE. Con GKE, puedes gestionar dependencias complejas y ejercer un control pormenorizado sobre la asignación y el escalado de recursos.
GKE es más adecuado para arquitecturas de microservicios complejas, aplicaciones con estado, cargas de trabajo que requieren configuraciones de infraestructura o de red personalizadas, y situaciones en las que es esencial tener un control exhaustivo sobre Kubernetes. Cloud Run es la opción más adecuada para las aplicaciones basadas en eventos. Es ideal para servicios web sin estado, APIs, tareas por lotes y otras cargas de trabajo que se benefician de los precios de pago por uso.
En el ejemplo anterior se muestra cómo la combinación de GKE y Cloud Run puede proporcionar una solución potente y flexible para tu plataforma de comercio electrónico. Disfrutarás de las ventajas de ambas plataformas: la eficiencia de los entornos sin servidor para las cargas de trabajo sin estado y el control de Kubernetes para los microservicios complejos y los componentes con estado.
Para obtener una vista unificada de los distintos componentes que se implementan con un enfoque híbrido y ver cómo funcionan en conjunto como una aplicación coherente, puedes usar App Hub. Para obtener más información, consulta Recursos admitidos en el centro de aplicaciones.
Cuestiones importantes
GKE y Cloud Run se complementan entre sí y satisfacen diferentes necesidades en un entorno de aplicaciones complejo.
A continuación se indican algunos aspectos que debes tener en cuenta al adoptar un enfoque híbrido para implementar cargas de trabajo:
Ejecuta microservicios sin reconocimiento del estado en Cloud Run para aumentar la rentabilidad y la escalabilidad.
Despliega aplicaciones complejas con reconocimiento del estado que requieran una personalización profunda en GKE.
Si usas una red privada en Google Cloud, para acceder a los recursos de tu clúster de GKE desde tu servicio de Cloud Run, puedes enviar una solicitud a una red de nube privada virtual (VPC) mediante la salida de VPC directa. Para acceder a los servicios de Kubernetes en el clúster de GKE, el servicio de Cloud Run debe estar conectado a la red de VPC del clúster y el servicio de Kubernetes debe usar un balanceador de carga de red de transferencia interno.
Para migrar el tráfico entre Cloud Run y GKE, puedes exponer endpoints externos detrás de un balanceador de carga de aplicación externo global. Si implementas este balanceador de carga delante de los servicios de ambos tiempos de ejecución, podrás desplegar la misma aplicación en Cloud Run y GKE, lo que te permitirá transferir gradualmente el tráfico de una plataforma a otra.
Para exponer servicios de Cloud Run en una nube privada virtual con IPs privadas, usa un balanceador de carga interno.
Recuerda que, si tus cargas de trabajo ya están en Cloud Run, puedes migrar a GKE cuando lo necesites.
Cuándo no usar GKE y Cloud Run juntos
Aunque GKE y Cloud Run ofrecen un enfoque atractivo para muchas cargas de trabajo en contenedores, hay situaciones en las que usarlos juntos puede no ser la mejor opción. A continuación, te mostramos algunos ejemplos de situaciones en las que puedes decidir no adoptar un enfoque híbrido:
Microservicios con acoplamiento fuerte: si tus microservicios dependen mucho entre sí y requieren una comunicación frecuente con baja latencia, gestionarlos en plataformas independientes puede generar complejidades. Las llamadas de red frecuentes entre plataformas podrían añadir sobrecarga y posibles cuellos de botella, lo que afectaría al rendimiento.
Aplicaciones antiguas con dependencias personalizadas: si tu aplicación depende de bibliotecas, frameworks o configuraciones específicas que no son compatibles con Cloud Run, es posible que tengas que refactorizar o buscar soluciones alternativas para usarlo en algunas partes de la aplicación. Esto puede anular las ventajas de la tecnología sin servidor e introducir una sobrecarga de mantenimiento específica de la plataforma.
Restricciones de presupuesto con cargas de trabajo predecibles: si tu carga de trabajo tiene requisitos de recursos coherentes y tienes un presupuesto ajustado, el modelo de pago por nodo de GKE puede ser más rentable que la facturación por uso de Cloud Run. Si tienes cargas de trabajo predecibles, es posible que no aproveches al máximo las ventajas del escalado automático de Cloud Run, por lo que el coste fijo de GKE puede ser más atractivo.
En última instancia, la mejor opción depende de tus necesidades y prioridades específicas. Evalúa detenidamente los requisitos de tu aplicación, las limitaciones de recursos y la experiencia del equipo antes de decidirte por una arquitectura híbrida de GKE y Cloud Run.
Siguientes pasos
Consulta cómo convertir tu servicio de Cloud Run en un despliegue de Kubernetes en el artículo Migrar de Cloud Run a GKE.
Empaqueta tu despliegue de Kubernetes en un contenedor compatible con Cloud Run siguiendo las instrucciones de Migrar de Kubernetes a Cloud Run.