Como dimensionar a rede do Kubernetes para sandboxes efêmeros de agentes de IA

Considere uma plataforma corporativa na qual agentes de inteligência artificial executam testes, consultam APIs e processam documentos em ambientes descartáveis. Cada tarefa cria um sandbox, baixa dependências, abre conexões e termina poucos minutos depois. O desafio de capacidade não é apenas quantos ambientes ficam ativos: é quantos precisam nascer, comunicar-se e desaparecer por segundo.

Este artigo complementa Como desenhar sandboxes efêmeros para agentes de IA no Kubernetes, que trata de isolamento, Jobs e expiração. Aqui o assunto é capacidade de rede. Usaremos esse cenário para construir um modelo de dimensionamento. Os números são hipotéticos, não benchmarks. A proposta é transformar concorrência, rotatividade e dependências externas em orçamentos explícitos de endereçamento, DNS, conexões e tráfego.

1. O que estamos dimensionando

Um sandbox efêmero é um ambiente de execução com duração limitada e descarte controlado. Nesta arquitetura, cada execução utiliza um Pod, normalmente gerenciado por um Job. Containers do mesmo Pod compartilham a rede; adicionar um sidecar não significa, por si só, adicionar outro IP. Um Pod comum, entretanto, não constitui uma fronteira suficiente para todo cenário de código hostil: isolamento por runtime, nós ou clusters pode ser necessário. (kubernetes.io)

Os componentes relevantes são:

• CNI — Container Network Interface: integra a configuração de rede dos Pods ao ambiente de execução.
• IPAM — IP Address Management: controla a alocação e a devolução de endereços.
• Service: fornece descoberta e acesso estável a um conjunto de endpoints; seu endereçamento não deve ser confundido com o pool de IPs dos Pods.
• NetworkPolicy: descreve permissões de comunicação implementadas pelo componente de rede compatível.
• DNS — Domain Name System: resolve nomes de serviços e destinos externos. (kubernetes.io)

Para planejar capacidade, separe seis dimensões: IPs disponíveis, criações por segundo, consultas DNS, conexões simultâneas, novas conexões por segundo e bytes/pacotes por segundo. Não trate a capacidade de rede como uma consequência automática da disponibilidade de CPU.

2. Arquitetura de referência

Uma arquitetura proposta para produção é:

Cliente → API da plataforma → fila → controlador de execução → Job → Pod isolado

O caminho de saída fica separado:

Pod → política de rede → proxy de egress → NAT ou endpoint privado → destino autorizado

O controlador mantém o estado da execução, aplica limites por tenant e admite trabalho conforme o orçamento disponível. O proxy centraliza autenticação, auditoria e autorização de destinos. Prefira poucas políticas reutilizáveis por perfil de execução em vez de gerar uma política exclusiva para cada tarefa.

Nesta proposta, os sandboxes não recebem Load Balancer individual. A comunicação interativa passa por um gateway compartilhado e autenticado. Também não recebem acesso direto ao banco operacional da plataforma: resultados são enviados por uma interface restrita.

Decisão importante: o proxy é parte da fronteira de segurança, não apenas um encaminhador. Sua configuração deve rejeitar destinos internos não autorizados, metadata services, redirecionamentos indevidos e tentativas de contornar a autorização por resolução DNS. Esses controles precisam de testes negativos próprios.

3. Dimensionamento: da taxa de chegada ao orçamento de IPs

Concorrência e rotatividade

Comece com uma aproximação de regime estável:

N_medio ≈ lambda_media × T_medio
N_projeto = ceil(lambda_pico_sustentado × T_planejado × H)

lambda é a taxa de execuções admitidas por segundo; T é o tempo de ocupação; H é uma margem explícita de planejamento. A segunda expressão é uma heurística: valide-a com a distribuição real de durações e com o perfil temporal do pico. Multiplicar percentis isolados não produz automaticamente um percentil de concorrência.

Exemplo hipotético:

Assim, a concorrência média estimada é 8 × 120 = 960. O orçamento de projeto é 16 × 120 × 1,25 = 2.400 execuções simultâneas.

