Reduza custos e escale com inteligência no ROSA: Karpenter automatiza o provisionamento de computação

Ao implantar aplicações no Red Hat OpenShift Service on AWS (ROSA), os desenvolvedores obtêm benefícios operacionais através da conteinerização, auto-scaling de nós e computação elástica, mas ainda podem enfrentar casos de subutilização de recursos. Para melhorar a utilização de computação e reduzir custos para o ROSA, a Red Hat está oferecendo o Red Hat build of Karpenter, que é um autoscaler totalmente gerenciado baseado no Project Karpenter upstream.

O Karpenter provisiona instâncias do Amazon Elastic Compute Cloud (Amazon EC2) com dimensionamento adequado just-in-time com base nos requisitos exatos de computação das cargas de trabalho implantadas, em vez de tipos de instância definidos estaticamente. Essa abordagem reduz significativamente os custos de computação através da alocação eficiente de recursos e avaliação contínua dos requisitos de computação, levando a um scale up econômico, bin-packing eficiente e scale-down.

Este post explica como o Karpenter resolve os desafios de gerenciamento de capacidade de computação, em seguida, aprofunda-se em como o Red Hat build of Karpenter (atualmente em Technology Preview) traz essas capacidades para o ROSA com hosted control planes (HCP), e como você pode usá-lo com seus clusters.

O Problema de Escalabilidade de Nós

Os administradores de cluster há muito tempo dependem do Kubernetes Cluster Autoscaler, bem como de machine pools configurados manualmente para gerenciar a capacidade de computação. Embora funcional, essa abordagem tem limitações:

• • Grupos de nós rígidos com tipos e tamanhos de instância fixos significam que você está preso a um único tipo de instância, como m6i.8xlarge, por grupo de nós, mesmo quando suas cargas de trabalho têm requisitos diversos (intensivo em CPU, pesado em memória, GPU, baseado em Arm).

• • Escalabilidade reativa resulta no Cluster Autoscaler adicionando mais nós do mesmo tipo de instância quando os pods não podem ser escalonados. Ele não avalia proativamente se um tipo de instância diferente (família ou tamanho) seria mais adequado.

• • Provisionamento excessivo é frequentemente empregado para garantir que as cargas de trabalho tenham recursos provisionados para expandir, resultando em machine pools superdimensionados e gastos desperdiçados.

• • Ineficiência de bin-packing surge quando os recursos ficam presos em nós parcialmente utilizados que não podem ser consolidados.

• • Esforço operacional repetitivo é resultado do processo manual e propenso a erros de gerenciar múltiplos machine pools com diferentes tipos de instância, tamanhos, opções de mercado e políticas de escalabilidade.

• • Restrições de recursos ocorrem se um tipo de instância específico não estiver disponível em um determinado momento, ou se uma cota de computação for excedida.

Para organizações operando em escala em múltiplos ambientes e equipes, essas ineficiências se acumulam rapidamente.

A Solução: Karpenter

O Karpenter, criado pela Amazon Web Services (AWS) e disponibilizado como código aberto em 2021, é um autoscaler de nós de alto desempenho e nativo do Kubernetes, projetado para superar as limitações do Kubernetes Cluster Autoscaler tradicional.

Ao contrário dos autoscalers tradicionais que operam em grupos de nós, o Karpenter trabalha no nível de pod individual. Quando os pods não podem ser escalonados, o Karpenter avalia as solicitações de recursos e restrições (por exemplo, CPU, memória, GPU, topologia) e provisiona a instância ideal do Amazon EC2 para satisfazê-los. Ele faz isso chamando a API EC2 CreateFleet diretamente, selecionando entre mais de 400 tipos de instância em múltiplas arquiteturas (x86, Arm/Graviton), tipos de capacidade (On-Demand, Spot) e AWS Availability Zones.

O resultado é computação dimensionada adequadamente e que não requer intervenção manual.

Economia de Custos com o Karpenter

