Sobre o GKE Agent Sandbox

O Google Kubernetes Engine (GKE) Agent Sandbox ajuda você a gerenciar cargas de trabalho isoladas, com estado e de réplica única no GKE. Ele é otimizado para casos de uso como tempos de execução de agentes de IA, em que códigos não confiáveis gerados por LLMs precisam ser executados em um ambiente seguro e eficiente.

O complemento GKE Agent Sandbox é baseado no projeto de controlador Agent Sandbox de código aberto e segue os ciclos de lançamento dele. Como um complemento gerenciado do GKE, o Google gerencia todo o ciclo de vida do controlador, incluindo upgrades automáticos e patches de segurança.

Este documento apresenta uma visão geral conceitual da sandbox do agente do GKE.

Por que usar o GKE Agent Sandbox

O GKE Agent Sandbox foi criado para cargas de trabalho de agentes que exigem alta escalonabilidade, extensibilidade e segurança. Dentre os principais benefícios estão:

  • Isolamento no nível do kernel: oferece isolamento forte no nível do kernel para código não confiável gerado por LLMs usando tecnologias como o gVisor.
  • Provisionamento em menos de um segundo: oferece um mecanismo pronto para uso para fornecer sandboxes significativamente mais rápido do que o agendamento padrão de pods do Kubernetes (normalmente <1s).
  • Extensibilidade nativa da nuvem: aproveita o poder do paradigma do Kubernetes e a infraestrutura gerenciada do GKE.

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

Casos de uso comuns da caixa de simulação do agente

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

  • Tempos de execução de agentes de IA: execute código não confiável com segurança em um ambiente isolado por tempos de execução focados em segurança, como o gVisor.
  • Ambientes de desenvolvimento: oferecem aos desenvolvedores ambientes de programação persistentes, isolados e 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 da sandbox do agente, para solicitar e gerenciar sandboxes diretamente da lógica do aplicativo sem gerenciar YAML do Kubernetes.

Como funciona o GKE Agent Sandbox

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

Arquitetura principal

  • CRD do sandbox: o recurso principal que representa um único pod com estado. Ele gerencia nomes de host estáveis, identidade de rede e armazenamento permanente.
  • Roteador de sandbox: um componente que fornece um endpoint estável e faz o túnel do tráfego para os pods de sandbox apropriados, abstraindo a complexidade da rede subjacente.
  • Integração com snapshots de pods: o GKE Agent Sandbox se integra ao recurso Snapshots de pods do GKE para permitir pausar 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 fundamental que separa a solicitação do usuário por 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 reivindicação permite solicitar um sandbox sem precisar gerenciar diretamente o pod ou as configurações de armazenamento subjacentes.

O modelo de reivindicação é gerenciado usando os CRDs SandboxClaim e SandboxTemplate e funciona da seguinte maneira:

  1. Os usuários ou aplicativos solicitam uma sandbox criando um SandboxClaim que faz referência a um SandboxTemplate.
  2. O controlador processa o mapeamento da reivindicação para uma instância real do Sandbox, oferecendo gerenciamento flexível de back-end. Isso permite que o sistema reutilize os sandboxes atuais ou aloque de um pool.

Warm Pools

O recurso Warm Pool foi criado para minimizar a latência de inicialização, o que é fundamental para cenários de agentes de IA interativos. Com esse recurso, o sandbox do agente pode fornecer ambientes de execução em menos de um segundo, o que é muito mais rápido do que o agendamento típico de pods. O recurso é gerenciado usando o CRD SandboxWarmPool e funciona da seguinte maneira:

  1. Um SandboxWarmPool mantém um conjunto de instâncias de pod pré-aquecidas em um estado pronto.
  2. Quando uma SandboxClaim é feita, o controlador atribui instantaneamente um pod do pool em vez de esperar que um novo pod extraia imagens e comece do zero.
  3. Quando combinadas com snapshots de pod, as pools quentes oferecem recursos rápidos e de "ativação instantânea" restaurando pods de um estado pré-configurado.

Isolamento de rede.

O GKE Agent Sandbox implementa uma postura de segurança de rede de negação padrão para todos os ambientes em sandbox. Isso garante que o código não confiável executado em um sandbox não possa acessar redes internas não autorizadas ou o plano de controle do GKE por padrão. É possível definir restrições de rede específicas e regras de saída ou entrada permitidas no seu SandboxTemplate para fornecer segurança refinada para cargas de trabalho de agentes.

Acesso programático com SDKs

Os engenheiros de IA podem consumir recursos do GKE Agent Sandbox de maneira programática usando as bibliotecas de cliente fornecidas. Por exemplo, o SDK do Python oferece uma interface de alto nível que abstrai as configurações SandboxClaim e SandboxTemplate subjacentes. Isso permite criar e interagir com ambientes isolados diretamente dos frameworks de agentes baseados em Python, como o LangChain ou o SDK Agentic da Vertex AI.

Limitações e requisitos

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

  • Versão do cluster: requer a versão 1.35.2-gke.1269000 ou mais recente do GKE para oferecer suporte completo a recursos, incluindo snapshots.
  • Requisitos de infraestrutura: otimizado para configurações de nós específicos (como tipos de máquinas N2) e exige que o controlador do Sandbox do agente seja instalado e configurado no cluster.
  • Ambientes de execução de isolamento: embora seja compatível com vários ambientes de execução, ele foi projetado principalmente para ser usado com ambientes de execução reforçados com segurança, como o gVisor.
  • Disponibilidade de recursos subjacentes: alguns recursos subjacentes, como snapshots de pods do GKE, podem estar em prévia ou ter disponibilidade regional específica.

A seguir