Selecciona un entorno de ejecución de contenedor administrado

Last reviewed 2024-08-30 UTC

Este documento te ayuda a evaluar los requisitos de tu aplicación y elegir entre Cloud Run y Autopilot de Google Kubernetes Engine (GKE) según las consideraciones técnicas y organizativas. Este documento está dirigido a los arquitectos de la nube que necesitan elegir un entorno de ejecución de contenedores de destino de Google Cloud para sus cargas de trabajo. Se supone que estás familiarizado con Kubernetes y Google Cloud, y que tienes conocimientos de entornos de ejecución sin servidores en la nube, como Cloud Run, las funciones de Cloud Run o AWS Lambda.

Google Cloud ofrece varias opciones de entornos de ejecución que tienen una variedad de capacidades. En el siguiente diagrama, se muestra el rango de ofertas administradas de Google Cloud:

Ofertas de Google Cloud, de la más administrada a la menos administrada.

En el diagrama se muestra lo siguiente:

  • Los entornos de ejecución más administrados (el enfoque de esta guía):

    Google administra estas opciones, sin administración de la infraestructura de procesamiento subyacente por parte de usuarios.

  • Los entornos de ejecución menos administrados:

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

    Estas opciones requieren cierto grado de administración de la infraestructura a nivel del usuario, como las máquinas virtuales (VMs) que sustentan las capacidades de procesamiento. 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 según tus requisitos.

Mediante esta guía, obtendrás ayuda para elegir entre los entornos de ejecución más administrados, Cloud Run y GKE Autopilot. Para obtener una vista más amplia de los entornos de ejecución de Google Cloud, consulta la guía Opciones de hosting de aplicaciones de Google Cloud.

Descripción general de los entornos

En esta sección, se proporciona una descripción general de las funciones de Cloud Run y GKE Autopilot. Cloud Run y GKE Autopilot están estrechamente integrados en Google Cloud, por lo que hay muchos puntos en común entre ambos. Ambas plataformas admiten varias opciones para el balanceo de cargas con los servicios de balanceo de cargas altamente confiables y escalables de Google. También admiten Herramientas de redes de VPC, Identity-Aware Proxy (IAP) yGoogle Cloud Armor para cuando se requiera una red privada más detallada. Ambas plataformas solo te cobran por los recursos exactos que usas para tus aplicaciones.

Desde una perspectiva de entrega de software, como entornos de ejecución de contenedores, Cloud Run y GKE Autopilot son compatibles con los servicios que conforman el ecosistema de contenedores de Google Cloud. Entre estos servicios, se incluyen los siguientes: Cloud Build, Artifact Registry, Autorización binaria y entrega continua conCloud Deploy, para ayudar a garantizar que tus aplicaciones se implementen de forma segura y confiable en producción. Esto significa que tú y tus equipos son propietarios de las decisiones de compilación y de implementación.

Debido a las similitudes entre las dos plataformas, te recomendamos que aproveches las fortalezas de cada una adoptando un enfoque flexible para implementar tus aplicaciones, como se detalla en la guía Usa GKE y Cloud Run en conjunto. En las siguientes secciones, se describen aspectos únicos de Cloud Run y Autopilot.

Cloud Run

Cloud Run es una plataforma de procesamiento administrada sin servidores que te permite ejecutar tus aplicaciones directamente sobre la infraestructura escalable de Google. Cloud Run proporciona automatización y escalamiento para dos tipos principales de aplicaciones:

Con estos dos modelos de implementación, Cloud Run puede admitir una amplia variedad de arquitecturas de aplicaciones y, al mismo tiempo, habilitar las prácticas recomendadas y permitir que los desarrolladores se enfoquen en el código.

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

  • Funciones ligeras individuales
  • Aplicaciones completas desde el código fuente
  • Aplicaciones alojadas en contenedores

Cloud Run incorpora una función de compilación e implementación que admite FaaS y la capacidad de compilar desde la fuente, junto con la función de entorno de ejecución de contenedor compilado previamente. Cuando usas Cloud Run de esta manera, los pasos para compilar e implementar la imagen de contenedor de la aplicación que se ejecutará son automáticos, y no se necesita que apliques una configuración personalizada.

