Sobre o Agent Sandbox no GKE

O Agent Sandbox no Google Kubernetes Engine (GKE) ajuda a executar cargas de trabalho de agentes isoladas em pods dedicados do Kubernetes. O isolamento é importante quando os agentes de IA executam código não confiável gerado por LLM. Para a maioria das cargas de trabalho de agentes, use o Agent Substrate no GKE, porque ele pode executar mais agentes nos mesmos nós. Use o Agent Sandbox no GKE quando cada agente precisar de um pod dedicado, GPUs ou TPUs, um PodSpec completo do Kubernetes ou um cluster do GKE Autopilot. Para comparar o Agent Sandbox no GKE com o Agent Substrate no GKE e escolher uma arquitetura para suas cargas de trabalho de agentes de IA, consulte Planejar uma arquitetura para cargas de trabalho de agentes de IA no GKE.

O Agent Sandbox é um projeto de código aberto do Kubernetes SIG Apps. Para usar o Agent Sandbox no GKE, instale o controlador do Agent Sandbox no cluster. Você é responsável por fazer upgrade do controlador. Para instruções, consulte Instalar o Agent Sandbox no GKE.

Neste documento, apresentamos uma visão geral conceitual do Agent Sandbox no GKE.

Por que usar o Agent Sandbox no GKE

O Agent Sandbox no GKE oferece a cada agente um pod dedicado e isolado do kernel, que você gerencia com APIs padrão do Kubernetes. Os principais benefícios incluem:

  • Isolamento no nível do kernel: isola o código não confiável gerado por LLM do kernel do nó usando o GKE Sandbox com o gVisor ou microVMs. O Agent Sandbox no GKE também funciona com Kata Containers de código aberto autogerenciados que você instala nos nós em vez do GKE Sandbox. Para um tutorial sobre como usar o Kata Containers de código aberto com o Agent Sandbox no GKE, consulte Como ativar o Kata Containers no GKE.

  • Provisionamento em menos de um segundo: fornece pods pré-aquecidos para seus agentes, normalmente em menos de um segundo, em vez de esperar pela programação e inicialização padrão de pods do Kubernetes.

  • Extensibilidade nativa da nuvem: aproveita o poder do paradigma do Kubernetes e da infraestrutura gerenciada do GKE.

Ao fornecer uma API declarativa e padronizada, o Agent Sandbox no GKE oferece uma experiência de contêiner único que fornece características de isolamento e persistência semelhantes às de uma máquina virtual (VM), criada inteiramente em primitivos do Kubernetes.

Casos de uso comuns do Agent Sandbox no GKE

Use o Agent Sandbox no GKE para cargas de trabalho que exigem isolamento, persistência e uma identidade estável. Veja alguns exemplos de casos de uso:

  • Ambientes de execução de agentes de IA: execute código não confiável em um pod que use o gVisor ou microVMs para isolar o código do kernel do nó.
  • Ambientes de desenvolvimento: forneça aos desenvolvedores ambientes de programação persistentes e isolados baseados na nuvem.
  • Notebooks e ferramentas de pesquisa: hospede sessões de contêiner único para ferramentas interativas, como notebooks Jupyter.
  • Serviços com estado de pod único: execute aplicativos que precisam de uma identidade e um armazenamento estáveis sem a complexidade de um StatefulSet.
  • Gerenciamento programático de ambientes: use os SDKs de biblioteca de cliente fornecidos, como o SDK do Python do Agent Sandbox, para solicitar e gerenciar recursos do Sandbox diretamente da lógica do aplicativo sem gerenciar o YAML do Kubernetes.

Como o Agent Sandbox no GKE funciona

O Agent Sandbox no GKE usa um controlador personalizado e várias definições de recursos personalizados (CRDs) do Kubernetes para gerenciar o ciclo de vida dos recursos do Sandbox.

Arquitetura principal

  • Recurso personalizado do sandbox: o recurso principal que representa um único pod com estado. O recurso gerencia nomes de host estáveis, identidade de rede e armazenamento permanente. Para suspender um agente inativo, defina o campo spec.operatingMode do recurso Sandbox como Suspended. O controlador exclui o pod, mas mantém o recurso do Sandbox e os volumes permanentes. Os dados na memória e as alterações no sistema de arquivos do contêiner são perdidos, a menos que você faça um snapshot do pod primeiro. Para retomar o agente, defina o campo de volta como Running. O Agent Sandbox no GKE não detecta agentes inativos. Seu aplicativo decide quando suspendê-los.
  • Roteador de sandbox: um componente que fornece um endpoint estável e direciona o tráfego para os pods que executam seus agentes, abstraindo a complexidade de rede subjacente.
  • Integração com snapshots de pods: o Agent Sandbox no GKE se integra ao recurso de snapshots de pods do GKE para suspender e retomar cargas de trabalho salvando e restaurando o estado completo de um contêiner.

