Sobre o Agent Substrate no GKE

O Agent Substrate no GKE executa cargas de trabalho de agentes em escala em clusters do Kubernetes. Ele resolve uma ineficiência comum de recursos: agentes interativos (como assistentes pessoais e agentes de programação) costumam passar a maior parte do tempo esperando por entradas do usuário ou acionadores externos. Manter esses agentes inativos em execução contínua usa CPU e memória que poderiam ser alocadas para cargas de trabalho ativas.

O Agent Substrate no GKE resolve esse problema permitindo que o aplicativo suspenda agentes inativos. Quando o aplicativo suspende um agente, o sistema faz um snapshot da memória ativa (RAM) e dos arquivos locais do agente. Quando o agente suspenso precisa agir novamente, o sistema restaura o estado dele em um sandbox disponível em menos de um segundo.

O Agent Substrate no GKE se baseia nos recursos do Agent Sandbox no GKE e melhora o Agent Sandbox no GKE ao ignorar os gargalos do plano de controle padrão do Kubernetes. Como resultado, o Agent Substrate no GKE executa mais agentes simultâneos por máquina e inicia os agentes mais rapidamente do que o Agent Sandbox no GKE. Para comparar o Agent Substrate no GKE com o Agent Sandbox 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.

As implantações padrão do Kubernetes (incluindo o Agent Sandbox no GKE) associam cada carga de trabalho do agente a um pod dedicado. Embora o Kubernetes seja altamente escalonável, ele é limitado pela capacidade de programação e pela latência de inicialização dos pods. Além disso, o Kubernetes não é compatível com a hibernação de pods, e manter milhões de agentes inativos em um cluster esgotaria os limites de pods e a memória do plano de controle. Para evitar pagar pela computação ociosa, é necessário encerrar os pods e gerenciar o estado do agente no armazenamento externo. O Agent Substrate no GKE resolve essas restrições de escalonamento desacoplando o estado do agente dos pods subjacentes: ele armazena milhões de snapshots de agentes suspensos no armazenamento e os restaura sob demanda em um pool compartilhado de workers ativos.

O Agent Substrate no GKE é um sistema de código aberto que você implanta diretamente nos seus próprios clusters do GKE Standard. Embora o projeto principal seja desenvolvido no repositório de código aberto do Agent Substrate, o Google fornece ferramentas e scripts de implantação otimizados para o GKE no repositório substrate-gke para clientes qualificados do Google Cloud .

Benefícios do Agent Substrate no GKE

Use o Agent Substrate no GKE para alcançar as seguintes metas:

  • Executar código não confiável com segurança: o Agent Substrate no GKE aplica o isolamento de kernel e rede para que você possa executar código gerado por IA sem colocar em risco sua infraestrutura mais ampla.
  • Criar agentes com estado de longa duração: a memória de trabalho e os arquivos de um agente são preservados entre as sessões. O agente retoma do ponto exato em que foi pausado.
  • Responder a solicitações em tempo real: quando uma nova solicitação aciona um agente suspenso, o sistema restaura o estado do agente em uma fração de segundo.
  • Reduzir os custos de computação: é possível executar mais agentes em menos máquinas compartilhando um pool de sandboxes de worker entre todos os agentes. Como os agentes ociosos são suspensos e não usam CPU e memória, você paga pela computação somente quando os agentes estão processando tarefas ativamente.

Casos de uso

O Agent Substrate no GKE foi projetado para executar agentes em qualquer escala, de dezenas a milhões de agentes simultâneos. Confira três exemplos de cargas de trabalho:

  • Agentes de produtividade: assistentes de segundo plano de longo prazo que mantêm o contexto por semanas. Como esses assistentes passam a maior parte do tempo esperando por gatilhos, suspender as cargas de trabalho quando não estão em uso reduz os custos de computação.
  • Sandboxes temporários: ambientes isolados e sob demanda para executar códigos gerados por LLM não confiáveis, executar chamadas de ferramentas ou analisar dados. Como os sandboxes são restaurados em menos de um segundo, o sistema pode fornecer ambientes descartáveis para tarefas de curta duração e liberar recursos quando a execução terminar.
  • Agentes de programação: assistentes de IA que conversam em tempo real com desenvolvedores para escrever, criar e testar códigos. O agente executa comandos de terminal e modifica arquivos dentro de um sandbox. Quando o agente está inativo, o aplicativo o suspende até que o desenvolvedor envie outro comando.

Como o Agent Substrate no GKE funciona