GKE Autopilot

GKE Autopilot es el modo de operación predeterminado y recomendado del clúster en GKE. Autopilot te permite ejecutar aplicaciones en Kubernetes sin la sobrecarga de administrar la infraestructura. Cuando usas Autopilot, Google administra aspectos clave subyacentes de la configuración de tu clúster, incluido el aprovisionamiento y el escalamiento de los nodos, la postura de seguridad predeterminada y otros parámetros de configuración establecidos previamente. Con Autopilot administrando los recursos de los nodos, solo pagas por los recursos que solicitan tus cargas de trabajo. Autopilot supervisa y optimiza de forma continua los recursos de la infraestructura para garantizar la mejor opción y, al mismo tiempo, proporcionar un SLA para tus cargas de trabajo.

Autopilot de GKE admite cargas de trabajo que podrían no ser adecuadas para Cloud Run. Por ejemplo, Autopilot de GKE suele admitir cargas de trabajo con estado o de larga duración.

Elige un entorno de ejecución

En general, si las características de tu carga de trabajo son adecuadas para una plataforma administrada, el entorno de ejecución sin servidores de Cloud Run es ideal. El uso de Cloud Run puede significar usar menos infraestructura para administrar, menos configuración autoadministrada y, por lo tanto, una menor sobrecarga operativa. A menos que quieras o necesites Kubernetes de forma específica, te recomendamos que primero consideres un entorno de ejecución sin servidores como tu entorno de destino. Si bien Kubernetes proporciona la poderosa abstracción de una plataforma abierta, su uso agrega complejidad. Si no necesitas Kubernetes, te recomendamos que consideres si tu aplicación es una buena opción para la computación sin servidores. Si hay criterios que hacen que tu carga de trabajo sea menos adecuada para la arquitectura sin servidores, te recomendamos usar Autopilot.

En las siguientes secciones, se proporcionan más detalles sobre algunos de los criterios que pueden ayudarte a responder estas preguntas, en particular, la pregunta de si la carga de trabajo es adecuada para la arquitectura sin servidores. Debido a los puntos comunes entre Autopilot y Cloud Run que se describe en las secciones anteriores, la migración entre las plataformas es una tarea sencilla cuando no hay obstáculos técnicos u otros obstáculos. Para explorar las opciones de migración con más detalle, consulta Migra de Cloud Run a GKE y Migra de Kubernetes a Cloud Run.

Cuando elijas un entorno de ejecución para tu carga de trabajo, debes tener en cuenta las consideraciones técnicas y organizativas. Las consideraciones técnicas son características de tu aplicación o del entorno de ejecución de Google Cloud. Las consideraciones organizativas son características no técnicas de tu organización o equipo que podrían influir en tu decisión.

Consideraciones técnicas

Estas son algunas de las consideraciones técnicas que influirán en tu elección de plataforma:

  • Control y capacidad de configuración: Nivel de detalle del control del entorno de ejecución.
  • Administración y enrutamiento del tráfico de red: Posibilidad de configurar las interacciones en la red.
  • Escalabilidad horizontal y vertical: Compatibilidad con el crecimiento y la reducción de capacidad de forma dinámica.
  • Compatibilidad con aplicaciones con estado: Funciones para almacenar el estado persistente.
  • Arquitectura de la CPU: Compatibilidad con diferentes tipos de CPU.
  • Descarga de acelerador (GPU y TPU): Capacidad de transferir procesamiento para hardware dedicado.
  • Memoria alta, CPU y otras capacidades de recursos: El nivel de varios recursos consumidos.
  • Dependencia explícita en Kubernetes: Son los requisitos para el uso de la API de Kubernetes.
  • RBAC complejo para múltiples usuarios: compatibilidad para compartir recursos agrupados.
  • Tiempo máximo de tiempo de espera de la tarea del contenedor: Duración de la ejecución de las 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 configuración

