Como o TrueFoundry se Integra ao GCP: A Arquitetura do Plano de Controle

A implantação de IA Generativa no Google Cloud Platform (GCP) exige a orquestração de um conjunto complexo de primitivas: Google Kubernetes Engine (GKE), Cloud TPUs e Vertex AI. Embora o GCP forneça a capacidade de computação bruta, a conexão desses elementos em uma Plataforma de Desenvolvedor Interna (IDP) em conformidade exige uma engenharia personalizada substancial.

TrueFoundry atua como a camada de infraestrutura. Nós cuidamos da orquestração, deixando você com controle sobre a VPC e a residência de dados. Esta publicação detalha nossos padrões de integração com o GCP, especificamente em relação à arquitetura de plano dividido, Federação de Identidade de Carga de Trabalho, e gerenciamento de TPU.

Modelo de Implantação: Arquitetura de Plano Dividido

Utilizamos uma arquitetura de plano dividido para isolar a interface de gerenciamento do seu ambiente de execução de carga de trabalho.

1. O Plano de Controle: Nosso servidor de API e painel hospedados. Ele gerencia metadados, RBAC e agendamento de tarefas.
2. O Plano de Computação: Agentes e controladores executados diretamente no seu cluster GKE. Ele gerencia pesos de modelo, dados do cliente e inferência.

Limite de Segurança Não exigimos regras de firewall de entrada. O Agente no seu cluster inicia um fluxo WebSocket ou gRPC seguro e apenas de saída para o nosso Plano de Controle. Ele consulta manifestos de implantação e envia telemetria. Sua VPC permanece privada para o tráfego de entrada externo.

Fig. 1: A Arquitetura de Plano Dividido isola o processamento de dados dentro da VPC do cliente.

Topologia de Rede

Para alto desempenho, configuramos o plano de computação para usar clusters nativos de VPC usando IPs de Alias. Todos os recursos de computação residem em sub-redes privadas.

Ingress (Solicitações de Inferência) O tráfego da aplicação entra na VPC via Cloud Load Balancing (tipicamente um ALB Externo Global). O ALB encerra o TLS e encaminha as solicitações para o Istio Ingress Gateway em execução dentro do cluster GKE.

Private Google Access Para manter a conformidade, o tráfego para as APIs do Google (Cloud Storage, Vertex AI) é roteado via Private Google Access. Isso mantém o tráfego entre os pods de inferência e os serviços gerenciados do GCP na rede principal do Google, ignorando a internet pública.

Saída Os nós de trabalho do GKE exigem acesso de saída para extrair imagens de contêiner de Artifact Registry. Roteamos esse tráfego através do Cloud NAT anexadas às sub-redes privadas.

Fig 2: Fluxo de tráfego de rede detalhando a entrada e a conectividade privada.

Federação de Identidades

Impomos a remoção de chaves estáticas de Contas de Serviço (arquivos .json). A TrueFoundry implementa Identidade de Carga de Trabalho do GKE para toda a autenticação de carga de trabalho.

A Sequência de Autenticação

1. Criação: Ao implantar um serviço, criamos uma Conta de Serviço do Kubernetes (KSA).
2. Vinculação: Anotamos a KSA para vinculá-la a uma Conta de Serviço do Google (GSA) através da vinculação roles/iam.workloadIdentityUser.
3. Troca: O servidor de metadados do GKE intercepta as solicitações, trocando o token KSA por um token de acesso de curta duração do Google Cloud.
4. Acesso: O pod usa este token para autenticar nativamente (ADC) com recursos como BigQuery ou Vertex AI.

Se um pod for comprometido, o raio de impacto é estritamente limitado às funções IAM concedidas a essa GSA específica.

Fig 3: O fluxo de autenticação da Identidade de Carga de Trabalho do GKE.

Computação: Otimização de TPU e Spot

Integramos com Pools de Nós GKE para orquestrar GPUs NVIDIA e TPUs na Nuvem.

Orquestração de TPU O agendamento em TPUs exige o tratamento de restrições de topologia específicas. O TrueFoundry gerencia o nodeSelector e as tolerations necessários para agendar pods em fatias de TPU (por exemplo, v4-8, v5e). Injetamos automaticamente os drivers e limites de recursos necessários no manifesto de implantação, abstraindo a configuração de baixo nível do Kubernetes.

Gerenciamento de VMs Spot Para processamento em lote ou cargas de trabalho de desenvolvimento, gerenciamos VMs Spot para reduzir custos (tipicamente 60-90% em comparação com sob demanda).

• Provisionamento: Orquestramos Pools de Nós com provisionamento spot ativado.
• Tratamento de Encerramento: Monitoramos o aviso de preempção de 30 segundos. Após a detecção, isolamos o nó e acionamos o agendador para mover o pod para um pool On-Demand de fallback ou um nó Spot alternativo.

Gateway de IA: Interface Unificada

Gerenciar chaves distintas para modelos como Gemini Pro cria sobrecarga operacional. O TrueFoundry oferece um Gateway de IA que atua como uma interface de API unificada.

• Autenticação Unificada: Autentique-se uma vez contra o Gateway. Lidamos com a troca de Workload Identity downstream com o Vertex AI.
• Troca de Modelo: Mude do Gemini Pro para um Llama-3-70b auto-hospedado alterando um parâmetro de configuração. Sem reescritas de código.
• Atribuição de Custos: Registramos o uso de tokens por projeto, permitindo que você atribua os custos compartilhados do Vertex AI de volta aos centros de custo internos.

Comparação Operacional

Resumo

Esta integração permite que sua equipe explore totalmente as vantagens de hardware do GCP — especificamente TPUs e redes de alta vazão — sem se prender à fricção operacional do gerenciamento puro do Kubernetes. O TrueFoundry atua como um multiplicador de força para sua infraestrutura: nós abstraímos a complexidade da orquestração GKE enquanto você mantém autoridade absoluta sobre segurança e residência de dados. Este equilíbrio permite que você operacionalize cargas de trabalho de GenAI imediatamente, transformando a infraestrutura de uma restrição em uma vantagem de velocidade competitiva.

‍