O Agent Substrate no GKE é baseado no Kubernetes, mas você não precisa entender o Kubernetes para usá-lo. Os principais conceitos do Agent Substrate no GKE são os seguintes:

  • Ator: uma única instância em execução de um agente.
  • ActorTemplate: um blueprint de configuração (que define imagens de contêiner, variáveis de ambiente e recursos de computação) usado para instanciar atores.
  • Worker: um sandbox em que um ator ativo é executado.
  • WorkerPool: um grupo de Workers pré-iniciados e inativos que estão prontos para receber um Actor.

Como um ator não está vinculado a um worker específico, o sistema pode reutilizar a computação que um ator libera quando o aplicativo o suspende. Essa arquitetura permite que o sistema execute milhões de agentes em um número limitado de máquinas.

O ciclo de vida típico de um agente segue estas etapas:

  1. Roteamento: cada solicitação de API recebida do aplicativo especifica o ator de destino. Por exemplo, quando um usuário digita um novo comando em uma interface de chat, seu aplicativo envia uma solicitação direcionada ao ator específico que gerencia a sessão do usuário.
  2. Retomada: se a solicitação for para um Ator suspenso, o sistema reivindica um Worker quente do WorkerPool e restaura o snapshot do Ator nesse Worker.
  3. Execução: o sistema encaminha a solicitação para esse worker recém-ativado, e o ator processa a tarefa.
  4. Suspensão: quando o aplicativo suspende um Ator inativo, o sistema faz um novo snapshot da memória e dos arquivos do Ator, salva o snapshot no armazenamento e libera o Worker vazio de volta para o pool.

Isolamento de cargas de trabalho e GKE Sandbox

O Agent Substrate no GKE usa o gVisor ou o Cloud Hypervisor para executar cada carga de trabalho em um sandbox que isola o código do aplicativo do kernel do host. A instalação do Agent Substrate no GKE inclui o próprio ambiente de execução do gVisor para workers. Não ative o GKE Sandbox nos pools de nós em que o Agent Substrate no GKE é executado, porque ele não pode ser executado nesses nós. Ainda é possível usar o GKE Sandbox para outras cargas de trabalho, incluindo o Agent Sandbox no GKE.

Limitações e requisitos

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

  • Modo, versão e canal de lançamento do cluster: o Agent Substrate no GKE é compatível com clusters do GKE Standard com plano de controle e pools de nós que executam a versão 1.37 ou mais recente. Os clusters do Autopilot e as versões anteriores à 1.37 não são compatíveis. Na versão 1.37 e mais recentes, o GKE disponibiliza as APIs podcertificaterequests e clustertrustbundles do Kubernetes e permite que os nós montem certificados de pod e pacotes de confiança em pods. Assim, você não precisa ativar as versões Beta dessas APIs. No entanto, o instalador ativa as versões Beta em todos os clusters que cria ou configura. Como o canal de lançamento estendido não é compatível com APIs Beta explicitamente ativadas, não é possível usar o instalador com clusters registrados no canal de lançamento estendido.

  • Federação de Identidade da Carga de Trabalho para GKE: os clusters do GKE precisam ter a Federação de Identidade da Carga de Trabalho para GKE ativada. O Agent Substrate no GKE usa a Federação de Identidade da Carga de Trabalho para GKE para autenticar as APIs do Google Cloud , como o Cloud Storage para salvar snapshots de agentes. Para salvar e restaurar snapshots, o sistema usa uma conta de serviço dedicada chamada ate-snapshot-transfer. As credenciais de cada operação de salvamento ou restauração só podem acessar os snapshots de um ator. Como resultado, não é necessário conceder aos nós do GKE acesso ao bucket de snapshot. O instalador cria a conta de serviço ate-snapshot-transfer e concede a ela acesso ao bucket de snapshot. Se você configurar as permissões por conta própria, conceda os seguintes papéis do IAM:

    • No bucket de snapshot, conceda à conta de serviço do ate-snapshot-transfer e à conta de serviço do Kubernetes do ate-api-server os papéis de Administrador de objetos do Storage (roles/storage.objectAdmin) e Leitor de buckets do Storage (roles/storage.bucketViewer).
    • Na conta de serviço do ate-snapshot-transfer, conceda à conta de serviço do Kubernetes do ate-api-server o papel de Criador de token da conta de serviço (roles/iam.serviceAccountTokenCreator). A conta de serviço do ate-api-server usa a identidade temporária de conta de serviço da conta de serviço do ate-snapshot-transfer para emitir as credenciais de cada ator.
    • Se você usar o ambiente de execução da microVM, conceda à conta de serviço do Kubernetes atelet o papel de Leitor de objetos do Storage (roles/storage.objectViewer) no bucket de recursos.

    Para ver a lista completa de vinculações e os comandos gcloud equivalentes, consulte O que o create iam realmente concede no README do setup-gcp.

  • Famílias de VMs:

    • Arquiteturas de CPU mistas: o Agent Substrate no GKE não é compatível com séries de máquinas de uso geral que são executadas em arquiteturas de CPU mistas (como tipos de máquina E2) devido a um problema conhecido no gVisor.
    • Tipos de VM uniformes por modelo de ator: todos os atores criados com base em um ActorTemplate precisam ser executados no mesmo tipo de VM. Um ActorTemplate não é um recurso do Kubernetes e não tem um seletor de nós. Em vez disso, o campo workerSelector do ActorTemplate seleciona os recursos WorkerPool pelos rótulos. Cada WorkerPool pode selecionar os nós para os workers usando o campo spec.template.nodeSelector. Por exemplo, se o cluster tiver pools de nós que usam VMs C4 e N2, configure cada WorkerPool para selecionar nós de apenas um tipo de VM. Em seguida, defina o campo workerSelector de ActorTemplate para corresponder apenas aos recursos WorkerPool que usam VMs C4.
    • Virtualização aninhada ou bare metal para ambientes de execução de microVM: o ambiente de execução de microVM executa cada sandbox na própria máquina virtual. Portanto, os workers que usam esse ambiente de execução precisam de nós que possam executar máquinas virtuais. Esses nós precisam usar a arquitetura de CPU x86, não Arm. Quando o instalador cria um cluster, o pool de nós criado tem a virtualização aninhada ativada. Se você instalar o Agent Substrate no GKE em um cluster atual ou adicionar seus próprios pools de nós para workers de microVM, use um pool de nós com a virtualização aninhada ativada ou que use um tipo de máquina bare metal x86. Só é possível ativar a virtualização aninhada ao criar um pool de nós. Para verificar quais séries de máquinas são compatíveis com a virtualização aninhada, como C3, C4, N2 e N4, consulte Comparação de séries de máquinas.

  • Suporte a GPU: a passagem de dispositivos de GPU para contêineres de ator não é compatível. Especificar nvidia.com/gpu apenas coloca pods em nós com GPU, mas não transmite o dispositivo de GPU para o contêiner do ator. Além disso, o gVisor não pode criar snapshots de contextos CUDA ativos.

  • Conexões de rede abertas: as conexões de rede abertas (como sessões de banco de dados ou conexões com servidores MCP) não são preservadas quando um agente é suspenso. O código do agente precisa lidar com a reconexão a serviços externos quando o agente é retomado.

  • Observabilidade e OpenTelemetry gerenciado: o OpenTelemetry gerenciado para o GKE tem as seguintes limitações:

    • Os conectores de coletor não são compatíveis, o que exige o uso de um medidor de proxy externo para benchmarking de telemetria.
    • As implantações do coletor geram uma sobrecarga de cache em memória que é escalonada linearmente com o número de pods em clusters grandes.
    • O TLS não é compatível com o OpenTelemetry gerenciado para GKE.

  • Armazenamento: o Agent Substrate no GKE usa os seguintes buckets do Cloud Storage, que o instalador cria se não existirem:

    • Bucket de snapshot: armazena os snapshots de todos os agentes no cluster. Este bucket é obrigatório.
    • Bucket de recursos: armazena os arquivos necessários para o ambiente de execução da microVM, como um kernel do Linux e um sistema de arquivos raiz. O ambiente de execução da microVM usa esses arquivos para executar cada sandbox na própria máquina virtual. O nome desse bucket é o nome do bucket de snapshot seguido por -assets. Por exemplo, se o bucket de snapshot for chamado example-snapshots, o bucket de recursos será chamado example-snapshots-assets. Se você não usar o ambiente de execução de microVM, esse bucket vai ficar vazio.

  • Configurações do kernel para alta densidade de sandbox: executar mais de aproximadamente 800 sandboxes simultâneos em um nó excede os limites padrão no kernel do Linux para monitoramento do sistema de arquivos (inotify) e para a tabela vizinha do protocolo de resolução de endereço (ARP). Sem limites mais altos, os sandboxes podem não ser iniciados e a rede pode ser interrompida. O instalador aplica as configurações de kernel necessárias aos clusters que ele cria. Se você instalar o Agent Substrate no GKE em um cluster atual ou adicionar seus próprios pools de nós, será necessário aplicar essas configurações por conta própria. Para os valores necessários, consulte Requisitos de cluster e Projetar sua infraestrutura para o Agent Substrate no GKE.

  • Ambiente de instalação: não é possível instalar o Agent Substrate no GKE no Cloud Shell. O Cloud Shell tem um limite de armazenamento em disco permanente de 5 GB, que não oferece espaço em disco suficiente para a instalação. É necessário instalar o Agent Substrate no GKE em uma estação de trabalho local ou em uma máquina virtual (VM) que tenha espaço em disco suficiente.

A seguir