A recente disponibilidade geral (GA) do Karpenter Provider para o OCI (Oracle Cloud Infrastructure) marca um ponto de inflexão para equipes de SRE e engenharia que rodam workloads rodando no OKE (Oracle Kubernetes Engine). Diferente do tradicional Cluster Autoscaler, que impõe limites rígidos via node pools estáticos, o Karpenter atua de forma preditiva e dinâmica, ajustando a infraestrutura quase em tempo real conforme a demanda dos pods.
O gargalo dos modelos tradicionais
O modelo de autoscaling convencional no Kubernetes — ancorado no Cluster Autoscaler — baseia-se em node pools pré-configurados. Na prática, isso cria uma gestão burocrática e ineficiente: se você precisa de diferentes compute shapes para microserviços variados com requisitos distintos de CPU e memória, você acaba forçado a gerenciar dezenas de pools. O resultado é o fenômeno da "fragmentação de capacidade": você mantém instâncias ociosas em vários pools para garantir que o escalonamento não trave, gerando um custo desnecessário e aumentando a carga operacional sobre o time de plataforma.
A transição para o modelo de 'Just-in-Time Provisioning'
Com a introdução do Karpenter no ecossistema OKE, a lógica se inverte. Em vez de escalar uma estrutura pronta, o Karpenter analisa os pods pendentes (pending pods) e provisiona exatamente o compute shape necessário para atender àquela carga de trabalho, respeitando as políticas definidas no NodePool e no OciNodeClass.
Essa abordagem não apenas elimina o "overhead" de criar múltiplos pools manualmente, mas permite uma elasticidade muito maior. Por exemplo, se um shape específico estiver com falta de disponibilidade momentânea na OCI, o Karpenter é capaz de saltar para a próxima melhor opção disponível, garantindo a continuidade do serviço sem intervenção humana.
Por que isso é estratégico para empresas brasileiras?
Para tomadores de decisão em TI no Brasil, essa funcionalidade traz três benefícios diretos:
- Eficiência no consumo (FinOps): Ao consolidar cargas de trabalho de forma mais inteligente, você reduz o desperdício de recursos infraestruturais.
- Resiliência operacional: O provisionamento automático reduz a dependência de processos de infraestrutura como serviço (IaaS) manuais, diminuindo o risco de erro humano em momentos de pico.
- Flexibilidade arquitetural: É muito mais simples adaptar sua infraestrutura a novas demandas de negócio, utilizando diferentes arquiteturas e modelos de compra (como preemptible capacity) por meio da mesma política centralizada.
Como o Karpenter interage nativamente com recursos como OCI Flexible Compute Shapes, Cluster Placement Groups e a rede VCN, a integração é fluida. No entanto, o cuidado deve ser na migração: a recomendação é iniciar migrando workloads não críticos via labels e taints, mantendo o Cluster Autoscaler como um "cinto de segurança" para sistemas core até que a confiança no novo modelo esteja consolidada.
Considerações de implementação
Para equipes que já operam o OKE, a jornada técnica envolve entender a separação de conceitos:
- NodePool (O "O quê"): Define as restrições da nuvem (instâncias, zonas, tipos de compra).
- OciNodeClass (O "Como"): Define a camada de infraestrutura (subnets, IAM, security groups, imagens).
Essa segregação permite que desenvolvedores foquem no deploy via standard Kubernetes specs, enquanto o time de plataforma garante a governança através destas classes de configuração robustas. É um claro movimento de shift-left na infraestrutura, tirando o peso da operação de nó da rotina diária.
Para quem pretende adotar, o ponto de partida é o repositório oficial no GitHub. A mudança de paradigma compensa o tempo de aprendizado pela redução drástica na complexidade da gestão técnica a médio prazo.
*Artigo originalmente publicado por Kay Singh em cloud-infrastructure.