• • Escalabilidade Vertical: Os tipos e tamanhos de instância são continuamente dimensionados adequadamente para evitar o provisionamento excessivo de capacidade de computação ao longo do dia.

• • Escalabilidade Horizontal: O número de worker nodes escala para cima e para baixo com base na demanda da carga de trabalho, aumentando a capacidade e disponibilidade conforme as aplicações precisam.

• • Otimização de Mercado: As condições de mercado são monitoradas para determinar quando as cargas de trabalho devem utilizar instâncias On-Demand e Spot, otimizando o custo sem sacrificar a disponibilidade. Quando você tem capacidade reservada, ele prioriza de forma inteligente a reserva de capacidade quando disponível e volta para on-demand quando a capacidade reservada está toda utilizada.

• • Economia Operacional: Ao automatizar o dimensionamento, monitoramento e ajuste de múltiplos pools de nós, as equipes de plataforma ficam livres para se concentrar em outras áreas.

Como o Karpenter Funciona

A arquitetura do Karpenter segue um fluxo direto:

1. 1. Pods pendentes acionam o provisionamento: Quando os pods não podem ser escalonados devido à capacidade insuficiente, o Karpenter os detecta.

1. 1. Avaliação da carga de trabalho: O Karpenter avalia as solicitações de recursos (CPU, memória, GPU) e restrições de escalonamento (topologia, afinidade, taints).

1. 1. Simulação de escalonamento: O Karpenter simula o escalonador do Kubernetes em tipos de instância candidatos para encontrar o melhor ajuste, não apenas o mais barato.

1. 1. Seleção de instância ideal: O Karpenter usa a API EC2 CreateFleet para provisionar a instância mais econômica que atende a todas as restrições.

1. 1. Nó ingressa no cluster, pods são escalonados: O nó recém-provisionado se junta ao cluster para que os pods pendentes sejam escalonados imediatamente.

Além do provisionamento, o Karpenter executa continuamente um loop de consolidação que avalia os nós existentes quanto à subutilização para que possam ser substituídos por instâncias mais adequadas. Seu cluster nunca para de otimizar, mesmo após o provisionamento inicial.

Benefícios do Red Hat build of Karpenter

Controladores Hospedados no Control Plane

Os controladores do Karpenter são hospedados e gerenciados como parte do hosted control plane, não em seus worker nodes. Não há pods extras para gerenciar, nenhuma sobrecarga de computação adicional e nenhuma contenção de recursos entre o Karpenter e suas aplicações.

Habilitar em Clusters Existentes

O Karpenter pode ser habilitado em clusters ROSA HCP existentes assim que forem atualizados para a versão do OpenShift que o suporta. Não é necessário recriar seu cluster para aproveitar o Karpenter.

Atualizações Independentes

Você tem flexibilidade total sobre o agendamento de atualizações. O hosted control plane, machine pools e nós do Karpenter podem ser atualizados para uma versão do OpenShift independentemente uns dos outros, com base em seus requisitos.

Coexistência com o Cluster Autoscaler

Você pode usar o Cluster Autoscaler, Karpenter e escalabilidade manual no mesmo cluster. É recomendado adotar técnicas de posicionamento de pods (taints/tolerations, labels/nodeSelectors) para direcionar cargas de trabalho de acordo com sua estratégia de gerenciamento de nós. Isso permite um caminho de migração gradual de NodePools autogerenciados para gerenciados pelo Karpenter no seu ritmo.

Reservas de Capacidade e CapacityBlocks para ML

Você pode usar a capacidade reservada (tanto On-Demand Capacity Reservations (ODCRs) quanto Amazon EC2 Capacity Blocks for ML) com o Karpenter. Isso é crítico para equipes executando treinamento de machine learning ou aplicações com requisitos regulatórios que exigem capacidade de computação reservada.

Configurando o Kubelet e Ajustando Nós

Para casos de uso avançados, aproveite as configurações do kubelet e perfis TuneD para atender às necessidades de cargas de trabalho diversas.

