Planejar uma arquitetura para cargas de trabalho de agentes de IA no GKE

O Google Kubernetes Engine (GKE) oferece dois modelos de orquestração para executar agentes de IA em sandboxes isolados do kernel (usando microVMs do Cloud Hypervisor ou gVisor):

  • Agent Substrate no GKE (baseado em ator, recomendado): use esse modelo para a maioria das cargas de trabalho de agentes de IA, especialmente agentes com estado baseados em CPU que são suspensos e retomados com frequência. As sessões de agentes ativos (atores) compartilham um pool de pods de worker ativos e podem ser restauradas do Cloud Storage em menos de um segundo.
  • Agent Sandbox no GKE (baseado em pod): use esse modelo quando cada agente exigir um pod dedicado do Kubernetes. Escolha essa opção para agentes continuamente ativos ou cargas de trabalho que precisam de um PodSpec completo do Kubernetes (como sidecars), GPUs ou TPUs, nós do Arm ou clusters do GKE Autopilot.

Para um resumo lado a lado dos dois modelos de orquestração, consulte Comparar o Agent Substrate e o Agent Sandbox.

Leia este documento para escolher um modelo de orquestração, um ambiente de execução de sandbox, controles de isolamento e opções de armazenamento antes de provisionar o cluster do GKE. Este documento é destinado a arquitetos de soluções, desenvolvedores de IA e administradores e operadores de plataforma que projetam ambientes de execução para agentes de IA no GKE.

Requisitos de arquitetura para cargas de trabalho de agentes de IA no GKE

A execução de cargas de trabalho de agentes de IA no GKE permite colocar ambientes de execução de agentes isolados no mesmo cluster e perímetro de rede que os serviços de suporte do Kubernetes e usar o GKE para provisionamento automático de nós, escalonamento de burst e gerenciamento do ciclo de vida.

Ao contrário dos microsserviços continuamente ativos, as cargas de trabalho de agentes de IA têm os seguintes requisitos de arquitetura:

Modelo baseado em ator: Agent Substrate no GKE (recomendado)

O Agent Substrate no GKE é um ambiente de execução que separa as sessões de agentes (atores) dos pods do Kubernetes subjacentes. Os atores ativos compartilham um pool de pods de worker pré-aquecidos (recursos WorkerPool) entre modelos de ator (recursos ActorTemplate). Quando o aplicativo suspende um ator inativo, o Agent Substrate salva o estado do ator no Cloud Storage e libera a capacidade do worker para que outros atores possam usar o nó. Quando uma nova solicitação chega, o Agent Substrate restaura o ator em um worker disponível em menos de um segundo.

Use o Agent Substrate como sua arquitetura padrão para cargas de trabalho de agentes baseadas em CPU, incluindo os seguintes casos de uso:

  • Agentes de programação interativos: assistentes de IA que executam comandos de terminal, criam código e editam arquivos durante conversas com desenvolvedores e são suspensos entre comandos.
  • Agentes de produtividade de longa duração: assistentes em segundo plano que mantêm o contexto por dias ou semanas, passando a maior parte do tempo esperando a entrada do usuário ou acionadores externos.
  • Código temporário e sandboxes de navegador: ambientes sob demanda para executar código gerado por LLM, navegadores headless ou chamadas de ferramentas que são restaurados em menos de um segundo e liberam computação após a execução.

O Agent Substrate requer clusters do GKE Standard (versão 1.37 ou mais recente no plano de controle e nos pools de nós) com nós de trabalho de CPU x86. O GKE Autopilot não é compatível porque o agente de nó do Agent Substrate (atelet) é executado como um DaemonSet privilegiado, e os pools de workers de microVM exigem virtualização aninhada ou nós bare metal. GPUs e TPUs não são compatíveis.

Identidade, credenciais e saída de rede

O Agent Substrate provisiona um certificado SPIFFE X.509 exclusivo e um JSON Web Token (JWT) para que cada ator autentique e audite solicitações de sessões individuais. Como vários atores compartilham pods de worker ao longo do tempo, use a Federação de Identidade da Carga de Trabalho para GKE no nível do pod apenas para tarefas de infraestrutura de worker.

Para manter as chaves de API e os tokens fora do sandbox, o gateway de saída integrado injeta credenciais nas solicitações de saída em trânsito. Os secrets são armazenados em objetos Secret do Kubernetes ou no Secret Manager. Quando uma solicitação HTTP ou HTTPS de saída corresponde a uma regra de saída, o gateway autentica o túnel mTLS do ator e substitui os cabeçalhos de marcador de posição por um secret buscado ou um JWT de ator. Para mais informações, consulte a documentação de código aberto sobre injeção de credenciais de saída do Agent Substrate.