Meça também o intervalo entre o término da aplicação e a reutilização efetiva do IP. Não confunda esse intervalo com a retenção do objeto Job: a existência do objeto na API não prova que o endereço continua ocupado. O ciclo de vida do Pod e a limpeza do runtime precisam ser observados separadamente. (kubernetes.io)

IPs por zona, inclusive durante falhas

Use uma conta por pool de endereços:

IPs_necessarios = Pods_com_IP
                 + IPs_em_liberacao
                 + IPs_pre_alocados_ociosos
                 + infraestrutura
                 + sobreposicao_de_upgrade

No exemplo, suponha 30 segundos de retenção efetiva após o trabalho e um Pod por execução:

IPs_em_liberacao = 16 × 30 = 480

Para suportar a perda de uma das três zonas, suponha redistribuição uniforme entre as duas restantes. Cada zona sobrevivente precisaria comportar:

(2.400 + 480) / 2 = 1.440 IPs

Acrescente, hipoteticamente, 256 endereços ociosos pré-alocados e 150 para infraestrutura e sobreposição de manutenção: 1.440 + 256 + 150 = 1.846 endereços por zona sobrevivente. Esses valores precisam vir do inventário e do comportamento medido do IPAM; não são defaults recomendados.

Em uma subnet IPv4 convencional da AWS, cinco endereços são reservados. Portanto, uma /21 oferece 2.043 endereços utilizáveis e sobrariam apenas 197 nesse cenário. Uma /20, com 4.091, seria uma candidata mais confortável, sujeita ao plano corporativo de endereçamento. Não extrapole essa conta para todo provedor ou modo de CNI. (docs.aws.amazon.com)

Densidade não é apenas disponibilidade de IP

Calcule também:

Pods_sandbox_por_no = min(
  limite_de_Pods_menos_Pods_de_sistema,
  capacidade_por_CPU,
  capacidade_por_memoria,
  capacidade_de_rede_validada
)

Se o teto operacional validado for 72 sandboxes por nó, 1.200 execuções ativas em uma zona exigirão pelo menos ceil(1.200 / 72) = 17 nós. Esse é um piso ilustrativo; reservas e outros consumidores podem elevar o total. Requests de CPU e memória participam do agendamento, mas não representam uma reserva universal de banda de rede. (kubernetes.io)

4. Particularidades do Amazon EKS

No Amazon Elastic Kubernetes Service, com Amazon VPC CNI em modo de prefixos IPv4, os prefixos delegados são /28, com 16 endereços. É necessário espaço contíguo; ter muitos IPs livres fragmentados pode não ser suficiente. WARM_IP_TARGET e MINIMUM_IP_TARGET, quando configurados, prevalecem sobre WARM_PREFIX_TARGET. (docs.aws.amazon.com)

Minha recomendação operacional é testar a combinação de tipo de instância, limite de Pods e política de pré-alocação em um node group canário. Compare tempo de inicialização, endereços reservados e erros de alocação antes de expandir. Delegar prefixos não elimina a necessidade de planejar a subnet.

Com rede overlay, o consumo de endereços da infraestrutura muda, mas permanece necessário dimensionar os blocos de Pods. Encapsulamento também exige atenção à MTU, a unidade máxima de transmissão. Uma alternativa é roteamento nativo, que transfere mais requisitos para a rede subjacente. (docs.cilium.io)

5. Banda, DNS e conexões

Banda: modele o início da execução

Suponha 60 MB decimais de transferência efetiva por nova execução, já considerando cache de imagens no nó e downloads feitos pela aplicação:

B_inicio = 16 × 60 MB/s = 960 MB/s = 7,68 Gbit/s
B_com_margem = 7,68 × 1,30 = 9,984 Gbit/s

Esse valor ainda não inclui tráfego durante a execução, logs e replicação. Distribua a estimativa pelos caminhos reais: registry para nós, Pod para proxy e proxy para internet. Não atribua todo download de imagem ao IP do Pod, nem conte a imagem integral em cada execução quando há cache.

Valide bytes por segundo e pacotes por segundo separadamente. Para os ensaios, compare downloads grandes, chamadas curtas, streaming e conexões ociosas; não use um único teste de throughput como certificação de capacidade.