En comparación con Cloud Run, el piloto automático de GKE proporciona un control más detallado del entorno de ejecución de tus cargas de trabajo. Dentro del contexto de un Pod, Kubernetes proporciona muchas primitivas configurables que puedes ajustar para satisfacer los requisitos de tu aplicación. Las opciones de configuración incluyen lo siguiente: nivel de privilegio, parámetros de calidad del servicio, controladores personalizados para eventos de ciclo de vida de contenedores y uso compartido compartido de espacios de nombres de procesos entre varios contenedores.

Cloud Run admite directamente un subconjunto de la superficie de la API de Pod de Kubernetes, que se describe en el YAML de referencia del objeto Service de Cloud Run y en el YAML de referencia del objeto Job 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 del contenedor para el entorno de ejecución de Cloud Run es relativamente sencillo y se adapta a la mayoría de las cargas de trabajo de entrega. Sin embargo, el contrato especifica algunos requisitos que se deben cumplir. Si tu aplicación o sus dependencias no pueden cumplir con esos requisitos o si necesitas un control más detallado sobre el entorno de ejecución, Autopilot podría ser más adecuado.

Si deseas reducir el tiempo que dedicas a la configuración y la administración, considera elegir Cloud Run como tu 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 la sobrecarga operativa.

Administración y enrutamiento del tráfico de red

Cloud Run y GKE Autopilot se integran en Google Cloud Load Balancing. Sin embargo, GKE Autopilot también proporciona un conjunto rico y potente de primitivas para configurar el entorno de red para las comunicaciones de servicio a servicio. Las opciones de configuración incluyen permisos detallados 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 de DNS integrado en el clúster. GKE Autopilot también admite la API de Gateway, que es altamente configurable y flexible. Esta funcionalidad proporciona un control potente sobre la forma en que se enruta el tráfico hacia los servicios del clúster y entre ellos.

Debido a que 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 la aplicación. Un ejemplo de este patrón es una aplicación distribuida que se descompone en varios microservicios que tienen patrones complejos de interdependencia. En esos casos, las opciones de configuración de redes de Autopilot pueden ayudarte a administrar y controlar las interacciones entre los servicios

Escalabilidad horizontal y vertical

Cloud Run y GKE Autopilot admiten el escalamiento horizontal manual y automático para servicios y trabajos. El escalamiento horizontal proporciona mayor potencia de procesamiento cuando se requiere y quita la potencia de procesamiento adicional cuando no se necesita. En el caso de una carga de trabajo típica, Cloud Run suele escalar más rápido que GKE Autopilot para responder a los aumentos repentinos en la cantidad de solicitudes por segundo. A modo de ejemplo, en el video de demostración “¿Cuáles son las novedades de la computación sin servidores?”, se muestra el escalamiento de Cloud Run de cero a más de 10,000 instancias en alrededor de 10 segundos. Para aumentar la velocidad del escalamiento horizontal en Kubernetes (con algún costo adicional), Autopilot te permite aprovisionar una capacidad de procesamiento adicional.

Si tu aplicación no puede escalar mediante la adición de más instancias para aumentar el nivel de recursos disponibles, podría ser una mejor opción para Autopilot. Autopilot admite el escalamiento vertical para variar de forma dinámica la cantidad de potencia de procesamiento disponible sin aumentar la cantidad de instancias en ejecución de la aplicación. }

Cloud Run puede escalar automáticamente tus aplicaciones hasta cero replicas mientras no se usan, lo que es útil para ciertos casos de uso que se enfocan especialmente en la optimización de costos. Debido a las características de cómo tus aplicaciones pueden escalar a cero, hay varios pasos de optimización que puedes seguir para minimizar el tiempo entre la llegada de una solicitud y el momento en que tu aplicación está en funcionamiento y puede procesar la solicitud.

Compatibilidad con aplicaciones con estado

Autopilot ofrece compatibilidad completa con volúmenes de Kubernetes, respaldados por discos persistentes que te permiten ejecutar una amplia variedad de implementaciones con estado, incluidas las bases de datos autoadministradas. Cloud Run y GKE Autopilot te permiten conectarte con otros servicios, como Filestore y los buckets de Cloud Storage. También incluyen la capacidad de activar buckets de almacenamiento de objetos en el sistema de archivos con Cloud Storage FUSE.