Por padrão, o Agent Substrate bloqueia todo o tráfego de saída para outros atores, o plano de controle do Kubernetes, o servidor de metadados do Compute Engine e a Internet. UDP não DNS, conexões TCP brutas arbitrárias e upgrades de WebSocket HTTP são bloqueados, e a resolução de DNS resolve apenas nomes de host permitidos pelo recurso EgressPolicy do ator. Para permitir conexões de saída, defina regras de passagem HTTP, HTTPS ou TLS no recurso EgressPolicy usando nomes de domínio totalmente qualificados (FQDNs) ou nomes de host curinga. Os endereços IP e intervalos CIDR não são compatíveis. Para mais informações, consulte a documentação de código aberto do Agent Substrate sobre tráfego de saída e segurança.

Checkpoints de sessão e armazenamento do espaço de trabalho

Quando o aplicativo suspende um ator (no gVisor ou em microVMs), o Agent Substrate salva um snapshot no Cloud Storage em três camadas: memória ativa, mudanças no sistema de arquivos raiz e diretórios duráveis (a camada de volumes). Todos os volumes CSI externos anexados persistem no armazenamento de apoio fora do snapshot e são anexados novamente na retomada.

Quando um ator suspenso é retomado, o Agent Substrate restaura a camada de snapshot mais alta que corresponde ao ambiente de destino:

  • Memória, sistema de arquivos raiz e volumes: restaurados em menos de um segundo quando o ator é retomado com o mesmo hardware, ambiente de execução de sandbox e imagem de contêiner.
  • Sistema de arquivos raiz e volumes: restaurados quando o hardware do nó ou o ambiente de execução do sandbox muda. O ator reinicia os processos, mantendo as alterações no sistema de arquivos raiz e os diretórios duráveis.
  • Somente volumes: restaurados quando você atualiza a imagem do contêiner no recurso ActorTemplate enquanto o ator está suspenso. A próxima retomada inicia os contêineres da imagem atualizada e restaura diretórios duráveis e volumes externos. Grave dados que precisam sobreviver a atualizações de imagem em diretórios duráveis ou armazenamento externo.

A latência de suspensão e retomada varia de acordo com o tamanho do snapshot. Para espaços de trabalho grandes que precisam de uma nova conexão rápida entre nós quando um ator é retomado em um nó diferente, use volumes de agente do Filestore externos em vez de armazenar os dados dentro do snapshot. Cada volume CSI externo (pré-lançamento) em um recurso ActorTemplate é provisionado exclusivamente para um único ator (não compartilhado entre atores) e é excluído com esse ator. O suporte Production para volumes do agente do Filestore é oferecido por um programa de GA limitado que exige uma solicitação de acesso.

O armazenamento em blocos (como o Hyperdisk) é usado para discos de inicialização de nós e armazenamento em cache de snapshots locais, em vez de volumes CSI por ator, porque a latência de desanexação e anexação de blocos entre nós atrasa a retomada do ator. Para mais informações, consulte a documentação de código aberto sobre volumes CSI do Agent Substrate.

Modelo baseado em pod: Agent Sandbox no GKE

O Agent Sandbox no GKE executa cada agente em um pod dedicado e com estado do Kubernetes gerenciado por recursos personalizados do Kubernetes (Sandbox, SandboxClaim, SandboxTemplate e SandboxWarmPool). Um recurso SandboxWarmPool mantém recursos de sandbox pré-aquecidos com pods em execução para um recurso SandboxTemplate específico, de modo que o controlador possa atribuir um recurso de sandbox pronto e o pod em execução a uma declaração em menos de um segundo.

Escolha o Agent Sandbox quando cada agente precisar de um pod dedicado ou quando as cargas de trabalho tiverem algum dos seguintes requisitos:

  • Agentes continuamente ativos e serviços de pod único: cargas de trabalho sem períodos de inatividade frequentes ou sessões persistentes (como ambientes de desenvolvimento em nuvem ou Jupyter Notebooks) que precisam de um nome de host e armazenamento estáveis sem a complexidade do StatefulSet.
  • Aceleradores de hardware (GPUs ou TPUs): agentes que precisam de acesso direto a GPUs ou TPUs dentro do sandbox. Os aceleradores funcionam apenas com o ambiente de execução do gVisor em modelos de GPU e versões de TPU compatíveis. As microVMs não são compatíveis com GPUs ou TPUs.
  • PodSpec completo do Kubernetes, nós do Arm ou GKE Autopilot: cargas de trabalho que exigem contêineres sidecar ou de inicialização personalizados, APIs e ferramentas padrão do Kubernetes (por exemplo, comandos kubectl, controle de acesso baseado em papéis e controladores atuais), CPUs do Arm ou clusters do GKE Autopilot.

Identidade, credenciais e políticas de rede

Como cada agente é executado em um pod dedicado, é possível conceder permissões do Google Cloud Identity and Access Management (IAM) ao pod usando a federação de identidade da carga de trabalho para GKE ou a identidade do agente (pré-lançamento). As duas opções vinculam a identidade à conta de serviço do Kubernetes do pod na criação do pod. Assim, todos os pods pré-aquecidos em um recurso SandboxWarmPool compartilham a mesma identidade. Para isolar identidades por agente ou locatário, mantenha um recurso SandboxWarmPool separado por identidade ou crie recursos Sandbox sob demanda sem um pool de espera.

Monte secrets em pods usando objetos de secret padrão do Kubernetes ou volumes CSI. O Agent Sandbox não inclui um gateway para injeção de credenciais fora do sandbox. Para injetar credenciais em trânsito, implante seu próprio proxy externo.

O controlador cria um objeto NetworkPolicy de negação padrão para cada recurso SandboxTemplate. Para recursos do Sandbox que você cria diretamente sem um modelo, crie seu próprio objeto NetworkPolicy. Restrinja o tráfego usando controles de rede padrão do GKE:

Suspensão por inatividade, snapshots de pod e armazenamento

O pod de um agente inativo mantém a CPU e a memória reservadas até que o aplicativo suspenda o recurso do Sandbox definindo o campo spec.operatingMode como Suspended. A suspensão do recurso do Sandbox exclui o pod, mas mantém os volumes permanentes. A exclusão do pod limpa os dados na memória e as alterações no sistema de arquivos do contêiner. Para salvar e restaurar esse estado do Cloud Storage, faça um snapshot de pod do GKE antes de suspender o agente. Os snapshots de pod exigem o ambiente de execução do gVisor e não são compatíveis com microVMs ou TPUs. A restauração de um pod de um snapshot leva de três a cinco segundos.

Para armazenamento permanente além dos snapshots de pod, escolha uma das seguintes opções:

Comparar o Agent Substrate e o Agent Sandbox

A tabela a seguir resume as diferenças de arquitetura entre o Agent Substrate no GKE e o Agent Sandbox no GKE:

Dimensão Agent Substrate no GKE (baseado em ator) Agent Sandbox no GKE (com base em pods)
Cargas de trabalho recomendadas do agente de IA A maioria dos agentes com estado baseados em CPU que são suspensos e retomados com frequência Agentes continuamente ativos, cargas de trabalho de GPU ou TPU, PodSpecs personalizados, nós Arm ou Autopilot do GKE
Unidade de programação Vários atores compartilham um pool de pods quentes (WorkerPool) Um pod dedicado por agente (sandbox)
Ambientes de execução de sandbox MicroVMs do gVisor e do Cloud Hypervisor (gerenciadas em pods do WorkerPool) gVisor e microVMs no GKE Standard (com o GKE Sandbox ativado no pool de nós ou na ComputeClass) ou gVisor no GKE Autopilot (ativado por padrão)
Pooling pré-inicializado Recursos compartilhados do WorkerPool em modelos de ator e imagens de contêiner Um recurso SandboxWarmPool por modelo e imagem de contêiner
Caminho do plano de controle Plano de controle e banco de dados dedicados fora do componente kube-apiserver Controladores padrão do Kubernetes, kube-apiserver e etcd
Tratamento de recursos inativos Suspender um ator inativo libera a CPU e a memória do worker Suspender um recurso inativo do Sandbox exclui o pod dele e mantém os volumes permanentes
Checkpoints de estado Snapshots integrados do Cloud Storage no gVisor e em microVMs, com restauração em menos de um segundo Snapshots de pod do GKE (compatíveis apenas com o gVisor), restaurados em 3 a 5 segundos
Modos de cluster compatíveis GKE Standard (versão 1.37 ou mais recente, nós x86) GKE Standard e GKE Autopilot
Aceleradores de hardware Não compatível (nós de trabalho somente de CPU) GPUs e TPUs compatíveis apenas com o ambiente de execução do gVisor
Suporte ao PodSpec do Kubernetes Subconjunto dividido entre os recursos ActorTemplate e WorkerPool PodSpec completo, incluindo sidecars e contêineres de inicialização
Rede Gateways de entrada e saída do Envoy integrados com túneis mTLS por ator Serviços do Kubernetes, NetworkPolicy e FQDNNetworkPolicy
Modelo de identidade Certificado SPIFFE X.509 e JWT por ator Conta de serviço do pod que usa a federação de identidade da carga de trabalho para GKE ou a identidade do agente (pré-lançamento), compartilhada em um pool de espera
Gerenciamento de secrets Injetado em solicitações de saída no gateway de saída Montados no pod usando objetos Secret do Kubernetes ou volumes CSI

Selecione um ambiente de execução de sandbox

Tanto o Agent Substrate quanto o Agent Sandbox isolam o código não confiável do nó host usando microVMs do Cloud Hypervisor ou o gVisor, mas você configura o ambiente de execução de maneira diferente em cada modelo:

  • Agent Substrate: selecione o ambiente de execução no recurso WorkerPool. O Agent Substrate gerencia os próprios ambientes de execução de microVM e gVisor nos pods do WorkerPool, em vez de usar o recurso GKE Sandbox no nível do nó. Não ative o GKE Sandbox em pools de nós de trabalho do Agent Substrate, porque o taint de nó sandbox.gke.io/runtime impede que os pods do WorkerPool sejam programados.
  • Agent Sandbox: defina o campo runtimeClassName como gvisor ou microvm no modelo de pod do recurso SandboxTemplate. No GKE Standard, ative também o GKE Sandbox no pool de nós ou em uma ComputeClass personalizada. No GKE Autopilot, o gVisor está disponível por padrão, e as microVMs não são compatíveis.

Os dois ambientes de execução executam código não confiável e navegadores headless:

  • MicroVMs: cada sandbox é executado em uma máquina virtual leve com um kernel Linux convidado dedicado. Escolha microVMs quando precisar de isolamento no nível da VM, compatibilidade total com chamadas do sistema do Linux ou limites de CPU e memória por contêiner em um ator de vários contêineres.
  • gVisor: cada sandbox é executado em um kernel de espaço do usuário que intercepta e filtra syscalls do Linux. Escolha o gVisor para inicializações a frio mais rápidas, menor sobrecarga de memória ou suporte mais amplo a máquinas do Compute Engine (incluindo GPUs, TPUs, nós Arm e Autopilot do GKE no Agent Sandbox).

A tabela a seguir compara microVMs e gVisor no GKE:

Recurso MicroVMs gVisor
Acesso ao kernel Kernel completo do Linux Subconjunto de chamadas do sistema do kernel do Linux
Nível de isolamento Virtualização de hardware com um kernel convidado dedicado Intercepção de syscall em um kernel de espaço do usuário
Sobrecarga de CPU e memória Memória de VMM por ator no Agent Substrate. Corrigido 250 mCPU e 130 MiB por pod no GKE Sandbox. Sobrecarga dinâmica com pouca memória base
Horário de início Entre 1 e 2 segundos Menos de 100 ms
Configuração de nós do GKE Nós do GKE Standard com virtualização aninhada (ambos os modelos) ou nós bare metal x86 (somente Agent Substrate) Pools de nós do GKE Standard (ambos os modelos) ou nós do GKE Autopilot (somente Agent Sandbox)
Suporte a imagens de nó Container-Optimized OS (cos_containerd) no Agent Substrate. Container-Optimized OS (cos_containerd) ou Ubuntu no GKE Sandbox. Somente Container-Optimized OS (cos_containerd)
Compatibilidade de tipo de máquina Séries de máquinas x86 que oferecem suporte à virtualização aninhada e bare metal x86 (não compatível com E2 ou Arm) Série x86 de CPU não mista no Agent Substrate. A maioria das séries x86, Arm e de aceleradores no Agent Sandbox.
Suporte para aceleradores Sem suporte Modelos de GPU e versões de TPU compatíveis (somente Agent Sandbox)
Exemplos de casos de uso
  • Agentes de programação e navegador autônomos
  • Cargas de trabalho que exigem compatibilidade total com o kernel do Linux
  • Cargas de trabalho de alta E/S com chamadas frequentes do sistema
  • Aplicativos não confiáveis em Python, Node.js, Go, Java ou Rust
  • Inferência de CPU, GPU ou TPU e sandboxes de execução de código
  • Front-ends, caches e proxies da Web

Para mais informações sobre essas tecnologias de isolamento, consulte GKE Sandbox.

A seguir