Seleccionar un entorno de ejecución de contenedor gestionado

Last reviewed 2024-08-30 UTC

Este documento te ayuda a evaluar los requisitos de tu aplicación y a elegir entre Cloud Run y Autopilot de Google Kubernetes Engine (GKE) en función de consideraciones técnicas y organizativas. Este documento está dirigido a arquitectos de la nube que necesiten elegir un Google Cloud entorno de tiempo de ejecución de contenedor de destino para sus cargas de trabajo. Se presupone que conoces Kubernetes y Google Cloudy que tienes algunos conocimientos sobre entornos de ejecución sin servidor en la nube, como Cloud Run, Cloud Run functions o AWS Lambda.

Google Cloud ofrece varias opciones de entorno de tiempo de ejecución que tienen una serie de funciones. En el siguiente diagrama se muestra la gama de ofertas gestionadas de Google Cloud:

Google Cloud de más a menos gestionados.

En el diagrama se muestra lo siguiente:

  • Entornos de ejecución más gestionados (el tema principal de esta guía):

    Google gestiona estas opciones, por lo que los usuarios no pueden gestionar la infraestructura de computación subyacente.

  • Entornos de ejecución menos gestionados:

    • GKE Standard, que está optimizado para cargas de trabajo empresariales y ofrece una escalabilidad de un solo clúster de hasta 65.000 nodos.
    • Compute Engine, que incluye la familia de máquinas virtuales A3 optimizada para aceleradores para cargas de trabajo de aprendizaje automático y computación de alto rendimiento.

    Estas opciones requieren cierto grado de gestión de la infraestructura a nivel de usuario, como las máquinas virtuales que sustentan las funciones de computación. Las VMs de GKE Standard son los nodos del clúster de Kubernetes. Las VMs de Compute Engine son la oferta principal de la plataforma, que puedes personalizar para adaptarla a tus necesidades.

Esta guía te ayuda a elegir entre los entornos de ejecución más gestionados: Cloud Run y Autopilot de GKE. Para obtener una visión más general de los entornos de ejecución, consulta la guía Google Cloud Opciones de alojamiento de aplicaciones. Google Cloud

Descripción general de los entornos

En esta sección se ofrece una descripción general de las funciones de Cloud Run y GKE Autopilot. Cloud Run y Autopilot de GKE están estrechamente integrados en Google Cloud, por lo que tienen muchas características en común. Ambas plataformas admiten varias opciones de balanceo de carga con los servicios de balanceo de carga altamente fiables y escalables de Google. Ambos admiten redes de VPC, Identity-Aware Proxy (IAP) y Google Cloud Armor para cuando se requiere una red privada más granular. En ambas plataformas solo se te cobra por los recursos exactos que usas en tus aplicaciones.

Desde el punto de vista de la entrega de software, Cloud Run y GKE Autopilot, como entornos de tiempo de ejecución de contenedores, son compatibles con los servicios que componen el Google Cloud ecosistema de contenedores. Estos servicios incluyen Cloud Build, Artifact Registry, Binary Authorization y la entrega continua con Cloud Deploy, para ayudarte a asegurarte de que tus aplicaciones se despliegan de forma segura y fiable en producción. Esto significa que tú y tus equipos tomáis las decisiones sobre la compilación y el despliegue.

Debido a las similitudes entre las dos plataformas, puede que te interese aprovechar las ventajas de cada una adoptando un enfoque flexible sobre dónde desplegar tus aplicaciones, tal como se explica en la guía Usar GKE y Cloud Run juntos. En las siguientes secciones se describen aspectos únicos de Cloud Run y Autopilot.

Cloud Run

Cloud Run es una plataforma de computación gestionada sin servidor que te permite ejecutar tus aplicaciones directamente en la infraestructura escalable de Google. Cloud Run ofrece automatización y escalado para dos tipos principales de aplicaciones:

Con estos dos modelos de implementación, Cloud Run puede admitir una amplia gama de arquitecturas de aplicaciones, a la vez que permite aplicar las prácticas recomendadas y los desarrolladores pueden centrarse en el código.

Cloud Run también admite el despliegue de código de aplicación desde las siguientes fuentes:

  • Funciones ligeras individuales
  • Aplicaciones completas a partir del código fuente
  • Aplicaciones en contenedores

Cloud Run incorpora una función de compilación y despliegue que admite tanto FaaS como la capacidad de compilar a partir de código fuente, junto con la función de tiempo de ejecución de contenedores prediseñados. Si usas Cloud Run de esta forma, los pasos de compilación y despliegue de la imagen de contenedor de la aplicación que se va a ejecutar son totalmente automáticos y no requieren ninguna configuración personalizada.

Autopilot de GKE

Autopilot de GKE es el modo de funcionamiento de clúster predeterminado y recomendado en GKE. Autopilot te permite ejecutar aplicaciones en Kubernetes sin la sobrecarga de gestionar la infraestructura. Cuando usas Autopilot, Google gestiona aspectos clave de la configuración de tu clúster, como el aprovisionamiento y el escalado de nodos, la postura de seguridad predeterminada y otros ajustes preconfigurados. Con Autopilot, que gestiona los recursos de los nodos, solo pagas por los recursos que solicitan tus cargas de trabajo. Autopilot monitoriza y optimiza continuamente los recursos de la infraestructura para asegurar que se ajustan a tus necesidades y, al mismo tiempo, ofrece un ANS para tus cargas de trabajo.

GKE Autopilot admite cargas de trabajo que no se ajustan a Cloud Run. Por ejemplo, GKE Autopilot suele admitir cargas de trabajo duraderas o con estado.

Elegir un entorno de ejecución

Por lo general, si las características de tu carga de trabajo son adecuadas para una plataforma gestionada, el entorno de ejecución sin servidor de Cloud Run es ideal. Si usas Cloud Run, tendrás menos infraestructura que gestionar, menos configuración autogestionada y, por lo tanto, menos gastos operativos. A menos que quieras o necesites Kubernetes específicamente, te recomendamos que consideres primero un entorno sin servidor como entorno de ejecución de destino. Aunque Kubernetes proporciona la potente abstracción de una plataforma abierta, su uso añade complejidad. Si no necesitas Kubernetes, te recomendamos que te plantees si tu aplicación es adecuada para un entorno sin servidor. Si hay criterios que hacen que tu carga de trabajo sea menos adecuada para la tecnología sin servidor, te recomendamos que utilices Autopilot.

En las siguientes secciones se ofrece más información sobre algunos de los criterios que pueden ayudarte a responder a estas preguntas, en concreto, a la de si la carga de trabajo es adecuada para la tecnología sin servidor. Dada la similitud entre Autopilot y Cloud Run, que se describe en las secciones anteriores, la migración entre las plataformas es una tarea sencilla si no hay ningún problema técnico ni de otro tipo. Para obtener más información sobre las opciones de migración, consulta los artículos Migrar de Cloud Run a GKE y Migrar de Kubernetes a Cloud Run.

Cuando elijas un entorno de tiempo de ejecución para tu carga de trabajo, debes tener en cuenta aspectos técnicos y organizativos. Las consideraciones técnicas son características de tu aplicación o del Google Cloudentorno de tiempo de ejecución. Las consideraciones organizativas son características no técnicas de tu organización o equipo que pueden influir en tu decisión.

Aspectos técnicos

