Orquestração de GPU Multi-Nuvem com TrueFoundry: Uma Arquitetura de Referência para Hiperescaladores e Nuvens Especializadas

A capacidade de GPU é uma das restrições mais difíceis para as equipes de IA atualmente. O provisionamento de instâncias Amazon EC2 P5 ou VMs Azure ND H100 v5-series pode esbarrar em limites de cota, restrições de capacidade regional ou compromissos comerciais difíceis de absorver. Isso tornou as nuvens de GPU especializadas — CoreWeave, Lambda, Fluidstacke várias outras — alvos de produção viáveis, não apenas capacidade excedente. Cada um desses provedores oferece um caminho Kubernetes gerenciado para cargas de trabalho de GPU: CoreWeave Kubernetes Service (CKS), Lambda Managed Kubernetes (MK8s) em um Cluster de 1 Clique, e Fluidstack managed Kubernetes.

Operar em todos esses, juntamente com uma pegada de hiperescalador, cria uma complexidade operacional real: dashboards separados, sistemas de identidade separados, observabilidade separada, fluxos de implantação separados. O papel da TrueFoundry aqui é anexar cada um desses clusters Kubernetes a um único Plano de Controle, apresentá-los como alvos de implantação em uma única UI e fornecer uma camada operacional K8s consistente por cima — sem substituir a automação nativa do cluster que cada provedor já oferece.

Este post detalha como isso realmente funciona: a arquitetura, o que anexar um cluster exige, onde a automação da plataforma termina e a do provedor começa, e os padrões práticos que recomendamos.

A Arquitetura: Um Plano de Controle, Muitos Planos de Computação

A TrueFoundry utiliza uma arquitetura de plano dividido. O Plano de Controle (gerenciado pela TrueFoundry ou auto-hospedado) contém metadados, RBAC, manifestos de implantação e a interface do usuário. O Plano de Computação é o seu próprio cluster Kubernetes. Múltiplos Planos de Computação podem se conectar a um único Plano de Controle — o que significa que um cluster EKS, um cluster AKS, um cluster CKS, um cluster MK8s e um cluster K8s gerenciado pela Fluidstack podem todos reportar ao mesmo painel.

O tfy-agent executa em cada cluster e abre um WebSocket de saída seguro para o Plano de Controle. O agente transmite o estado do cluster, enquanto o proxy do agente permite que o Plano de Controle aplique alterações no Kubernetes através dessa conexão de saída, sem exigir um endpoint de entrada no cluster. Cargas de trabalho, tráfego do plano de dados e credenciais do provedor permanecem dentro da conta de nuvem de cada cluster, e o tráfego não flui entre os Planos de Computação através do Plano de Controle — eles permanecem nuvens independentes com identidades independentes.

O que "Anexar um Cluster" Realmente Exige

A instalação do agente em si é um único comando helm — mas ela se encontra no final de uma configuração que possui pré-requisitos reais. Para que qualquer cluster (hiperescalável ou especializado) seja anexado de forma limpa, o cluster precisa de:

• Kubernetes 1.28+ com folga para aproximadamente 250 nós / 4.096 pods, dependendo do perfil de carga de trabalho pretendido
• Conectividade de saída para os registros de contêineres dos quais a TrueFoundry extrai: public.ecr.aws, quay.io, ghcr.io, tfy.jfrog.io, docker.io/natsio, nvcr.io, registry.k8s.io
• Um domínio curinga (ex.: *.lambda-pool.example.com) e um certificado TLS — cert-manager + Let's Encrypt é o padrão documentado
• Um balanceador de carga funcional ou caminho de entrada (ingress). K8s de hiperescala gerenciado geralmente fornece isso através da integração do balanceador de carga da nuvem; em clusters bare-metal ou especializados, confirme o ingress e o caminho de alocação de IP suportados pelo provedor
• Suporte a armazenamento persistente para volumes e artefatos, tipicamente através das integrações de bloco, sistema de arquivos ou armazenamento de objetos baseadas em CSI do provedor
• Um registro de contêiner e armazenamento de artefatos acessível para pulls de imagem, saídas de build e artefatos de fluxo de trabalho
• Rótulos de nó em clusters genéricos / especializados: truefoundry.com/nodepool=<pool-name> em cada nó, e truefoundry.com/gpu_type=<GPU_TYPE> em nós de GPU (TrueFoundry descobre automaticamente pools de nós apenas em EKS/GKE/AKS)

Em K8s de hiperescala gerenciados, os módulos OpenTofu/Terraform da TrueFoundry cobrem a maior parte disso. Em nuvens especializadas, você usa a oferta de K8s gerenciados do provedor diretamente — provisione através do console deles, prepare os pré-requisitos e, em seguida, anexe. O comando exato de instalação do agente é gerado pela interface do usuário da plataforma quando você clica em Anexar Cluster Existente; ele geralmente segue este formato:

helm repo add truefoundry https://truefoundry.github.io/infra-charts/
helm upgrade --install tfy-agent truefoundry/tfy-agent \
  --set tenantName=my-org \
  --set clusterName=lambda-h100-pool \
  --set controlPlaneURL=https://<YOUR_CONTROL_PLANE> \
  --set clusterTokenSecret=<YOUR_CLUSTER_TOKEN_SECRET>

Especificidades da Nuvem Especializada: o Problema de Sobreposição de Addons

Esta é a parte que muitos artigos de arquitetura ignoram. As nuvens especializadas mencionadas anteriormente já fornecem componentes Kubernetes que se sobrepõem a partes da pilha de addons padrão da TrueFoundry. Se ambos os lados instalarem o mesmo componente, você pode ter conflitos que variam de painéis duplicados a implantações de operadores de GPU não suportadas.

A CoreWeave é explícita sobre isso: A CoreWeave gerencia o NVIDIA GPU Operator em clusters CKS e adverte contra a instalação duplicada. A implantação gerenciada pela plataforma é a única suportada. Desative o addon GPU Operator da TrueFoundry ao anexar um cluster CKS.

Concretamente:

• CoreWeave CKS inclui um NVIDIA GPU Operator gerenciado pela CoreWeave em clusters recentes, rede Cilium, integrações de armazenamento, infraestrutura baseada em DPU e observabilidade CoreWeave. Ao anexar, desative o da TrueFoundry GPU Operator addon e revise qualquer sobreposição de observabilidade.
• Lambda MK8s fornece suporte a GPU e InfiniBand/RDMA, armazenamento persistente compartilhado através do lambda-shared StorageClass, painéis NVIDIA DCGM Grafana e remediação automatizada de nós. Desative o da TrueFoundry GPU Operator complemento se o Lambda já estiver gerenciando a habilitação de GPU. O painel DCGM do provedor é separado da observabilidade da TrueFoundry e pode funcionar em paralelo.
• Kubernetes gerenciado pela Fluidstack oferece suporte para GPU Operator e Network Operator, Ray, Volcano e Kueue para agendamento em lote, armazenamento gerenciado pelo Atlas e observabilidade da saúde do cluster. Desative o da TrueFoundry GPU Operator complemento quando o provedor já o estiver gerenciando. A pilha de agendamento em lote do provedor é complementar, e não um substituto, para a orquestração de fluxo de trabalho.

O Anexar Cluster Existente formulário tem uma seção de Complementos de Cluster onde você desativa qualquer complemento que o provedor já forneça. Esta é uma decisão única por cluster.

O que a TrueFoundry Adiciona em Todos os Clusters

Uma vez que um cluster é anexado, a plataforma oferece uma experiência operacional consistente sobre qualquer K8s que o provedor tenha fornecido:

• Uma única interface de usuário para cada cluster. Cada implantação, cada trabalho, cada serviço, cada espaço de trabalho — visível em todos os clusters anexados no mesmo painel.
• Formato consistente de manifesto de implantação. Crie um serviço ou trabalho uma vez; direcione para um cluster diferente alterando o campo cluster_name — desde que os pré-requisitos no cluster de destino correspondam (tipo de GPU correspondente, acesso ao registro, segredos, classe de armazenamento).
• Entrega versionada por GitOps via ArgoCD implantado em cada cluster, com a configuração de implantação armazenada no Git quando o GitOps está ativado.
• Observabilidade por cluster, com métricas baseadas em Prometheus exibidas na UI do Painel de Controle e Grafana opcional para dashboards mais detalhados a nível de cluster. (Nota: esta é uma visibilidade operacional consolidada, não um substituto para um backend de métricas federado de longo prazo.)
• Argo Workflows em cada cluster para trabalhos em lote e execuções de treinamento, com histórico de execução e observabilidade a nível de etapa exibidos uniformemente.
• Autoescalonamento para serviços dentro de cada cluster, incluindo escalonamento baseado na taxa de requisições, regras baseadas em tempo, padrões baseados em fila e escalonamento para zero para cargas de trabalho adequadas.
• Alocação de tipo de capacidade dentro do cluster: as cargas de trabalho podem direcionar capacidade spot, sob demanda ou spot com fallback sob demanda, onde a nuvem subjacente e a configuração de provisionamento de nós o suportam.
• RBAC e SSO baseados em workspace na camada da plataforma, com modelos de permissão consistentes independentemente do cluster em que uma carga de trabalho é executada.

O que a TrueFoundry faz Não Faz (Ainda)

Para ser totalmente claro sobre o escopo — estas são capacidades reais que os clientes pedem, mas não são recursos da plataforma hoje:

• Agendamento entre clusters. Quando você implanta um trabalho, você direciona um cluster específico. A plataforma não escolhe automaticamente o cluster mais barato, não roteia com base na capacidade em tempo real, nem reequilibra cargas de trabalho em execução entre clusters.
• Failover entre clusters. Se um Lambda 1CC tiver problemas de hardware ou uma região CoreWeave ficar sem capacidade, a plataforma não tenta automaticamente o trabalho novamente em uma reserva EKS. Políticas de alocação e fallback dentro do cluster podem ajudar quando o cluster subjacente as suporta; o failover entre clusters é um problema diferente e não é fornecido.
• Pool de capacidade de GPU agregada. Sua capacidade de H100 na CoreWeave, Lambda e AWS é rastreada como três clusters separados — não como uma cota única e agrupada. A interface do usuário mostra todos os três; o agendador os trata como independentes.
• Roteamento automático com reconhecimento de custo. Escolher onde executar um trabalho com base nos preços em tempo real do provedor não é um recurso da plataforma hoje.

Se o seu caso de uso realmente exige orquestração entre clusters — por exemplo, um trabalho de treinamento que deve ser expandido para a nuvem mais barata disponível — construa essa decisão na camada de orquestração (sua lógica de CI/CD, um pequeno agendador personalizado ou uma ferramenta de fluxo de trabalho como Argo Workflows ou Temporal) sobre a API de implantação por cluster da TrueFoundry. A plataforma oferece as primitivas de implantação consistentes entre clusters; a decisão de roteamento permanece com você.

Um Fluxo de Trabalho Real: Anexando um Cluster Lambda 1-Click

Sequência concreta para que a expectativa seja definida corretamente:

1. Provisione um Cluster 1-Click na Lambda com Kubernetes Gerenciado ativado. Escolha o tamanho (16 a mais de 2.000 GPUs) e a duração da reserva.
2. Obtenha acesso de administrador do cluster através do fluxo de autenticação da Lambda e verifique kubectl get nodes mostra seus workers de GPU como Ready.
3. Prepare os pré-requisitos no cluster: configure o DNS curinga e o caminho de entrada (ingress), instale ou verifique a automação de certificados TLS, confirme que o lambda-shared StorageClass está presente se precisar de armazenamento compartilhado, e verifique a saída para os registros de contêiner necessários da TrueFoundry.
4. No TrueFoundry, clique em "Attach Existing Cluster" e preencha os detalhes do cluster. Desativar o addon do Operador de GPU quando a Lambda já está fornecendo habilitação de GPU.
5. Execute o comando helm gerado no seu cluster. Aguarde que o agente e quaisquer addons selecionados estejam operacionais — geralmente 5 a 10 minutos depois que os pré-requisitos estiverem configurados.
6. Configurar tolerâncias no workspace TrueFoundry que tem como alvo este cluster. Os nós MK8s possuem taints de GPU que precisam ser tolerados; a configuração de tolerância em nível de workspace os aplica a cada tarefa submetida a esse cluster.
7. Verificar se o cluster aparece como conectado, em seguida, implante uma pequena tarefa de teste (um serviço vLLM de GPU única ou uma execução de treinamento de um nó) antes de mover cargas de trabalho de produção.

O tempo total em um cluster preparado é geralmente de 30 a 60 minutos, dominado pela propagação de DNS, emissão de certificados e instalação do helm.

Comparação Prática

Conclusão

A estratégia de GPU multi-nuvem é real e cada vez mais prática à medida que a capacidade de computação se torna uma restrição nos roteiros de IA. O caminho pragmático é tratar cada cluster — seja EKS, AKS, GKE, CKS, MK8s ou Kubernetes gerenciado pela Fluidstack — como um anexo Kubernetes padrão, com a plataforma fornecendo uma camada operacional consistente por cima.

O que você obtém: uma única interface de usuário em todos os clusters que você anexou, padrões consistentes de implantação e GitOps independentemente da nuvem, portabilidade de carga de trabalho no nível do manifesto (onde os pré-requisitos correspondem) e separação completa de dados entre as contas de nuvem do cliente. O que você não obtém hoje: agendamento automático entre clusters, pooling de capacidade ou roteamento com consciência de custo — essas decisões permanecem com você, construídas sobre a API de implantação por cluster da plataforma.

Se você está avaliando esta pilha, o ponto de partida natural é anexar dois clusters — um de hiperescala e um especializado — e executar uma tarefa representativa em cada um para validar a ergonomia operacional antes de escalar.

‍