Design Doc: EKS Multi-Tenant em Escala — Karpenter, Isolamento e Custo

Plataformas internas de Kubernetes crescem de forma orgânica. Uma equipe cria um cluster, outra pede acesso, e em dezoito meses você tem quarenta times compartilhando infraestrutura que foi desenhada para cinco. O resultado típico é um cluster onde ninguém sabe exatamente o que custa o quê, workloads críticos competem com jobs de batch por nós, e o blast radius de um namespace mal configurado pode afetar vizinhos.

O cenário que este documento aborda é uma plataforma EKS gerenciada por uma equipe de plataforma central, servindo entre 30 e 60 times de produto. Cada time é um tenant: tem seus próprios namespaces, repositórios, pipelines e, idealmente, sua própria conta de custo. O cluster precisa escalar de forma reativa e econômica, manter isolamento forte o suficiente para satisfazer auditoria de segurança, e produzir dados de custo granulares o suficiente para showback ou chargeback.

Os três vetores de falha mais comuns nesse modelo são: (1) isolamento insuficiente — um tenant consome recursos de outro por ausência de quotas ou network policies, ou pior, consegue escalar privilégios via RBAC mal configurado; (2) custo invisível — sem labels consistentes e ferramentas de alocação, a fatura da AWS vira um número agregado que ninguém consegue contestar ou otimizar; (3) autoscaling lento ou caro — Cluster Autoscaler com node groups fixos não acompanha picos heterogêneos de workload e tende a superprovisionamento por segurança. Karpenter resolve o terceiro vetor, mas precisa de guardrails para não virar um vetor de custo descontrolado em mãos de tenants sem restrições.

O modelo de isolamento adotado é namespace-as-tenant-boundary, com reforço em quatro camadas independentes. Nenhuma camada sozinha é suficiente; a defesa em profundidade é o princípio.

Camada 1 — Namespace e identidade: Cada tenant recebe um namespace dedicado (ou um conjunto deles, por ambiente: team-x-prod, team-x-staging). O provisionamento é automatizado via GitOps (ArgoCD ou Flux): um PR no repositório de plataforma cria o namespace, aplica ResourceQuota e LimitRange padrão, e cria o RoleBinding que concede ao ServiceAccount da equipe permissões de edit dentro do namespace, nunca cluster-admin. A política de RBAC segue o princípio de menor privilégio: equipes não conseguem criar ClusterRoles, acessar segredos de outros namespaces, ou modificar NetworkPolicies — essas operações são reservadas à equipe de plataforma.

Camada 2 — Rede: Uma NetworkPolicy default-deny-all é aplicada a cada namespace no momento da criação. Equipes precisam declarar explicitamente as políticas de ingress e egress que seus workloads necessitam. O tráfego entre namespaces é bloqueado por padrão; exceções são concedidas via política revisada pela equipe de plataforma. Isso elimina o risco de um tenant acessar inadvertidamente APIs internas de outro tenant. O DNS interno do cluster (kube-dns) permanece acessível para todos os namespaces, mas o acesso à API do Kubernetes a partir de pods é restrito via NetworkPolicy para o CIDR do control plane.

Camada 3 — Compute e quotas: ResourceQuota define limites de CPU, memória, número de pods, e contagem de objetos (Services, ConfigMaps, Secrets) por namespace. LimitRange define defaults de requests e limits para containers sem especificação explícita — isso é crítico para que o scheduler do Kubernetes e o Karpenter tomem decisões corretas de bin-packing. Workloads sem requests definidos são tratados como BestEffort e podem ser evicted primeiro sob pressão de memória. A equipe de plataforma define três tiers de quota (small, medium, large) e os tenants solicitam o tier adequado via PR.

Camada 4 — Identidade de workload: Nenhum pod deve carregar credenciais AWS estáticas. O modelo preferido é EKS Pod Identity, que associa um ServiceAccount Kubernetes a uma IAM Role via o agente eks-pod-identity-agent rodando como DaemonSet. A role é criada com escopo mínimo e revisada pelo time de segurança. IRSA permanece suportado para workloads legados, mas novos onboardings usam Pod Identity. Isso elimina a classe de vulnerabilidade onde credenciais são expostas em variáveis de ambiente ou ConfigMaps.

Karpenter substitui o Cluster Autoscaler com uma abordagem fundamentalmente diferente: em vez de escalar node groups pré-definidos, ele observa pods Unschedulable e provisiona o nó mais adequado diretamente via EC2 Fleet API, respeitando os constraints declarados no pod (nodeSelector, affinity, tolerations, topology spread). Isso permite bin-packing mais eficiente e latência de provisionamento significativamente menor.

Estrutura de NodePools: Defino três NodePools com responsabilidades distintas:

1. system — nós On-Demand dedicados para workloads de plataforma (Karpenter, CoreDNS, Kubecost, admission webhooks). Esses nós têm um taint CriticalAddonsOnly e são excluídos da consolidação agressiva. Uso instâncias m6i.large ou m6i.xlarge fixas para previsibilidade.

1. production — nós para workloads de produto com SLA. Estratégia: On-Demand como base, com capacidade Spot para até 30% dos nós quando disponível. O EC2NodeClass define uma lista diversificada de tipos de instância (m6i, m7i, c6i, c7i) para maximizar disponibilidade de Spot. karpenter.sh/capacity-type: [on-demand, spot] com spot-to-on-demand-ratio controlado via weight. PodDisruptionBudgets são obrigatórios para workloads neste pool — sem PDB, o Karpenter pode consolidar nós e derrubar todos os pods de um Deployment de uma vez.

1. batch — nós Spot-first para jobs de ML, ETL e CI. Aqui aceito interrupção com tolerância declarada (karpenter.sh/interruption-queue integrado ao SQS para receber notificações de interrupção EC2 e drenar nós graciosamente antes da terminação). A diversidade de tipos de instância é máxima neste pool — r6i, m6i, c6i, r7i, m7i em múltiplos tamanhos — para garantir que o Spot Placement Score seja alto.

Consolidação: Habilito consolidationPolicy: WhenUnderutilized para o pool de batch e WhenEmpty para produção. A diferença é importante: WhenUnderutilized permite ao Karpenter mover pods entre nós para liberar nós subutilizados (bin-packing ativo), enquanto WhenEmpty só remove nós completamente vazios. Para produção, a consolidação agressiva pode causar disruption excessiva; prefiro WhenEmpty com PDBs bem configurados.

Guardrails de custo: Sem restrições, um tenant pode criar um Job que solicita 1000 pods de 4 vCPU cada, e o Karpenter vai provisionar 250 nós c6i.xlarge em segundos. Para prevenir isso, ResourceQuota no namespace limita o total de CPU/memória requisitável. Adicionalmente, o NodePool define limits.cpu e limits.memory globais — o Karpenter não provisiona além desses limites, mesmo que haja pods pendentes. Isso cria um teto de custo por pool.