Cloud Run usa un sistema de archivos en la memoria, que podría no ser una buena opción para las aplicaciones que requieren un sistema de archivos local persistente. Además, el sistema de archivos en la memoria local 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 el 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 servicio o contenedor de trabajos de Cloud Run tiene un tiempo de espera de la tarea máximo. Un contenedor que se ejecuta dentro de un pod en un clúster de Autopilot se puede reprogramar, sujeto a cualquier restricción que se configure con los presupuestos de interrupción de Pods (PDB). Sin embargo, los pods pueden ejecutarse hasta por siete días cuando están protegidos de la expulsión causada por las actualizaciones automáticas de nodos o los eventos de reducción de escala. Por lo general, es más probable que el tiempo de espera de las tareas constituya un consideración para las cargas de trabajo por lotes en Cloud Run. Para las cargas de trabajo de larga duración y las tareas por lotes que no se pueden completar dentro de la duración máxima de la tarea, Autopilot podría ser la mejor opción.

Arquitectura de la CPU

Todas las plataformas de procesamiento de Google Cloud admiten la arquitectura de CPU x86. Cloud Run no admite procesadores de arquitectura Arm, pero Autopilot admite nodos administrados que están respaldados por la arquitectura Arm. Si tu carga de trabajo requiere arquitectura Arm, deberás usar Autopilot.

Descarga de acelerador

Autopilot admite el uso de GPUs y el uso de TPUs, incluida la capacidad de consumir recursos reservados. Cloud Run admite el uso de GPU con algunas limitaciones.

Requisitos altos de memoria, CPU y otros recursos

En comparación con los límites de solicitudes de recursos de GKE Autopilot, 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. Según 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 la cantidad máxima de conexiones salientes pueden estar limitados con Cloud Run. Con Autopilot, es posible que no se apliquen algunos límites o que tengan valores permitidos más altos.

Dependencia explícita en Kubernetes

Es posible que algunas aplicaciones, bibliotecas o frameworks tengan una dependencia explícita en Kubernetes. La dependencia de Kubernetes puede ser el resultado de uno de los siguientes casos:

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

En estas situaciones, Autopilot es el entorno de ejecución objetivo porque Cloud Run no es compatible con Kubernetes.

RBAC complejo para múltiples usuarios

Si tu organización tiene estructuras organizativas o requisitos particularmente complejos para múltiples usuarios, usa Autopilot a fin de que puedas aprovechar el control de acceso basado en roles (RBAC) de Kubernetes. Para obtener una opción más sencilla, puedes usar las funciones de seguridad y segregación integradas en Cloud Run.

Consideraciones organizativas

Las siguientes son algunas de las consideraciones organizativas que influirán en tu elección del entorno:

  • Estrategia técnica general: Es la dirección técnica de tu organización.
  • Aprovechar el ecosistema de Kubernetes: interés en aprovechar la comunidad de OSS.
  • Herramientas internas existentes: Uso actual de ciertas herramientas.
  • Perfiles del equipo de desarrollo: Habilidades y experiencia de los desarrolladores.
  • Asistencia operativa: las capacidades y el enfoque de los equipos de operaciones.

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

Estrategia técnica amplia

Es posible que las organizaciones o los equipos hayan acordado estrategias para preferir ciertas tecnologías en lugar de otras. Por ejemplo, si un equipo tiene un acuerdo para estandarizar siempre que sea posible en un entorno sin servidores o Kubernetes, ese acuerdo podría influir o incluso determinar un entorno de ejecución de destino.

Si una carga de trabajo determinada no es adecuada para el entorno de ejecución que se especifica en la estrategia, puedes decidir hacer una o más de las siguientes acciones, con las advertencias que se incluyen:

  • Vuelve a diseñar la carga de trabajo. Sin embargo, si la carga de trabajo no es una buena opción, hacerlo puede generar rendimiento, costo, seguridad o características no óptimos.
  • Registra la carga de trabajo como una excepción a la dirección estratégica. Sin embargo, si se abusa de las excepciones, se puede generar una cartera de tecnología dispar.
  • Reconsidera la estrategia. Sin embargo, hacerlo puede generar una sobrecarga de la política que puede impedir o bloquear el progreso.