DNS: conte consultas, não apenas sandboxes

Uma estimativa proposta é:

QPS_DNS = criacoes_por_segundo × consultas_por_inicio
          + Pods_ativos × consultas_por_segundo_por_Pod

Com 40 consultas por início e duas por segundo por sandbox, o exemplo resulta em 16 × 40 + 2.400 × 2 = 5.440 consultas/s. Defina se os números representam chamadas da aplicação ou consultas efetivamente transmitidas: search domains, ndots, A/AAAA, cache e retries alteram a relação. (kubernetes.io)

NodeLocal DNSCache pode reduzir o tráfego de resolução que atravessa o caminho convencional de Service e conntrack. Porém, introduz um componente por nó que também precisa de capacidade e monitoração. Ajuste as políticas para o caminho DNS efetivamente utilizado. (kubernetes.io)

Conexões: conte cada salto

Adotando 12 conexões simultâneas por execução, o orçamento inicial é 2.400 × 12 = 28.800 conexões. Isso não implica 28.800 conexões externas se houver pooling no proxy; tampouco significa que a infraestrutura inteira mantém apenas esse número de estados.

Para cada salto, estime separadamente conexões abertas e estados residuais:

estados_residuais ≈ encerramentos_por_segundo × tempo_medio_de_retencao

No Linux, nf_conntrack_count informa entradas alocadas e nf_conntrack_max limita a tabela. Não aumente o limite sem avaliar memória, padrão de tráfego e timeouts; em dataplanes alternativos, monitore também as tabelas específicas da implementação. (docs.kernel.org)

No NAT Gateway da AWS, cada IPv4 suporta até 55.000 conexões simultâneas para um destino único, definido por IP, porta e protocolo. Esse limite não é uma capacidade global do cluster. Em uma arquitetura com NAT zonal, preserve saída por zona e capacidade de contingência. (docs.aws.amazon.com)

Prefira pools limitados, reutilização de conexões, deadlines, retries com backoff e jitter e limites de concorrência por destino. Trate essas escolhas como controles de carga a validar, não como substitutos para medir o provedor externo.

6. Configuração: política de saída restrita

O exemplo abaixo cria um namespace e permite aos Pods identificados como sandbox apenas DNS e acesso a um proxy interno. É uma base didática, não um ambiente completo: o proxy, seu Service e suas regras de autorização devem existir previamente.

apiVersion: v1
kind: Namespace
metadata:
  name: agent-sandboxes
  labels:
    pod-security.kubernetes.io/enforce: restricted
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-and-egress-proxy
  namespace: agent-sandboxes
spec:
  podSelector:
    matchLabels:
      workload: agent-sandbox
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: platform-egress
          podSelector:
            matchLabels:
              app: egress-proxy
      ports:
        - protocol: TCP
          port: 3128

Esta política parte de um default-deny já aplicado ao namespace, como no desenho de sandboxes efêmeros, que também detalha runtime, identidade e ciclo de vida. Aqui o foco é o que esse desenho não cobre: quanto DNS e egress o proxy precisa suportar. Os seletores de namespace e Pod no mesmo item são combinados, e o CNI precisa implementar NetworkPolicy. (kubernetes.io)

Adapte labels, porta do proxy e caminho DNS. Esta regra pressupõe CoreDNS acessível pelos Pods selecionados, não NodeLocal DNSCache. Se o namespace do proxy também bloquear entrada, adicione a permissão correspondente do lado dele. Verifique DNS UDP e TCP e tentativas de saída direta antes de admitir tarefas reais.

Job completo para validar DNS

apiVersion: batch/v1
kind: Job
metadata:
  name: sandbox-dns-check
  namespace: agent-sandboxes
spec:
  backoffLimit: 0
  activeDeadlineSeconds: 60
  ttlSecondsAfterFinished: 300
  template:
    metadata:
      labels:
        workload: agent-sandbox
    spec:
      automountServiceAccountToken: false
      restartPolicy: Never
      securityContext:
        runAsNonRoot: true
        runAsUser: 10000
        runAsGroup: 10000
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: check
          image: busybox:1.37.0
          command:
            - sh
            - -c
            - nslookup kubernetes.default.svc.cluster.local
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL
          resources:
            requests:
              cpu: 100m
              memory: 32Mi
            limits:
              cpu: 200m
              memory: 64Mi

Esse Job executa somente uma consulta DNS; não executa um agente nem comprova acesso pelo proxy. backoffLimit evita retries automáticos neste teste, activeDeadlineSeconds limita a execução e ttlSecondsAfterFinished permite limpeza posterior do Job. (kubernetes.io)

Ajuste o domínio do cluster, recursos e imagem; em produção, fixe a imagem aprovada por digest. O exemplo não configura runtimeClassName: portanto, não oferece isolamento adicional ao runtime padrão. Adicione uma RuntimeClass instalada e validada quando o modelo de ameaça exigir.

Não há probes porque o processo é um teste curto. Para APIs e proxies persistentes, configure readiness, liveness e, quando necessário, startup probes. Evite fazer a liveness depender de um provedor externo: isso transforma indisponibilidade externa em reinicializações locais. (kubernetes.io)

7. Produção: admissão, disponibilidade e segurança

Proponho que a plataforma limite execuções por tenant e por zona antes de criar Pods. O orçamento de admissão deve considerar a menor capacidade disponível entre IPs, DNS, egress e computação. Ao atingir o limite, mantenha tarefas na fila com prazo explícito ou rejeite novas solicitações; não dependa apenas de retries.

Para componentes persistentes, distribua réplicas entre zonas com topology spread ou anti-affinity. Use PodDisruptionBudget para controlar interrupções voluntárias, lembrando que ele não impede perda de nós ou de uma zona. Para sandboxes interrompíveis, prefira checkpoints e reexecução idempotente. (kubernetes.io)

Separe o controlador privilegiado dos executores. RBAC, controle de acesso baseado em papéis, deve impedir que sandboxes criem workloads ou alterem políticas. Para código não confiável, avalie runtimes sandboxed, nós dedicados ou clusters separados conforme criticidade e compliance. (kubernetes.io)

Se houver acesso à AWS, use IAM, Identity and Access Management, com identidade específica do workload por EKS Pod Identity ou IAM Roles for Service Accounts, conforme compatibilidade. Não distribua credenciais do nó ou chaves estáticas compartilhadas. (docs.aws.amazon.com)

Como política operacional, exija TLS, credenciais curtas, rotação de Secrets e ausência de tokens nos logs. Desabilitar o token padrão no YAML não configura uma identidade AWS; qualquer integração deve ser acrescentada e testada explicitamente.

8. Observabilidade e testes de capacidade

Defina um SLO, objetivo de nível de serviço, para o tempo entre admissão e primeiro acesso autorizado bem-sucedido. A decomposição proposta é: espera na fila, agendamento, configuração de rede, download, DNS, conexão TCP e negociação TLS.

Organize dashboards por zona, perfil de execução e destino:

No NAT Gateway, acompanhe especialmente ErrorPortAllocation, PacketsDropCount, ActiveConnectionCount e IdleTimeoutCount. Correlacione-os com o destino e o comportamento das aplicações. (docs.aws.amazon.com)

Uma implementação possível usa Prometheus e Grafana para métricas, logs centralizados e traces instrumentados na plataforma. Mantenha identificadores individuais de sandbox em logs/traces, não indiscriminadamente em labels de métricas.

O plano de teste recomendado inclui rampa, rajada, churn prolongado, cache frio, destino lento, falha de zona e upgrade com capacidade sobreposta. Inclua testes de negação de tráfego. O critério de aprovação deve combinar latência, erros, isolamento e recuperação, não somente o total de Pods criados.

9. Troubleshooting orientado a sintomas

Use eventos, estado e logs para distinguir falha de agendamento, preparação do Pod e aplicação. (kubernetes.io)

kubectl get nodes
kubectl get pods -n agent-sandboxes -o wide
kubectl get events -n agent-sandboxes --sort-by=.metadata.creationTimestamp
kubectl describe job sandbox-dns-check -n agent-sandboxes
kubectl logs job/sandbox-dns-check -n agent-sandboxes
kubectl get networkpolicy -n agent-sandboxes
kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide

Em Amazon EKS com o DaemonSet padrão do Amazon VPC CNI, inspecione uma instância afetada:

kubectl get pods -n kube-system -l k8s-app=aws-node -o wide
kubectl logs -n kube-system <aws-node-pod> -c aws-node --since=10m

Substitua <aws-node-pod> pelo Pod do nó afetado. Faça a investigação por hipótese:

• Pod preso em criação → possível falta de IP ou prefixo → eventos e logs do CNI → corrigir disponibilidade ou fragmentação antes de aumentar nós. (docs.aws.amazon.com)
• Timeout de nomes → possível saturação ou caminho DNS bloqueado → correlacionar consultas, políticas e resolvedor real → corrigir a regra ou capacidade identificada. (kubernetes.io)
• Conexões externas falham sob carga → possível falta de portas NAT → verificar `ErrorPortAllocation` → revisar pooling e distribuição de egress. (docs.aws.amazon.com)
• Transferências grandes falham em overlay → possível MTU incompatível → testar tamanhos e caminho → corrigir MTU e passagem de mensagens necessárias à descoberta de MTU. (docs.cilium.io)

Evite a correção automática de simplesmente reiniciar todos os sandboxes: primeiro limite novas admissões para não amplificar o incidente.

10. Custos, desenvolvimento e manutenção

NAT Gateway tem cobrança por disponibilidade e volume processado. Avalie endpoints privados para serviços compatíveis e compare o custo completo, incluindo endpoints e tráfego entre zonas. Cache e redução de downloads devem entrar no experimento de FinOps, sem presumir economia universal. (docs.aws.amazon.com)

Para esta arquitetura, recomendo medir custo por execução concluída, incluindo retries, logs, armazenamento e capacidade ociosa. Reserve Spot para tarefas recuperáveis e mantenha a capacidade crítica de DNS, proxy e controle em uma base estável. Não reduza requests apenas para aparentar melhor utilização.

Em desenvolvimento, uma réplica e menor escala podem bastar, mas preserve as mesmas regras de isolamento. Em produção, valide múltiplas zonas, health checks, alertas, recuperação e limites por tenant. Não replique tarefas com efeitos externos sem idempotência.

Versione CNI, políticas, DNS e proxy em GitOps. Faça upgrades por canário e mantenha node groups anteriores até concluir testes de conectividade e isolamento. O rollback proposto é interromper admissões, drenar o grupo novo e redirecionar execuções para a configuração validada; não suponha que toda mudança de CNI pode ser revertida com um simples comando de rollout.

Mantenha backup e teste de restauração do estado durável: fila, metadados, configurações e artefatos. Pods descartáveis não são a unidade de recuperação.

11. Quando utilizar e quais alternativas considerar

Esta abordagem é indicada quando há execuções concorrentes, múltiplos tenants, necessidade de auditoria e equipe capaz de operar rede e isolamento. Para poucas tarefas internas confiáveis, um pool pequeno de workers pode ser mais simples.

A comparação é um roteiro de avaliação, não um ranking. Faça uma prova de conceito com o mesmo perfil de tráfego e o mesmo modelo de ameaça antes de escolher.

Resumo prático

1. Dimensione concorrência e criações por segundo separadamente.
2. Inclua liberação de IPs, pré-alocação, falha de zona e upgrades.
3. Calcule banda de início, DNS e conexões por caminho e destino.
4. Restrinja saída e teste tentativas de contorno.
5. Controle admissão antes de consumir a última unidade de capacidade.
6. Valide recuperação e custo por execução, não apenas throughput.

Conclusão

Para sandboxes efêmeros, o produto da plataforma não é apenas um Pod: é uma execução com tempo de preparação previsível, acesso autorizado e descarte verificável.

A estratégia proposta conecta DevOps, SRE, Cloud e Platform Engineering por meio de contratos operacionais mensuráveis. A rede deixa de ser um requisito implícito e passa a ter orçamento, testes, limites de admissão e procedimento de recuperação. Essa disciplina permite aumentar a escala sem transformar cada pico de agentes em um experimento involuntário de capacidade.