Otimização de Custos e Sustentabilidade

O Karpenter faz mais do que apenas simplificar operações, ele também gera resultados significativos de custo e sustentabilidade. O Karpenter avalia mais de 400 tipos de instância EC2 e provisiona dinamicamente cada nó com base nos requisitos da carga de trabalho, eliminando capacidade provisionada em excesso. Ele aproveita automaticamente instâncias Spot e instâncias reservadas disponíveis (On-demand Capacity Reservations) com fallback para On-Demand, o que otimiza o custo mantendo a disponibilidade. Nós subutilizados são continuamente consolidados e substituídos, garantindo que seu cluster funcione eficientemente 24 horas por dia. Além disso, instâncias baseadas em Arm AWS Graviton oferecem melhor relação preço-desempenho e menor consumo de energia por unidade, alinhando-se com o Pilar de Sustentabilidade da AWS do Well-Architected Framework.

Segurança e Conformidade Empresarial

O Karpenter se integra perfeitamente com sua postura de segurança existente. A Red Hat fornece a base de conformidade, incluindo FIPS, SOC2 e FedRAMP, enquanto o Karpenter respeita todas as restrições de escalonamento do Kubernetes, taints e tolerations. As configurações de subnet e security group do Amazon VPC são gerenciadas através do EC2NodeClass, garantindo que os nós sejam iniciados apenas em segmentos de rede aprovados. A seleção de AMI gerenciada pelo OpenShift garante que apenas imagens de SO aprovadas sejam usadas para worker nodes. Por fim, a integração com AWS Identity and Access Management (AWS IAM) e AWS Security Token Service (AWS STS) fornece acesso de menor privilégio para os controladores do Karpenter.

Conclusão

O Karpenter oferece economia significativa de custos de infraestrutura através do dimensionamento adequado, otimização de spot e consolidação contínua, eliminando a sobrecarga operacional da escalabilidade manual de nós. O Red Hat build of Karpenter estará em disponibilidade geral (GA) no próximo lançamento menor do Red Hat OpenShift em todas as Regiões da AWS onde o ROSA está geralmente disponível.

Para saber mais:

• • Leia este post sobre otimização de custos com o ROSA.

• • Entre em contato com seu representante da Red Hat ou Red Hat Support.

• • Visite a página web do ROSA.

Este conteúdo foi traduzido do post original do blog por Steve Mirman, Partner Solutions Architect na AWS e Bala Chandrasekaran, Product Manager no Managed OpenShift Cloud Services, que pode ser encontrado aqui.

Tradutores

Guilherme Baufaker Rêgo é Arquiteto de Soluções Sênior na AWS, atendendo o setor público brasileiro, com especialização em Inteligência Artificial, Machine Learning e arquitetura de soluções em nuvem. Guilherme ajuda organizações a acelerar suas jornadas de transformação digital e IA generativa, de provas de conceito a implementações em produção em escala empresarial, com experiência em arquiteturas serverless e event-driven, agentes autônomos com Amazon Bedrock e AgentCore, e pipelines de ML/MLOps. Antes da AWS, passou 6 anos na Red Hat, na Engenharia de Produtos, contribuindo diretamente para projetos de código aberto como Istio, Kiali e OpenShift, o que lhe deu profunda especialização em service mesh, observabilidade, ambientes cloud-native sobre Kubernetes e Red Hat OpenShift Service on AWS (ROSA). Mestre em UX e Inteligência Artificial pela USP, é também 9x AWS Certified, certificado Red Hat e PMP.

Pedro Henrique Oliveira é Arquiteto de Soluções atendendo o segmento de empresas de Software na AWS, ajudando clientes em suas jornadas de containers e Open Source. Pedro tem experiência trabalhando com sistemas distribuídos, modernização, aplicações nativas em nuvem, GitOps e engenharia de plataforma. Ele também contribui para projetos de código aberto, como o “Twelve Factors”, e participa de palestras sobre projetos CNCF em eventos de comunidade.