Modelo de reivindicação

O modelo de declaração é um recurso importante que separa a solicitação do usuário de um ambiente dos detalhes específicos da implementação, como onde e como a carga de trabalho é provisionada. Ao contrário de um StatefulSet padrão do Kubernetes, o modelo de declaração permite solicitar um recurso de sandbox sem precisar gerenciar diretamente as configurações de pod ou armazenamento subjacentes.

O modelo de declaração usa os recursos personalizados SandboxClaim, SandboxWarmPool e SandboxTemplate e funciona da seguinte maneira:

  1. Usuários ou aplicativos solicitam um recurso de sandbox criando um recurso SandboxClaim que faz referência a um recurso SandboxWarmPool. O pool de aquecimento faz referência ao recurso SandboxTemplate que define a configuração do pod.
  2. O controlador atribui um recurso de sandbox pronto (e o pod em execução) do pool de espera à reivindicação. Se nenhum recurso de sandbox no pool estiver pronto, o controlador vai criar um novo recurso de sandbox para a declaração com base no modelo.

Pools pré-inicializados

O recurso de pool de aquecimento foi projetado para minimizar a latência de inicialização em cenários de agentes de IA interativos. Ao usar um pool de espera, o Agent Sandbox no GKE pode fornecer ambientes de execução em menos de um segundo. O recurso usa o recurso personalizado SandboxWarmPool e funciona da seguinte maneira:

  1. Um recurso SandboxWarmPool mantém um pool de recursos de sandbox pré-aquecidos com pods em um estado pronto.
  2. Quando um recurso SandboxClaim é criado, o controlador atribui um recurso Sandbox pronto e o pod em execução do pool, em vez de esperar que um novo pod extraia imagens e seja iniciado.
  3. Quando combinados com snapshots de pods, os pools de aquecimento podem restaurar pods de um estado pré-configurado em vez de iniciá-los do zero.

Isolamento de rede.

O Agent Sandbox no GKE implementa uma política de rede de negação padrão para os pods que o controlador cria com base em um recurso SandboxTemplate. Para cada recurso SandboxTemplate, o controlador cria um recurso NetworkPolicy que ajuda a impedir que códigos não confiáveis dentro do pod acessem redes internas não autorizadas ou o plano de controle do GKE. É possível definir restrições de rede específicas e regras de saída ou entrada permitidas no recurso SandboxTemplate para controlar o acesso à rede para cargas de trabalho de agentes.

O controlador não cria um recurso NetworkPolicy para um recurso Sandbox criado diretamente. Para restringir o acesso à rede para os pods desses recursos do Sandbox, crie seu próprio recurso NetworkPolicy.

Acesso programático com SDKs

Os engenheiros de IA podem consumir o Agent Sandbox em recursos do GKE de forma programática usando as bibliotecas de cliente fornecidas. Por exemplo, o SDK para Python fornece uma interface de alto nível que cria o recurso SandboxClaim para você. A declaração faz referência a um recurso SandboxWarmPool que você cria. Essa interface permite criar e interagir com ambientes isolados diretamente de frameworks de agentes de IA baseados em Python, como o LangChain ou o SDK Agêntico da Vertex AI.

Limitações e requisitos

O Agent Sandbox no GKE tem as seguintes limitações e requisitos:

  • Versão do cluster: o Agent Sandbox no GKE é executado em qualquer versão compatível do GKE. Para usar snapshots de pod, o cluster precisa executar o GKE versão 1.35.3-gke.1234000 ou mais recente.
  • Requisitos de infraestrutura: exige que o controlador do Agent Sandbox esteja instalado e configurado no cluster. O Agent Sandbox no GKE não exige um tipo de máquina específico. Por exemplo, o guia de instalação usa nós e2-standard-2. No entanto, os snapshots de pod não são compatíveis com os tipos de máquina E2. Portanto, se você planeja usar snapshots de pod, use outra série de máquinas, como N2.
  • Ambientes de execução de isolamento: o Agent Sandbox no GKE oferece suporte ao gVisor e a microVMs como ambientes de execução de isolamento. Os snapshots de pod exigem o gVisor e não funcionam com microVMs. Se você não especificar um ambiente de execução do GKE Sandbox (gVisor ou microVMs), os pods serão executados sem isolamento de kernel. Portanto, não os use para executar código não confiável.
  • Aceleradores de hardware: as GPUs e TPUs funcionam apenas com o ambiente de execução do gVisor em modelos de GPU e versões de TPU compatíveis, e não são compatíveis com microVMs. Além disso, os snapshots de pod não são compatíveis com TPUs.
  • Disponibilidade de recursos subjacentes: alguns recursos subjacentes, como snapshots de pods do GKE, podem estar em pré-lançamento ou ter disponibilidade regional específica.

A seguir