Evaluación automática de código con Agent Sandbox en GKE

1. Introducción

En este codelab, implementarás la aplicación Hackathon Judge en Google Kubernetes Engine (GKE) y usarás Kubernetes-sigs Agent Sandbox para ejecutar cargas de trabajo basadas en agentes de forma segura.

La plataforma está diseñada para automatizar el proceso de revisión, prueba y calificación de los proyectos de hackatones con agentes de LLM. Dado que la evaluación requiere analizar envíos de código de participantes no confiables, es fundamental contar con una zona de pruebas de ejecución segura para evitar la inyección de código, la elevación de privilegios o el abuso de recursos.

Actividades

  • Aprovisiona los servicios de Google Cloud de destino y establece las APIs de destino.
  • Inicializa GKE Autopilot y, luego, instala los CRD de Agent Sandbox, las configuraciones del clúster y el enrutador de Sandbox.
  • Implementa la puerta de enlace de zona de pruebas, la plantilla de reclamo de zona de pruebas y un WarmPool de zona de pruebas.
  • Implementa la API de backend de REST, el agente trabajador de evaluación del ADK y la IU de frontend de React.
  • Conecta el enrutamiento externo con balanceo de cargas y accede a la plataforma para ejecutar flujos de trabajo de evaluación seguros en un entorno de pruebas.

Requisitos

  • Un navegador web, como Chrome
  • Un proyecto de Google Cloud con facturación habilitada.

Los recursos creados en este codelab deberían costar menos de USD 5 en cargos totales por tiempo de ejecución.

2. El problema: Evaluación segura de código no confiable

Los hackatones son eventos de innovación de ritmo rápido en los que los participantes crean y envían proyectos (a menudo, con código fuente) para su evaluación. Evaluar manualmente estas presentaciones requiere mucho tiempo y recursos. Usar agentes de IA para automatizar la calificación es una solución prometedora, pero presenta un desafío de seguridad importante: ¿cómo ejecutar de forma segura el código proporcionado por los participantes que podría ser defectuoso, malicioso o consumir muchos recursos?

Ejecutar código no confiable directamente en tu infraestructura te expone a riesgos como los siguientes:

  • Inyección de código: Los scripts maliciosos podrían intentar acceder a datos sensibles o modificarlos.
  • Elevación de privilegios: Es posible que el código intente obtener acceso no autorizado a otros sistemas o recursos de red.
  • Abuso de recursos: El código mal escrito o los ataques de denegación de servicio podrían consumir una cantidad excesiva de CPU, memoria o ancho de banda de red, lo que afectaría otras operaciones.

Para automatizar la evaluación de hackathons con IA, necesitamos una forma de ejecutar el código enviado en un entorno completamente aislado del resto de nuestro sistema y de otros envíos.

3. La solución: GKE Agent Sandbox

GKE Agent Sandbox es una función diseñada para este desafío específico. Ayuda a administrar cargas de trabajo aisladas, con estado y de una sola réplica en GKE, y está optimizado para casos de uso como los tiempos de ejecución de agentes de IA, en los que el código no confiable debe ejecutarse de forma segura y eficiente.

Estos son algunos de los beneficios clave de Agent Sandbox:

  • Aislamiento a nivel del kernel: Proporciona un aislamiento sólido a nivel del kernel para el código no confiable con tecnologías como gVisor, lo que impide que el código acceda al sistema host o a otros contenedores.
  • Aprovisionamiento en menos de un segundo: Ofrece un aprovisionamiento rápido de entornos de zona de pruebas (por lo general, menos de 1 s), lo que es fundamental para la evaluación de código a pedido.
  • Extensibilidad nativa de la nube: Aprovecha el poder de Kubernetes y la infraestructura administrada de GKE.

Con Agent Sandbox, podemos crear entornos aislados y a pedido para cada envío del hackathon. Luego, el agente de evaluación de IA puede indicarle a Agent Sandbox que ejecute pruebas, compile código o realice otros pasos de evaluación dentro de esta zona de pruebas segura sin poner en riesgo la integridad de la plataforma general. Esto proporciona una forma escalable, segura y eficiente de automatizar la calificación de hackatones.

4. Antes de comenzar

Inicie Cloud Shell

Haz clic en el siguiente botón para iniciar Google Cloud Shell, que ya viene preconfigurado con las utilidades de línea de comandos necesarias para desarrolladores y la nube.

Habilita las APIs

Ejecuta el siguiente comando en Cloud Shell para habilitar todas las APIs de Google Cloud de destino necesarias para ejecutar la plataforma:

gcloud services enable \
  container.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  pubsub.googleapis.com \
  aiplatform.googleapis.com \
  cloudresourcemanager.googleapis.com \
  iam.googleapis.com \
  bigquery.googleapis.com \
  bigqueryconnection.googleapis.com

Por qué habilitamos estas APIs: Los servicios de Google Cloud están inhabilitados de forma predeterminada para evitar cargos y accesos no autorizados. Habilitamos estas APIs específicas para activar la organización de contenedores (GKE), el almacenamiento seguro de contenedores (Artifact Registry), el empaquetado de compilaciones sin servidores (Cloud Build), las filas de mensajes confiables (Pub/Sub), los servicios de modelos de IA (Vertex AI), la configuración de proyectos (Cloud Resource Manager y IAM), el análisis de datos sin servidores (BigQuery) y las vinculaciones de IA a nivel de la base de datos (conexión de BigQuery).

5. Configura la infraestructura

En este paso, clonarás el repositorio de código y ejecutarás la secuencia de comandos de configuración automatizada para implementar la arquitectura de nube de destino y los componentes del clúster de referencia.

Clona el repositorio

Clona el repositorio que contiene todos los servicios de la aplicación, las secuencias de comandos de configuración y las declaraciones de manifiesto de Kubernetes:

git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos.git
cd devrel-demos
git sparse-checkout set codelabs/ai-toolkit-lab-2/hackathon-judge
cd codelabs/ai-toolkit-lab-2/hackathon-judge

Ejecutar secuencia de comandos de implementación

La configuración básica de tus recursos de nube, modelos de bases de datos y políticas de referencia del clúster de Kubernetes se automatiza con la secuencia de comandos deploy.sh.

Ejecuta la secuencia de comandos:

./deploy.sh

Sigue las indicaciones interactivas de la shell para proporcionar configuraciones como el ID del proyecto activo y la región objetivo. La secuencia de comandos genera automáticamente una configuración .env local, vincula recursos, compila imágenes de contenedor y registra la infraestructura de referencia de GKE.

Estas son las operaciones objetivo que realiza la secuencia de comandos:

1. Configuración del entorno

La secuencia de comandos crea un archivo de configuración .env para almacenar los parámetros de las variables de GKE, Pub/Sub, BigQuery y del proyecto. El abastecimiento de este archivo propaga de forma dinámica todas las definiciones posteriores del manifiesto de Kubernetes.

Por qué configuramos este archivo de entorno: El archivo .env centraliza los parámetros de configuración, lo que garantiza que los manifiestos de GKE que aplicamos manualmente en los pasos posteriores usen la misma configuración regional, los mismos nombres de proyectos y los mismos recursos, y desacopla estrictamente la configuración del entorno del código fuente.

2. Configuración de Google Cloud CLI y del proyecto de destino

La secuencia de comandos verifica que las utilidades gcloud, bq, kubectl y envsubst estén instaladas, comprueba el estado de autenticación y fija los destinos de configuración activos en tu proyecto de Google Cloud activo.

Por qué segmentamos los proyectos activos: Establecer el proyecto objetivo activo evita que los comandos de la CLI afecten a otros proyectos de tu cuenta y realiza verificaciones de autenticación previas al vuelo, lo que garantiza que los comandos de configuración no fallen a mitad de la implementación debido a credenciales no válidas.

3. Habilita las APIs de Google Cloud de destino

La secuencia de comandos realiza una verificación idempotente para verificar y habilitar las APIs de los servicios de destino de Google Cloud (GKE, Artifact Registry, Cloud Build, Pub/Sub, Vertex AI, BigQuery y IAM).

Por qué habilitamos las APIs de Google Cloud: Los servicios administrados en la nube deben activarse antes de que se pueda acceder a sus extremos o crear recursos. Habilitarlas al principio prepara la puerta de enlace de la API de GCP regional para controlar los comandos de aprovisionamiento de recursos posteriores.

4. Aprovisiona el repositorio de Docker de Artifact Registry

La secuencia de comandos aprovisiona un repositorio de contenedores de Docker llamado hackathon-judge-repo en la ubicación de destino seleccionada.

Por qué creamos un repositorio de Artifact Registry: Los clústeres de GKE requieren acceso seguro a registros de contenedores privados en la misma red regional para extraer imágenes de aplicaciones rápidamente. Artifact Registry proporciona un host privado y seguro para catalogar, analizar y almacenar imágenes de contenedores de Docker.

5. Aprovisionamiento del clúster de GKE Autopilot

La secuencia de comandos aprovisiona un clúster de Google Kubernetes Engine (GKE) Autopilot llamado hackathon-judge-cluster.

Por qué implementamos un clúster de GKE Autopilot: GKE Autopilot administra automáticamente el aprovisionamiento, el escalamiento, la supervisión del estado y las actualizaciones de seguridad del SO host de los nodos. Proporciona una plataforma de contenedores de nivel de producción para organizar nuestros servicios persistentes y programa de forma dinámica zonas de pruebas seguras para trabajadores según demanda.

6. Configura temas y suscripciones de Pub/Sub

La secuencia de comandos aprovisiona los temas de mensajes (judging-tasks y judging-results) junto con sus suscripciones correspondientes a la API y al trabajador.

Por qué implementamos temas y suscripciones de Pub/Sub: Evaluar los envíos de código es un proceso lento y que requiere muchos recursos. El uso de una arquitectura de filas de mensajes desacopla la API síncrona orientada al usuario de los nodos de procesamiento. El backend de la API envía trabajos al tema judging-tasks, y los agentes trabajadores extraen tareas a medida que están disponibles, lo que evita el bloqueo de la API y proporciona capacidades de reintento automático.

7. Configura conjuntos de datos, tablas y conexiones de IA de BigQuery

La secuencia de comandos crea el conjunto de datos hackathon_judge, aplica esquemas de bases de datos SQL estructurales, carga registros iniciales y otorga los roles de almacenamiento y de AA necesarios a la cuenta de servicio de conexión de BigQuery ML.

8. Cómo activar compilaciones de contenedores con Cloud Build

La secuencia de comandos activa la definición de cloudbuild.yaml para compilar nuestra IU de React, el servidor REST de Go, el trabajador del ADK de Python y el entorno de pruebas de FastAPI, y los empaqueta en imágenes de contenedor aisladas etiquetadas con el SHA de la confirmación de Git del repositorio activo y los guarda en Artifact Registry.

9. Registro de definiciones de recursos personalizados (CRD) de Agent Sandbox

La secuencia de comandos descarga y registra las definiciones de recursos personalizadas (manifest.yaml y extensions.yaml) de Agent Sandbox de Kubernetes-sigs más recientes para extender las capacidades principales de GKE.

Por qué instalamos la infraestructura de Agent Sandbox: Los clústeres estándar de Kubernetes no admiten la asignación de zonas de pruebas protegidas a pedido. El registro de CRD de Agent Sandbox extiende el plano de control de GKE, lo que permite que Kubernetes coordine de forma nativa microcontenedores seguros en zona de pruebas con recursos personalizados (como SandboxTemplates y SandboxClaims).

10. Configura espacios de nombres, cuentas de servicio y Workload Identity

La secuencia de comandos aprovisiona el espacio de nombres hackathon-judge, registra las cuentas de servicio de Kubernetes (KSA) y establece asignaciones de Workload Identity para otorgar a los Pods de GKE permisos de destino de Google Cloud.

11. Implementa el enrutador de zona de pruebas

La secuencia de comandos aplica el manifiesto k8s/sandbox_router.yaml, inicia la implementación y el servicio del enrutador de zona de pruebas, y espera a que alcancen un estado correcto.

Por qué implementamos el enrutador de zona de pruebas: El enrutador de zona de pruebas es la puerta de enlace central interna del plano de control. Expone una API simple a la que llama el agente trabajador de evaluación del ADK para reclamar, acceder o liberar zonas de pruebas seguras, administrar las asignaciones de enrutamiento y abstraer la asignación de Pods a nivel del clúster de la lógica de la aplicación.

6. Configura Agent Sandbox Gateway, Claims y WarmPool

En este paso, configurarás manualmente la puerta de enlace de red especializada de la zona de pruebas, registrarás la plantilla de reclamo de la zona de pruebas y, luego, implementarás el WarmPool de la zona de pruebas para habilitar la zona de pruebas de latencia ultrabaja.

Variables de entorno de origen

Antes de aplicar plantillas que requieren variables de entorno, ejecuta el script setup-env.sh para analizar y exportar todas las variables necesarias a tu shell:

source ./setup-env.sh

Aplica Sandbox Gateway

Implementa la puerta de enlace configurada específicamente para enrutar el tráfico de la zona de pruebas:

kubectl apply -f k8s/sandbox-gateway.yaml

Por qué implementamos la puerta de enlace de zona de pruebas: La puerta de enlace de zona de pruebas actúa como el controlador de entrada seguro y de alto rendimiento dedicado exclusivamente al enrutamiento de la zona de pruebas. Aísla la red de la zona de pruebas, lo que proporciona un destino local seguro que permite que los agentes trabajadores se comuniquen con las zonas de pruebas reclamadas sin exponer los extremos de forma externa.

Aplica la plantilla de reclamo de zona de pruebas

Usa envsubst para propagar la definición de la plantilla de zona de pruebas con tus variables de entorno activas y aplícala:

source ./setup-env.sh
envsubst < k8s/sandbox-claim-template.yaml | kubectl apply -f -

Por qué implementamos la plantilla de reclamo de zona de pruebas: La plantilla de reclamo de zona de pruebas actúa como la configuración del plano que define el entorno. Especifica la imagen del contenedor que se ejecutará (preempaquetada con herramientas para desarrolladores), los parámetros del entorno (ID del proyecto de GCP), los puertos y los límites de recursos (objetivos de CPU/memoria). Configura GKE para ejecutar estas instancias de contenedor con gVisor (tiempo de ejecución de gVisor), lo que garantiza que el código de participantes no confiables se ejecute bajo una capa adicional de aislamiento de virtualización del kernel.

Aplica la zona de pruebas de WarmPool

Aplica el WarmPool de zona de pruebas para preinicializar las zonas de pruebas en ejecución:

kubectl apply -f k8s/sandbox-warmpool.yaml

Verifica que las instancias en espera del grupo de instancias en espera se hayan iniciado correctamente:

kubectl get pods -n hackathon-judge -l app=sandbox

Por qué implementamos el Sandbox WarmPool: El aprovisionamiento, la programación, la extracción de imágenes y el inicio de Pods de contenedores nuevos a pedido introducen una sobrecarga de inicio considerable (tiempos de inicio en frío de más de 30 segundos). El WarmPool de Sandbox mantiene un grupo de espera de pods de sandbox activos y precalentados (5 réplicas de forma predeterminada). Cuando el agente de trabajador solicita un entorno de evaluación, el enrutador de Sandbox asigna de inmediato un pod precalentado en ejecución, lo que reduce las demoras de inicio a velocidades inferiores a un segundo.

7. Implementa componentes de la aplicación

Con la infraestructura de zona de pruebas segura completamente activa, ahora implementarás la API central de backend, el agente de trabajador, la interfaz web de React y la asignación de la puerta de enlace de entrada.

Implementa el backend

Implementa el backend de la API de REST del orquestador:

source ./setup-env.sh
envsubst < k8s/backend.yaml | kubectl apply -f -

Implementar agente

Implementa el agente trabajador de evaluación del ADK:

source ./setup-env.sh
envsubst < k8s/agent.yaml | kubectl apply -f -

Implemente el frontend

Implementa la interfaz de usuario web interactiva:

source ./setup-env.sh
envsubst < k8s/frontend.yaml | kubectl apply -f -

Configura la puerta de enlace y el enrutamiento externos

Implementa la puerta de enlace principal y las rutas HTTP de entrada que asignan el tráfico de clientes externos:

kubectl apply -f k8s/gateway.yaml

Por qué implementamos la puerta de enlace de entrada externa: La puerta de enlace externa expone nuestros servicios con la API de Gateway de Kubernetes. Aprovisiona una dirección IP pública con balanceo de cargas y asigna rutas según reglas de ruta, lo que dirige las solicitudes de API en /api/* al backend de Go y asigna todo el tráfico web del cliente (/) al frontend de React, lo que protege el acceso público al clúster.

Verifica los lanzamientos

Bloquea la ejecución del shell y espera hasta que las tres implementaciones del servicio principal alcancen un estado de lanzamiento correcto y listo:

kubectl rollout status deployment/backend -n hackathon-judge --timeout=300s
kubectl rollout status deployment/agent -n hackathon-judge --timeout=300s
kubectl rollout status deployment/frontend -n hackathon-judge --timeout=300s

8. Verifica y usa la aplicación

Accede a la IU

Recupera la dirección IP pública externa de la puerta de enlace del balanceador de cargas principal aprovisionado recientemente:

Para observar el estado de aprovisionamiento en tiempo real, ejecuta el comando con la marca watch (-w) y espera hasta que se propague una dirección IP pública en el campo ADDRESS:

kubectl get gateway -n hackathon-judge hackathon-judge-gateway -w

Cuando se aprovisione correctamente, deberías ver un resultado similar al siguiente:

NAME                      CLASS    ADDRESS          PROGRAMMED   AGE
hackathon-judge-gateway   gke-l7   34.120.120.120   True         3m

Cuando veas una dirección IP pública válida en la columna ADDRESS y el estado PROGRAMMED sea True, presiona Ctrl+C para detener el reloj.

Por qué obtenemos el estado de Gateway: La API de Gateway controla la entrada pública. La verificación del estado de la puerta de enlace devuelve la dirección IP externa pública con balanceo de cargas que el balanceador de cargas externo global de Google Cloud asignó a nuestro clúster, lo que representa la dirección pública de nuestra plataforma.

Abre la dirección IP pública asignada en tu navegador para cargar el panel del juez del hackathon.

Envía tareas

  • Usa la IU de frontend para navegar al panel y seleccionar el hackathon.

Panel

  • En cualquiera de los proyectos, puedes hacer clic en Run Agent para que el agente evalúe todo el proyecto según la rúbrica.

Proyectos

Mira el inicio de la zona de pruebas

Supervisa los Pods activos dentro del espacio de nombres hackathon-judge para ver un Pod de zona de pruebas que se reclama y aprovisiona de forma dinámica para la ejecución de la evaluación:

kubectl get pods -n hackathon-judge -w

Verifica los registros del pod del agente trabajador para observar la lógica de evaluación del juicio del ADK paso a paso:

kubectl logs -l app=agent -n hackathon-judge

Por qué inspeccionamos los registros del agente: La inspección de los registros del agente de trabajador muestra los pasos internos detallados de la canalización de evaluación en tiempo real. Puedes hacer un seguimiento del agente del ADK que recupera la tarea, solicita un contenedor de zona de pruebas, ejecuta destinos de compilación, analiza informes con Gemini y publica cuadros de evaluación.

9. (Opcional) Cómo funciona

Arquitectura de la zona de pruebas de agentes

Si bien las funciones de IA de BigQuery son increíbles para evaluar las presentaciones basadas en texto y las afirmaciones de README, juzgar un proyecto de ingeniería requiere compilar código, instalar bibliotecas de terceros y ejecutar conjuntos de pruebas reales.

Ejecutar código de usuario sin procesar plantea riesgos de seguridad masivos, como la vulneración del host, la fuga de contenedores y el acceso no autorizado a los recursos. El framework de GKE Agent Sandbox mitiga estos riesgos mediante la organización de cargas de trabajo aisladas de Sandbox con la virtualización de gVisor (runsc).

Flujo de interacción del sistema

En el siguiente diagrama, se muestra cómo se comunican los distintos elementos de nuestro sistema basado en eventos durante una ejecución de evaluación segura en un entorno de pruebas:

Cómo funcionan en conjunto los componentes y las herramientas de participación

  • IU de frontend de React: Expone una interfaz interactiva en la que los usuarios configuran modelos de criterios, registran equipos, envían URLs de proyectos y revisan las tarjetas de puntuación finalizadas, incluidas las discrepancias de archivos completos y los comentarios de ingeniería.
  • API de backend de Go REST: Administra los extremos de API globales. Almacena la configuración del proyecto en BigQuery y envía trabajos de evaluación a Pub/Sub para desacoplar canalizaciones de ejecución computacional pesadas.
  • Google Pub/Sub: Es el agente orientado a mensajes que mantiene los mensajes de tareas de forma segura en la cola y coordina la comunicación de forma asíncrona entre la API y las instancias de trabajadores activos.
  • Worker de ADK de Python (agente supervisor): Es un worker en segundo plano que extrae tareas de Pub/Sub. Aprovecha el Kit de desarrollo de agentes (ADK) de Google para iniciar un agente supervisor de alto nivel, al que se le indica que coordine la evaluación. El supervisor invoca su herramienta principal, evaluate_repository, para delegar pruebas de comandos sin procesar detalladas.
  • Sandbox Router & Gateway (plano de control de GKE): Es una puerta de enlace de control interna que registra definiciones de recursos personalizados (CRD) de Sandbox estándar (SandboxClaims, SandboxTemplates). Coordina las redes de GKE para asignar y proteger pods, y devuelve flujos de conexión a los clientes trabajadores.
  • Sandbox WarmPool: Para evitar los largos tiempos de inicio de los contenedores de GKE (los "inicios en frío" de más de 30 segundos), WarmPool mantiene Pods en espera activos. Cuando se reclama un sandbox, el enrutador lo asigna de inmediato en menos de un segundo y, luego, programa el reciclaje cuando se libera.
  • Aislamiento de gVisor (runsc): Es un kernel virtual de espacio de usuario que actúa como límite seguro de zona de pruebas. Intercepta las llamadas al sistema desde el espacio del contenedor a los kernels de los nodos de GKE, lo que garantiza que los comandos sin procesar peligrosos (como las secuencias de comandos del sistema o la configuración de paquetes) se ejecuten bajo un aislamiento absoluto de virtualización.
  • Tiempo de ejecución de zona de pruebas de FastAPI: Es un servidor de API de Python ligero que se ejecuta dentro del contenedor de zona de pruebas. Expone extremos seguros (/execute, /upload, /download) que permiten que las herramientas de trabajadores externos manipulen archivos y activen tareas de shell.
  • Gemini CLI (@google/gemini-cli): Es un script de agente autónomo instalado dentro del sandbox. Cuando se activa con la marca de tiempo de ejecución del entorno de desarrollo (--yolo), usa una hoja de instrucciones de calificación rigurosa (prompt.md) y una definición de criterios (criteria.md) para hacer lo siguiente:
    • Analiza de forma dinámica la jerarquía de la base de código (con herramientas como tree o ripgrep).
    • Instalar automáticamente los requisitos (a través de comandos como npm install, pip install y go build)
    • Ejecuta pruebas de desarrollo reales (como npm test o pytest) para verificar la funcionalidad.
    • Llama a los modelos de Vertex AI (a través de las credenciales de vinculación de Workload Identity del contenedor) para evaluar la lógica de los archivos, verificar las afirmaciones con el archivo README, detectar funciones fantasma, registrar problemas de calidad y escribir un informe estructurado del cuadro de evaluación en evaluation.json.
  • Entornos de desarrollo estándar: Incluyen node, npm, yarn, pnpm, python, pip, uv, go, gh, git, tree, ripgrep y playwright en la imagen del contenedor de zona de pruebas, lo que le brinda al agente secundario autónomo un espacio de trabajo de prueba completo.

10. Limpieza

Para evitar que se apliquen cargos a tu cuenta de Google Cloud, borra los recursos que creaste durante este codelab.

./destroy.sh

Por qué limpiamos los recursos: Google Cloud factura según un modelo de utilización de recursos. Los recursos activos, como los clústeres de GKE Autopilot, los balanceadores de cargas de red y los discos persistentes, generan cargos continuos incluso cuando están inactivos. Si ejecutas este paso, se borrará el espacio de nombres del clúster para quitar los objetos de Kubernetes y se borrará el host del clúster de GKE Autopilot para detener de inmediato todos los cargos de facturación subyacentes.

11. Felicitaciones

¡Felicitaciones! Implementaste correctamente la aplicación Hackathon Judge con Agent Sandbox en GKE.

Implementaste una plataforma de IA moderna y segura basada en eventos que puede probar y evaluar envíos de base de código no confiables bajo restricciones de seguridad aisladas alojadas en contenedores.

Qué aprendiste

  • Infraestructura de GKE: Cómo aprovisionar GKE Autopilot y los servicios compatibles de Google Cloud, como Pub/Sub y BigQuery
  • Configuración de Agent Sandbox: Cómo configurar definiciones de recursos personalizados, SandboxTemplates, SandboxClaims y Sandbox WarmPools de alto rendimiento
  • Implementación de microservicios: Cómo configurar vinculaciones de Workload Identity y, luego, implementar una arquitectura de microservicios de varios componentes (Frontend React, REST Go, Worker ADK Agent y Isolated Sandbox).
  • Zonas de pruebas seguras: Cómo utilizar contenedores virtualizados de gVisor para ejecutar de forma segura comandos de terceros no confiables en nodos de GKE

Próximos pasos

Documentos de referencia