Estos son algunos de los aspectos técnicos que influirán en tu elección de plataforma:

  • Control y configurabilidad: granularidad del control del entorno de ejecución.
  • Gestión y enrutamiento del tráfico de red: capacidad de configuración de las interacciones a través de la red.
  • Escalabilidad horizontal y vertical: admite el aumento y la reducción dinámicos de la capacidad.
  • Compatibilidad con aplicaciones con reconocimiento del estado: funciones para almacenar estados persistentes.
  • Arquitectura de CPU: compatibilidad con diferentes tipos de CPU.
  • Descarga de aceleradores (GPUs y TPUs): capacidad de descargar la computación en hardware específico.
  • Alta capacidad de memoria, CPU y otros recursos: nivel de varios recursos consumidos.
  • Dependencia explícita de Kubernetes: requisitos para usar la API de Kubernetes.
  • Control de acceso basado en roles complejo para arquitecturas multiempresa: admite el uso compartido de recursos agrupados.
  • Tiempo máximo de espera de la tarea del contenedor: duración de la ejecución de aplicaciones o componentes de larga duración.

En las siguientes secciones se detallan estas consideraciones técnicas para ayudarte a elegir un entorno de ejecución.

Control y configurabilidad

En comparación con Cloud Run, GKE Autopilot ofrece un control más granular del entorno de ejecución de tus cargas de trabajo. En el contexto de un pod, Kubernetes proporciona muchas primitivas configurables que puedes ajustar para cumplir los requisitos de tu aplicación. Las opciones de configuración incluyen el nivel de privilegio, los parámetros de calidad del servicio, los controladores personalizados para los eventos del ciclo de vida del contenedor y el uso compartido del espacio de nombres del proceso entre varios contenedores.

Cloud Run admite directamente un subconjunto de la superficie de la API de pods de Kubernetes, que se describe en el YAML de referencia del objeto de servicio de Cloud Run y en el YAML de referencia del objeto de trabajo de Cloud Run. Estas guías de referencia pueden ayudarte a evaluar las dos plataformas junto con los requisitos de tu aplicación.

El contrato de contenedor del entorno de ejecución de Cloud Run es relativamente sencillo y se adapta a la mayoría de las cargas de trabajo de servicio. Sin embargo, el contrato especifica algunos requisitos que deben cumplirse. Si tu aplicación o sus dependencias no pueden cumplir esos requisitos, o si necesitas un mayor grado de control sobre el entorno de ejecución, Autopilot puede ser más adecuado.

Si quieres reducir el tiempo que dedicas a la configuración y la administración, te recomendamos que elijas Cloud Run como entorno de ejecución. Cloud Run tiene menos opciones de configuración que Autopilot, por lo que puede ayudarte a maximizar la productividad de los desarrolladores y reducir los gastos operativos.

Gestión y enrutamiento del tráfico de red

Tanto Cloud Run como Autopilot de GKE se integran con el balanceo de carga de Google Cloud. Sin embargo, Autopilot de GKE también proporciona un conjunto de primitivas completo y potente para configurar el entorno de red de las comunicaciones entre servicios. Las opciones de configuración incluyen permisos granulares y segregación en la capa de red mediante espacios de nombres y políticas de red, reasignación de puertos y descubrimiento de servicios DNS integrado en el clúster. Autopilot de GKE también admite la API Gateway, que es muy configurable y flexible. Esta función ofrece un control eficaz sobre la forma en que se enruta el tráfico hacia los servicios del clúster y entre ellos.

Como Autopilot es altamente configurable, puede ser la mejor opción si tienes varios servicios con un alto grado de codependencia de red o requisitos complejos sobre cómo se enruta el tráfico entre los componentes de tu aplicación. Un ejemplo de este patrón es una aplicación distribuida que se descompone en numerosos microservicios que tienen patrones complejos de interdependencia. En estos casos, las opciones de configuración de redes de Autopilot pueden ayudarte a gestionar y controlar las interacciones entre servicios.

Escalabilidad horizontal y vertical