Aprovecha el ecosistema de Kubernetes

Como parte de la amplia estrategia técnica que se describió anteriormente, las organizaciones o los equipos pueden seleccionar Kubernetes como su plataforma de preferencia debido al ecosistema significativo y en crecimiento. Esta opción es distinta de la selección de Kubernetes debido a las dependencias técnicas de la aplicación, como se describe en la sección anterior Dependencia explícita de Kubernetes. La consideración de usar el ecosistema de Kubernetes hace hincapié en una comunidad activa, herramientas de terceros enriquecidas, estándares y portabilidad sólidos. Aprovechar el ecosistema de Kubernetes puede acelerar tu velocidad de desarrollo y reducir el tiempo de salida al mercado.

Herramientas internas existentes

En algunos casos, puede ser ventajoso usar los ecosistemas de herramientas existentes en tu organización o equipo (para cualquiera de los entornos) Por ejemplo, si usas Kubernetes, puedes optar por seguir usando herramientas de implementación, como ArgoCD, herramientas de seguridad y políticas, como Gatekeeper, y administración de paquetes, como Helm. Las herramientas existentes pueden incluir reglas establecidas para la automatización del cumplimiento de la organización y otras funciones que pueden ser costosas o requerir un largo tiempo de preparación 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 que puede acelerar la velocidad y la capacidad del equipo para entregar en Autopilot. Puede llevar tiempo que un equipo domine un nuevo entorno de ejecución. Según el modelo operativo, hacerlo puede generar una menor confiabilidad de la plataforma durante el período de mejora.

En el caso de un equipo en crecimiento, la capacidad de contratación puede influir en la elección de la plataforma de una organización. En algunos mercados, las habilidades de Kubernetes pueden ser escasas y, por lo tanto, exigen un recargo de contratación. Elegir un entorno como Cloud Run puede ayudarte a optimizar el proceso de contratación y permitir un crecimiento más rápido del equipo según tu presupuesto.

Asistencia operativa

Cuando elijas un entorno de ejecución, considera la experiencia y las capacidades de los equipos de SRE, DevOps y plataformas, y otro personal de operaciones. Las capacidades de los equipos operativos para brindar asistencia al entorno de producción de forma eficaz son fundamentales desde la perspectiva de la confiabilidad. También es fundamental que los equipos operativos puedan admitir entornos de preproducción para garantizar que la velocidad de los desarrolladores no se vea afectada por el tiempo de inactividad, la dependencia de los procesos manuales o los mecanismos de implementación complejos.

Si usas Kubernetes, un equipo central de ingeniería de plataforma o de operaciones puede controlar las actualizaciones de Kubernetes de Autopilot. Aunque las actualizaciones son automáticas, el personal operativo suele supervisarlas de cerca para garantizar que haya interrupciones mínimas en tus cargas de trabajo. Algunas organizaciones eligen actualizar las versiones del plano de control de forma manual. GKE Enterprise también incluye funciones para optimizar y simplificar la administración de aplicaciones en varios clústeres.

A diferencia de Autopilot, Cloud Run no requiere una sobrecarga de administración continua ni actualizaciones del plano de control. Con Cloud Run, puedes simplificar los procesos de operaciones. 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 para admitir esos entornos de ejecución.

Selección

Para comenzar el proceso de selección, habla con las diversas partes interesadas. Para cada aplicación, reúne un grupo de trabajo que conste de desarrolladores, personal operativo, representantes de cualquier grupo central de administración de tecnología, usuarios y consumidores internos de la aplicación, seguridad, equipos de optimización financiera de la nube y otros puestos o grupos dentro de tu organización que puedan ser relevantes. Puedes distribuir una encuesta de recopilación de información para recopilar las características de la aplicación y compartir los resultados antes de la sesión. Te recomendamos que selecciones un grupo de trabajo pequeño que incluya solo las partes interesadas necesarias. Es posible que no se requieran todos los representantes para cada sesión de trabajo.

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

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

¿Qué sigue?

Colaboradores

Autor: Henry Bell | Arquitecto de Soluciones de Cloud

Otros colaboradores: