Quando o Kubernetes foi lançado há uma década, sua promessa era clara: tornar o deployment de microservices tão simples quanto rodar um container. Avançando para 2026, o Kubernetes não é mais "apenas" para serviços web stateless. No levantamento anual da CNCF de janeiro de 2026, 82% dos usuários de containers relatam rodar Kubernetes em produção, e 66% das organizações que hospedam modelos de General AI (IA Generativa) utilizam Kubernetes para parte ou a totalidade de seus workloads de inference.
A conversa mudou fundamentalmente: de aplicações web stateless para processamento de dados distribuído, jobs de treinamento (training) distribuídos, inference de LLM e agentes de IA autônomos. Isso não é apenas evolução; é uma convergência de plataforma impulsionada por uma realidade prática: rodar processamento de dados, treinamento de modelos, inference e agentes em infraestruturas separadas multiplica a complexidade operacional. O Kubernetes oferece a fundação unificada necessária para todos eles sob uma ótica de eficiência e escala.
Três eras, uma plataforma
A jornada do Kubernetes espelha a evolução do software moderno:
- Era dos Microservices (2015–2020): Amadurecimento de serviços stateless, padrões de rollout e plataformas multi-tenant.
- Era de Dados + GenAI (2020–2024): Trouxe o processamento de dados distribuído e workloads intensivos em GPU para o mainstream.
- Era Agêntica (2025+): Muda o foco de APIs de request/response para loops de raciocínio de longa duração.
Cada onda se apoia na anterior, criando uma plataforma única onde processamento de dados, training, inference e agentes coexistem.
Fundação: Processamento de dados em escala
Antes dos modelos serem treinados, os dados precisam ser preparados. O Kubernetes agora é a plataforma unificada onde o Data Engineering e o Machine Learning convergem, lidando tanto com ETLs de estado estável quanto com picos de demanda (burst workloads) que escalam de centenas para milhares de cores em minutos. De acordo com o relatório da comunidade Data on Kubernetes de 2024, quase metade das organizações já roda 50% ou mais de seus workloads de dados em Kubernetes em produção.
O Apache Spark continua sendo o padrão ouro para processamento em larga escala. O Kubeflow Spark Operator permite o gerenciamento declarativo do Spark dentro do ecossistema. Organizações rodam Spark em escala massiva: milhares de nodes e mais de 100k cores em clusters únicos. O Spark pré-processa petabytes de dados e dispara jobs de training downstream, tudo orquestrado via primitivas nativas do Kubernetes.
Orquestração: Conectando o Pipeline
Coordenar workflows de múltiplas etapas é crítico. Um pipeline de ML típico envolve pré-processamento no Spark, treinamento distribuído em milhares de GPUs, validação e deployment do modelo. Realizar isso manualmente não escala.
O Kubeflow Pipelines oferece workflows de ML portáteis com tracking de experimentos. O Argo Workflows permite DAGs complexos que abrangem desde jobs Spark até deployments via KServe. Essa camada de orquestração transforma scripts ad-hoc em pipelines de produção que disparam retreinamentos automaticamente ao detectar data drift.
Training: Gang Scheduling e coordenação de recursos
O desafio fundamental do treinamento distribuído é a coordenação de recursos. Solicitar 120 GPUs mas ter apenas 100 disponíveis resulta em 100 GPUs ociosas, queimando orçamento (FinOps) e bloqueando o trabalho. Este é o estado padrão em clusters compartilhados.
O Gang Scheduling tornou-se indispensável. Projetos como Volcano e Apache Yunikorn pioneiraram o padrão onde jobs só iniciam quando todos os recursos solicitados estão disponíveis. O Kueue está emergindo como o padrão da comunidade para gerenciamento de batch workloads, trazendo gerenciamento de cotas e fair-share scheduling, resolvendo a disputa por GPUs entre times. O JobSet complementa isso fornecendo uma API nativa para gerenciar grupos de Jobs distribuídos com tratamento de falhas coordenado.
Serving: Inference em escala
Após o treinamento, o serving de predições exige uma abordagem diferente. Training é batch e GPU-saturated; Inference é online, latência-sensível e precisa lidar com tráfego imprevisível.
vLLM e SGLang tornaram-se padrões para serving de LLM de alto throughput, utilizando PagedAttention e continuous batching. O KServe fornece uma camada padronizada de model serving com autoscaling, versionamento e traffic splitting, integrando-se ao Knative para workloads scale-to-zero.
Workloads Agênticos: Construindo o Sistema Operacional de Agentes
A tendência mais recente são os agentes autônomos. Ao contrário de predições únicas, os agentes fazem cadeias de chamadas de LLM, mantêm estado de conversação e acessam ferramentas externas por longos períodos. Eles exigem gestão de estado e barreiras de segurança (SecOps).
Frameworks como LangGraph fornecem orquestração de agentes stateful. O KEDA permite o autoscaling orientado a eventos, crucial quando 100 requisições de usuários precisam de 100 pods de agentes instantaneamente. Em termos de segurança, o isolamento via gVisor ou Kata Containers ajuda a proteger o ambiente contra caminhos de código não confiáveis, enquanto políticas de OPA ou Kyverno definem as guardrails em tempo de execução.
Otimizando a Economia das GPUs
Nesses workloads, a disponibilidade e custo de GPU predominam. O gargalo não é mais CPU ou memória, mas maximizar a utilização de hardware caro.
A evolução do compartilhamento de GPU trouxe tecnologias como Multi-Instance GPU (MIG), Time-slicing e Multi-Process Service (MPS). O Dynamic Resource Allocation (DRA) no Kubernetes vai além dos Device Plugins, permitindo o particionamento e a reatribuição de GPUs em runtime. Na camada de infraestrutura, ferramentas como o Karpenter provisionam tipos exatos de instâncias e desprovisionam capacidade ociosa agressivamente, garantindo eficiência em FinOps.
O Caminho a Seguir
As métricas de sucesso das plataformas estão mudando. O foco agora é tokens-per-second-per-dollar, não mais densidade de pods. A confiabilidade agora inclui monitorar drifts de saída e degradação da qualidade do modelo. A observabilidade deve rastrear loops de raciocínio e chamadas de ferramentas.
A boa notícia para gestores de TI brasileiros: grande parte disso está sendo construída em código aberto, transformando o Kubernetes na fundação onde times de IA constroem sistemas de ponta a ponta, e não apenas onde fazem o deployment de containers.
Artigo originalmente publicado por Sabari Sawant, Amazon em Cloud Native Computing Foundation.