Cloud Run y Autopilot de GKE admiten el escalado horizontal manual y automático de servicios y tareas. El escalado horizontal proporciona una mayor potencia de procesamiento cuando es necesario y elimina la potencia de procesamiento adicional cuando no se necesita. En el caso de una carga de trabajo habitual, Cloud Run suele poder escalar horizontalmente más rápido que GKE Autopilot para responder a los picos en el número de solicitudes por segundo. Por ejemplo, en la demostración en vídeo "Novedades de la computación sin servidor" muestra el escalado de Cloud Run de cero a más de 10.000 instancias en aproximadamente 10 segundos. Para aumentar la velocidad del escalado horizontal en Kubernetes (con un coste adicional), Autopilot te permite proporcionar capacidad de computación adicional.

Si tu aplicación no puede escalar añadiendo más instancias para aumentar el nivel de recursos disponibles, puede que Autopilot sea una opción más adecuada. Autopilot admite el escalado vertical para variar dinámicamente la cantidad de potencia de procesamiento disponible sin aumentar el número de instancias en ejecución de la aplicación.

Cloud Run puede reducir automáticamente el número de réplicas de tus aplicaciones a cero cuando no se estén usando, lo que resulta útil en determinados casos prácticos en los que se presta especial atención a la optimización de costes. Debido a las características de cómo pueden escalar tus aplicaciones a cero, hay varios pasos de optimización que puedes seguir para minimizar el tiempo que transcurre entre la llegada de una solicitud y el momento en el que tu aplicación está operativa y puede procesar la solicitud.

Compatibilidad con aplicaciones con reconocimiento del estado

Autopilot ofrece compatibilidad completa con volúmenes de Kubernetes, respaldada por discos persistentes que te permiten ejecutar una amplia gama de implementaciones con estado, incluidas bases de datos autogestionadas. Tanto Cloud Run como GKE Autopilot te permiten conectarte con otros servicios, como Filestore y los segmentos de Cloud Storage. Ambos incluyen la posibilidad de montar segmentos de almacenamiento de objetos en el sistema de archivos con Cloud Storage FUSE.

Cloud Run usa un sistema de archivos en memoria, que puede no ser adecuado para las aplicaciones que requieren un sistema de archivos local persistente. Además, el sistema de archivos local en memoria se comparte con la memoria de tu aplicación. Por lo tanto, tanto el sistema de archivos efímero como el uso de memoria de la aplicación y del contenedor contribuyen a agotar el límite de memoria. Puedes evitar este problema si usas un volumen en memoria dedicado con un límite de tamaño.

Un contenedor de servicio o de trabajo de Cloud Run tiene un tiempo de espera de la tarea máximo. Un contenedor que se ejecuta en un pod de un clúster de Autopilot se puede reprogramar, sujeto a las restricciones que se hayan configurado con presupuestos de interrupción de pods (PDBs). Sin embargo, los pods pueden ejecutarse hasta siete días cuando están protegidos contra el desalojo causado por las actualizaciones automáticas de los nodos o por eventos de reducción de escala. Normalmente, el tiempo de espera de las tareas es más probable que se tenga en cuenta en las cargas de trabajo por lotes en Cloud Run. En el caso de las cargas de trabajo de larga duración y las tareas por lotes que no se pueden completar en el plazo máximo, Autopilot puede ser la mejor opción.

Arquitectura de CPU

Todas las plataformas de computación Google Cloud admiten la arquitectura de CPU x86. Cloud Run no admite procesadores con arquitectura Arm, pero Autopilot sí admite nodos gestionados que tienen una arquitectura Arm. Si tu carga de trabajo requiere la arquitectura Arm, tendrás que usar Autopilot.

Descarga del acelerador

Autopilot admite el uso de GPUs y TPUs, incluido el consumo de recursos reservados. Cloud Run admite el uso de GPUs con algunas limitaciones.

Requisitos elevados de memoria, CPU y otros recursos

En comparación con los límites de solicitudes de recursos de Autopilot de GKE, los recursos máximos de CPU y memoria que puede consumir un solo servicio o trabajo de Cloud Run (una sola instancia) están limitados. En función de las características de tus cargas de trabajo, Cloud Run puede tener otros límites que restrinjan los recursos disponibles. Por ejemplo, el tiempo de espera de inicio y el número máximo de conexiones salientes pueden estar limitados en Cloud Run. Con Autopilot, es posible que algunos límites no se apliquen o que tengan valores permitidos más altos.

Dependencia explícita de Kubernetes

Algunas aplicaciones, bibliotecas o frameworks pueden tener una dependencia explícita de Kubernetes. La dependencia de Kubernetes puede deberse a uno de los siguientes motivos:

  1. Los requisitos de la aplicación (por ejemplo, si la aplicación llama a las APIs de Kubernetes o usa recursos personalizados de Kubernetes).
  2. Los requisitos de las herramientas que se usan para configurar o desplegar la aplicación (como Helm).
  3. Los requisitos de asistencia de un creador o proveedor externo.

En estos casos, Autopilot es el entorno de ejecución de destino, ya que Cloud Run no es compatible con Kubernetes.

RBAC complejo para la multitenencia

Si tu organización tiene estructuras organizativas especialmente complejas o requisitos de multitenencia, utiliza Autopilot para aprovechar el control de acceso basado en roles (RBAC) de Kubernetes. Si prefieres una opción más sencilla, puedes usar las funciones de seguridad y segregación integradas en Cloud Run.

Consideraciones organizativas

A continuación, se indican algunos aspectos organizativos que influirán en tu elección del entorno:

  • Estrategia técnica general: la dirección técnica de tu organización.
  • Aprovechar el ecosistema de Kubernetes: interés en aprovechar la comunidad de software libre.
  • Herramientas internas: uso habitual de determinadas herramientas.
  • Perfiles del equipo de desarrollo: conjunto de habilidades y experiencia de los desarrolladores.
  • Asistencia operativa: capacidades y objetivos de los equipos de operaciones.

En las siguientes secciones se detallan estas consideraciones organizativas para ayudarte a elegir un entorno.

Estrategia técnica general

Las organizaciones o los equipos pueden haber acordado estrategias para preferir determinadas tecnologías sobre otras. Por ejemplo, si un equipo tiene un acuerdo para estandarizar, en la medida de lo posible, un entorno sin servidor o Kubernetes, ese acuerdo podría influir o incluso determinar un entorno de ejecución de destino.

Si una carga de trabajo determinada no se adapta bien al entorno de tiempo de ejecución especificado en la estrategia, puedes hacer una o varias de las siguientes acciones, con las advertencias correspondientes:

  • Rediseña la carga de trabajo. Sin embargo, si la carga de trabajo no es adecuada, puede que el rendimiento, el coste, la seguridad u otras características no sean óptimos.
  • Registra la carga de trabajo como excepción a la estrategia. Sin embargo, si se abusa de las excepciones, se puede generar una cartera de tecnología dispar.
  • Reconsidera la estrategia. Sin embargo, si lo haces, se puede producir una sobrecarga de políticas que impida o bloquee el progreso.

Aprovechar el ecosistema de Kubernetes

Como parte de la estrategia técnica general descrita anteriormente, las organizaciones o los equipos pueden decidir seleccionar Kubernetes como su plataforma preferida debido al importante y creciente ecosistema. Esta opción es distinta de la de seleccionar Kubernetes debido a las dependencias técnicas de las aplicaciones, tal como se describe en la sección anterior Dependencia explícita de Kubernetes. El uso del ecosistema de Kubernetes se centra en una comunidad activa, herramientas de terceros completas y estándares y portabilidad sólidos. Aprovechar el ecosistema de Kubernetes puede acelerar el desarrollo y reducir el tiempo de lanzamiento.

Herramientas internas

En algunos casos, puede ser ventajoso usar ecosistemas de herramientas que ya tengas en tu organización o equipo (para cualquiera de los entornos). Por ejemplo, si usas Kubernetes, puedes seguir usando herramientas de implementación como ArgoCD, herramientas de seguridad y políticas como Gatekeeper y gestión de paquetes como Helm. Las herramientas actuales pueden incluir reglas establecidas para la automatización del cumplimiento de la organización y otras funciones que pueden ser costosas o requerir mucho tiempo para implementarse en un entorno de destino alternativo.

Perfiles del equipo de desarrollo

Un equipo de aplicaciones o cargas de trabajo puede tener experiencia previa con Kubernetes, lo que puede acelerar la velocidad y la capacidad del equipo para ofrecer resultados con Autopilot. Un equipo puede tardar en dominar un nuevo entorno de ejecución. En función del modelo operativo, esto puede provocar una menor fiabilidad de la plataforma durante el periodo de mejora de las habilidades.

En el caso de un equipo en crecimiento, la capacidad de contratación puede influir en la elección de la plataforma por parte de la organización. En algunos mercados, las habilidades de Kubernetes pueden ser escasas y, por lo tanto, requieren una prima de contratación. Elegir un entorno como Cloud Run puede ayudarte a agilizar el proceso de contratación y a que tu equipo crezca más rápido sin salirse del presupuesto.

Asistencia operativa

Cuando elijas un entorno de tiempo de ejecución, ten en cuenta la experiencia y las capacidades de tus equipos de SRE, DevOps y plataformas, así como de otros miembros del personal operativo. Las capacidades de los equipos operativos para dar asistencia eficaz al entorno de producción son cruciales desde el punto de vista de la fiabilidad. También es fundamental que los equipos operativos puedan dar soporte a los entornos de preproducción para asegurarse de que la velocidad de los desarrolladores no se vea obstaculizada por el tiempo de inactividad, la dependencia de procesos manuales o los engorrosos mecanismos de implementación.

Si usas Kubernetes, un equipo central de operaciones o de ingeniería de plataformas puede gestionar las actualizaciones de Autopilot de Kubernetes. Aunque las actualizaciones son automáticas, el personal operativo suele monitorizarlas de cerca para minimizar las interrupciones en tus cargas de trabajo. Algunas organizaciones prefieren actualizar manualmente las versiones del plano de control. GKE Enterprise también incluye funciones para optimizar y simplificar la gestión de aplicaciones en varios clústeres.

A diferencia de Autopilot, Cloud Run no requiere gastos de gestión ni actualizaciones del plano de control. Con Cloud Run, puedes simplificar tus procesos operativos. Si seleccionas un solo entorno de ejecución, puedes simplificar aún más tus procesos operativos. Si decides usar varios entornos de ejecución, debes asegurarte de que el equipo tenga la capacidad, las funciones y el interés necesarios para admitir esos entornos.

Selección

Para iniciar el proceso de selección, habla con los distintos participantes. Para cada aplicación, reúne a un grupo de trabajo formado por desarrolladores, personal operativo, representantes de cualquier grupo central de gobernanza tecnológica, usuarios y consumidores internos de la aplicación, equipos de seguridad y de optimización financiera en la nube, y otros roles o grupos de tu organización que puedan ser relevantes. Puedes enviar una encuesta para recoger información y recopilar las características de las solicitudes, así como compartir los resultados antes de la sesión. Te recomendamos que elijas un grupo de trabajo pequeño que incluya solo a las partes interesadas necesarias. Puede que no se requiera la presencia de todos los representantes en todas las sesiones de trabajo.

También puede resultarte útil incluir a representantes de otros equipos o grupos que tengan experiencia en crear y ejecutar aplicaciones en Autopilot o Cloud Run, o en ambos. Usa las consideraciones técnicas y organizativas de este documento para guiar la conversación y evaluar la idoneidad de tu aplicación para cada una de las plataformas potenciales.

Te recomendamos que programes una revisión después de unos meses para confirmar o reconsiderar la decisión en función de los resultados de la implementación de tu aplicación en el nuevo entorno.

Siguientes pasos

Colaboradores

Autor: Henry Bell | Arquitecto de soluciones en la nube

Otros colaboradores: