O blog da AWS

Gerencie e escale clusters Kubernetes com Karpenter e Rancher no Amazon EKS

Por Bruno Lopes, Sr. Specialist SA Containers na AWS; Michael Silva, Sr. Solutions Architect na AWS e Lucas Amaral, Sr. Partner SA na SUSE.

Gerenciar clusters Kubernetes em escala pode ser um desafio significativo para equipes de engenharia. À medida que as cargas de trabalho crescem e se tornam mais dinâmicas, surgem questões críticas: Como provisionar recursos de infraestrutura de forma eficiente e automática? Como manter governança e visibilidade centralizada em ambientes multi-cluster? Como garantir que a escalabilidade não comprometa a segurança e o controle operacional?

O Karpenter e Rancher no Amazon EKS resolvem esses desafios. O Karpenter fornece gerenciamento autônomo de infraestrutura, criando nodes sob demanda de forma inteligente, enquanto o Rancher oferece uma camada abrangente de gerenciamento e governança para ambientes multi-cluster. Com eles, sua organização simplifica operações complexas de Kubernetes, mantendo controle total sobre seus ambientes.

Este post mostra como integrar Karpenter e Rancher no Amazon EKS para criar uma solução de gerenciamento de clusters Kubernetes escalável, eficiente e fácil de governar.

Visão Geral da Solução

Karpenter: Provisionamento inteligente de infraestrutura

O Karpenter é um provisionador de nós open-source desenvolvido pela AWS que automatiza o provisionamento em tempo de execução (just-in-time) de capacidade computacional para Kubernetes. Ele observa pods não agendados e provisiona automaticamente nós EC2 otimizados em segundos, selecionando dinamicamente entre centenas de tipos de instâncias (incluindo Spot) para maximizar eficiência e reduzir custos.

Diferentemente do Cluster Autoscaler tradicional, que opera no nível de Auto Scaling Groups pré-configurados levando minutos para provisionar nós, o Karpenter provisiona diretamente via chamada de API para o EC2 Fleet, seleciona automaticamente entre centenas de tipos de instância em tempo real, e consolida proativamente cargas de trabalho para otimizar custos. A configuração é baseada em NodePools (políticas de provisionamento) e EC2NodeClass (configurações específicas da AWS).

Embora o Karpenter ofereça flexibilidade na seleção de instâncias, ambientes corporativos frequentemente exigem configurações padronizadas em todos os nós. É aqui que entram os NodeOverlays.

NodeOverlays: Personalização de Nós

Com NodeOverlays, você aplica configurações personalizadas aos nós provisionados pelo Karpenter, como modificação de user data, patches de sistema operacional, agentes de monitoramento e políticas de hardening. Essa funcionalidade pode ser um recurso muito estratégico para ambientes Enterprise, onde requisitos de compliance exigem configurações padronizadas, mantendo a flexibilidade do Karpenter na seleção de instâncias.

Com a infraestrutura configurada e personalizada, o próximo passo é entender como o Karpenter se integra com autoscalers de aplicação para criar uma solução de escalabilidade completa.

Integração com KEDA, HPA e VPA

O Karpenter trabalha harmoniosamente com autoscalers de aplicação (KEDA, HPA, VPA) porque operam em camadas diferentes: KEDA/HPA escalam réplicas de pods (camada de aplicação), enquanto Karpenter provisiona nós (camada de infraestrutura). Quando KEDA aumenta réplicas baseado em eventos (ex: fila SQS), os novos pods entram em estado ‘Pending’ se não houver capacidade. O Karpenter detecta esses pods e provisiona nós adequados em segundos. Quando KEDA reduz réplicas, o Karpenter consolida workloads e remove nós ociosos.

Onde o Rancher entra nessa história?

Se o Karpenter cuida da infraestrutura de forma autônoma (Nodes sob medida, no momento certo), o Rancher entra como a camada de gestão e governança, reunindo gerenciamento multicluster, autenticação/RBAC centralizados, observabilidade e GitOps em uma única ferramenta. Não é só mais um dashboard do Kubernetes e sim uma plataforma completa para operar clusters em escala, especialmente em cenários multicluster, multirregião e multiconta.

Para efeito de contraste, o Kubernetes Dashboard oficial é uma UI genérica para administrar um cluster (deploy, troubleshooting, escala de objetos). O Rancher vai além, orquestrando vários clusters e agregando identidade, políticas e entrega contínua.

Figura 1 – Console do Rancher, exibindo os Events do Cluster

Principais diferenciais

  • Gestão multicluster (provisionar, importar e operar): do mesmo console você cria clusters EKS novos, importa clusters EKS existentes e administra o ciclo de vida de todos eles, lado a lado. Isso reduz config drift e padroniza operações entre contas e regiões.
  • Autenticação e RBAC centralizados: o Rancher adiciona single sign-on e controle de acesso unificado sobre múltiplos clusters. Integra com Active Directory e Okta/SAML, mantendo grupos/papéis consistentes.
  • Catálogo e GitOps com Fleet: padronize implantações com Helm e adote GitOps em escala via Fleet (o mecanismo de Continuous Delivery do Rancher). Para EKS, é uma opção recomendada quando a necessidade é gerenciar múltiplos clusters de forma coerente.
  • Observabilidade integrada: habilite Rancher Monitoring (Prometheus/Grafana) por cluster para métricas, painéis e alertas, com integração ao Alertmanager. Além disso, use o SUSE Observability quando precisar de visão unificada entre clusters e aplicações (já incluso na subscrição do Rancher Prime) apontando o Prometheus do Rancher Monitoring para o endpoint do serviço. Assim você mantém seus dashboards e ganha correlação centralizada de métricas, logs e traces integrada ao Rancher.

Como o Rancher se conecta: entendendo os cattle-agents

A mágica do Rancher acontece por agentes instalados nos clusters gerenciados (namespace cattle-system). Ao importar ou criar um cluster pelo Rancher, ele implanta:

  • cattle-cluster-agent (Deployment): faz a ponte entre o servidor Rancher e o cluster. É o canal primário para o Rancher inspecionar estado e aplicar mudanças.
  • cattle-node-agent (DaemonSet): faz operações no nível do nó (ex.: upgrades de Kubernetes, snapshots de etcd em clusters RKE2) e atua como fallback se o cattle-cluster-agent estiver indisponível.

No modelo padrão, o controlador do Rancher se comunica com o cluster-agent e, se necessário, com o node agent. Isso permite gerenciar o cluster sem expor operações sensíveis diretamente, a comunicação é mediada pelos agentes.

Observação de nomenclatura: o prefixo “cattle-” é histórico e identifica componentes internos do Rancher; ver esses pods/Namespaces (cattle-system) é esperado após o registro do cluster.

Rancher community (OSS) vs. Rancher Prime

O Rancher é 100% open-source. Já o Rancher Prime (versão comercial) é construído sobre o mesmo código e adiciona suporte enterprise, ciclos de vida estendidos e integrações certificadas para ambientes regulados.

O que muda com o Prime:

  • Suporte do provedor: indicado para produção em escala, com SLAs.
  • Segurança com extensões oficiais: integração e UI extension do NeuVector diretamente no Rancher Manager para segurança de runtime, scan de vulnerabilidades e visibilidade de topologia de rede e policies, suportada para clientes Prime.
  • Aplicações curadas (Application Collection): catálogo de artefatos empacotados e testados pela SUSE, com processo de patching acelerado e foco em superfície mínima de ataque.
  • Ciclos de vida estendidos/LTS e arquiteturas validadas: útil para quem precisa de estabilidade e compliance de longo prazo.

A edição community é excelente para POCs e times que aceitam operar sem SLA externo. Já o Prime é a escolha natural quando há requisitos de suporte, segurança e compliance corporativos, combinando especialmente bem com EKS em ambientes enterprise.

Passo a Passo

Este passo a passo demonstra como integrar Karpenter e Rancher em um cluster Amazon EKS existente. Assumimos que você já possui um cluster EKS configurado e acesso administrativo.

Os passos principais são:

  • Instalação do Karpenter via Helm
  • Deploy do Rancher Manager via Helm
  • Configuração da integração entre ambas as ferramentas

Pré Requisitos

Para este passo a passo, você deve ter:

  • Um cluster Amazon EKS em funcionamento
  • kubectl configurado para acessar o cluster
  • Helm 3.x instalado
  • Permissões IAM adequadas para gerenciar recursos EKS, conforme mencionado no guia oficial do Karpenter logo abaixo.

Para setup inicial do cluster EKS, siga a documentação oficial do Amazon EKS.

Instalando Karpenter

Para instalação completa do Karpenter, incluindo pré-requisitos e configurações IAM, siga o guia oficial do Karpenter.

Abaixo, usamos algumas variáveis de ambiente, como por exemplo =${CLUSTER_NAME}. Lembre-se de defini-las antes de executar os comandos.

Os comandos essenciais para instalação via Helm:

# Instalar Karpenter
helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter \
  --version "1.8.0" \
  --namespace "karpenter" \
  --create-namespace \
  --set "settings.clusterName=${CLUSTER_NAME}" \
  --set "settings.interruptionQueue=${CLUSTER_NAME}" \
  --set "serviceAccount.annotations.eks\.amazonaws\.com/role-arn=arn:aws:iam::${AWS_ACCOUNT_ID}:role/KarpenterControllerRole-${CLUSTER_NAME}" \
  --set "controller.resources.requests.cpu=1" \
  --set "controller.resources.requests.memory=1Gi" \
  --set "controller.resources.limits.cpu=1" \
  --set "controller.resources.limits.memory=1Gi" \
  --wait

Após a instalação, configure um NodePool e uma EC2NodeClass via YAML, usando seu IDE, a fim de definir os tipos de instâncias que o Karpenter pode provisionar. Certifique-se de que a variável $CLUSTER_NAME está definida e que a IAM role segue o padrão ${CLUSTER_NAME}-karpenter-node. Ajuste o nome da role conforme sua convenção de nomenclatura.

cat <<EOF | envsubst | kubectl apply -f -
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    metadata:
      labels:
        type: karpenter
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: kubernetes.io/os
          operator: In
          values: ["linux"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2023
  amiSelectorTerms:
    - alias: al2023@latest
  role: "${CLUSTER_NAME}-karpenter-node"
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: "${CLUSTER_NAME}"
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: "${CLUSTER_NAME}"
EOF

Figura 2 – Console do Rancher exibindo Nodes gerenciados pelo Karpenter

Instalando Rancher Manager

Para configurações detalhadas e pré-requisitos do Rancher Manager, consulte a documentação oficial de instalação no EKS e também a documentação sobre o setup via Helm Chart.

Comandos para instalação via Helm:

# Instalar cert-manager (pré-requisito)
kubectl create namespace cert-manager
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --set installCRDs=true

# Instalar Rancher
kubectl create namespace cattle-system
helm install rancher rancher-latest/rancher \
  --namespace cattle-system \
  --set hostname=<rancher.alb.com> \
  --set bootstrapPassword=admin

Em hostname, lembre de alterar para o DNS name do seu Application Load Balancer na AWS, neste caso.

Configurando a Integração

Após ambas as instalações, registre o cluster no Rancher:

  1. Acesse a interface do Rancher via LoadBalancer ou Ingress configurado
  2. Navegue para Cluster Management > Import Existing
  3. Selecione Amazon EKS e selecione a Região e a Cloud Credential previamente configurada. Para ver mais sobre Cloud Credential, veja esta documentação.

O Rancher agora pode visualizar e gerenciar workloads que são automaticamente escalados pelo Karpenter.

Figura 3 – Operando o cluster Kubernetes do Amazon EKS pela interface do Rancher

Vantagens da Solução Combinada

A integração entre Karpenter e Rancher oferece benefícios únicos que vão além das capacidades individuais de cada ferramenta:

Visibilidade Operacional Aprimorada

O Rancher fornece uma interface unificada para monitorar recursos provisionados dinamicamente pelo Karpenter. Enquanto o Karpenter otimiza automaticamente a infraestrutura, o Rancher oferece visibilidade em tempo real sobre:

  • Utilização de recursos por namespace e projeto
  • Métricas de performance dos nodes provisionados automaticamente
  • Logs centralizados de aplicações em nodes efêmeros

Figura 4 – Visibilidade centralizada do Rancher com o Amazon EKS

Governança e Controle de Custos

Com essa combinação, você implementa políticas de governança robustas:

  • Resource Quotas: O Rancher pode definir limites por projeto, enquanto o Karpenter otimiza dentro desses limites
  • Cost Allocation: Visibilidade granular de custos por equipe/projeto, mesmo com infraestrutura dinâmica
  • Policy Enforcement: Aplicação de políticas de segurança e compliance em nodes provisionados automaticamente

Experiência Simplificada para Desenvolvedores

Desenvolvedores obtêm o melhor dos dois mundos:

  • Self-Service: Deploy de aplicações via Rancher sem se preocupar com provisionamento de infraestrutura
  • Escalabilidade Transparente: O Karpenter escala automaticamente conforme demanda, sem intervenção manual
  • Multi-Cluster Management: Gerenciamento consistente de múltiplos clusters EKS com diferentes configurações de Karpenter

Otimização Inteligente de Recursos

A integração permite otimizações avançadas:

  • Workload-Aware Scaling: O Rancher identifica padrões de uso que informam as decisões de scaling do Karpenter
  • Mixed Instance Types: Aproveitamento otimizado de Spot e On-Demand instances baseado na criticidade dos workloads
  • Bin Packing Eficiente: Melhor utilização de recursos através da visibilidade combinada de ambas as ferramentas

Boas práticas e design patterns com EKS, Karpenter e Rancher

Quando juntamos EKS, Karpenter e Rancher, alguns padrões aparecem em praticamente todo ambiente que roda bem em produção. A ideia aqui é amarrar o walkthrough com decisões de arquitetura concretas que o time de plataforma consegue copiar ou adaptar.

Desenho de NodePools ou Node Groups

Um desenho que funciona bem é separar claramente nós de plataforma de nós de aplicação. Um NodePool (ou Managed Node Group) system fica com instâncias on-demand, sem scale-to-zero, para rodar os cattle-agents do Rancher, o próprio Karpenter, add-ons de cluster, CoreDNS, ingress controller e tudo que não pode sumir durante uma consolidação agressiva. Os demais NodePools ficam sob gestão do Karpenter: por exemplo, um workload-spot com capacity type SPOT e consolidação habilitada para workloads tolerantes a preemption, e um workload-ondemand para serviços críticos ou stateful. As aplicações selecionam o NodePool por labels/taints, e você controla o trade-off custo x resiliência por meio da definição de NodePools.

Amarração entre NodePools e projects/namespaces no Rancher

O Rancher fica ainda mais interessante quando você traduz essas decisões de capacity em isolamento lógico. Uma prática simples é usar Projects para agrupar Namespaces por domínio de negócio e amarrar cada Project a um subconjunto de NodePools. Exemplo: o Project payments usa Namespaces payments-dev e payments-prod e só agenda workloads em NodePools payments-spot e payments-ondemand. Já o Project analytics aponta para NodePools com instâncias otimizadas para memória ou GPU. Isso ajuda a controlar consumo de capacidade por área, simplifica showback/chargeback e reduz o atrito entre times na hora de ajustar Karpenter.

GitOps, kubectl e UI do Rancher no mesmo fluxo

Do ponto de vista operacional, o ideal é ter o Git como fonte da verdade. Sempre que você precisa mudar algo estrutural, como Deployments, Services, NodePools ou políticas, a alteração origina-se no Git, passa por revisão e é aplicada por um pipeline de GitOps. O Rancher identifica esse estado desejado chegando no cluster e mostra se o estado atual está em conformidade ou não. O kubectl é reservado para situações pontuais, como laboratório ou resposta a incidente, quando você precisa testar rapidamente um ajuste. Após a estabilização, o que foi feito com kubectl é revisado e incorporado aos manifests no Git, para não criar drift. A interface do Rancher atua como painel de operação: é ali que você visualiza pods em estado Pending que acionarão o Karpenter, identifica em quais NodePools as aplicações estão sendo provisionadas e acompanha mensagens de erro de provisionamento.

Observabilidade e tuning do Karpenter com SUSE Observability

Como o Karpenter reage a sinais do próprio Kubernetes (pods Pending, requests/limits, afinidade), ter observabilidade adequada é o que separa um cluster estável de um ambiente que enfrenta problemas constantes. O Rancher Monitoring já cobre o básico, mas em ambientes maiores vale considerar o SUSE Observability, que é o add-on de observabilidade integrado à subscrição do Rancher Prime. Ele coleta topologia, eventos, logs, mudanças e métricas dos clusters Kubernetes, incluindo EKS, por meio de StackPacks específicos e agentes instalados via Helm. Na prática, isso significa ter, em uma única interface, dashboards prontos por cluster, NodePool e workload, além de timelines de mudanças e correlação com alertas. O time usa esses dados para calibrar requests/limits, políticas de consolidação, TTL de nós e o mix Spot x On-demand do Karpenter com base em comportamento real.

Segurança e escopo de acessos

Por fim, a combinação EKS + Rancher facilita separar bem funções, permissões e visibilidade nos recursos Kubernetes. A integração típica é com um IdP corporativo como AWS IAM Identity Center, Okta, Ping Identity, Keycloak ou outro provedor de SSO que sua organização já utiliza. Os grupos do IdP são mapeados para roles de Cluster e Project no Rancher, então, por exemplo, o time de plataforma fica com acesso administrativo, enquanto times de produto recebem permissões mais restritas, limitadas aos seus Namespaces e operações do dia a dia. O Rancher ainda centraliza auditoria: você tem visibilidade de quem alterou as quotas, NodePools ou políticas e evita que um ajuste “local” de Karpenter feito por um time de aplicação tenha impacto global no cluster.

Cleaning up

Para remover os recursos criados:

# Remover Rancher
helm uninstall rancher --namespace cattle-system
helm uninstall cert-manager --namespace cert-manager

# Remover Karpenter
kubectl delete nodepool default
kubectl delete ec2nodeclass default
helm uninstall karpenter --namespace karpenter
kubectl delete namespace karpenter

Conclusão

Neste post, você aprendeu como o Karpenter e o Rancher trabalham juntos no Amazon EKS para resolver desafios de gerenciamento e escalabilidade de clusters Kubernetes em produção.

O Karpenter automatiza o provisionamento de infraestrutura, criando nodes EC2 otimizados em segundos com base na demanda real de workloads. Ele seleciona dinamicamente entre centenas de tipos de instância, combina Spot e On-Demand para reduzir custos, e consolida proativamente nodes ociosos.

O Rancher complementa essa automação com uma camada de gerenciamento multi-cluster que oferece visibilidade centralizada, governança com RBAC integrado entre outros. Os cattle-agents mantêm a comunicação segura entre o Rancher Manager e os clusters gerenciados.

Você viu na prática como instalar ambas as ferramentas, configurar NodePools com requisitos específicos, e integrar os componentes para criar uma solução completa. As boas práticas apresentadas — como separar nodes de plataforma, usar GitOps como fonte da verdade, e implementar observabilidade com SUSE Observability — preparam seu ambiente para escalar com segurança.

Próximos Passos

Para aprofundar sua implementação:

1. Otimize custos com Spot: Configure NodePools dedicados com capacity-type: ["spot"] para workloads tolerantes a interrupção

2. Implemente GitOps: Use EKS Capabilities ou o Rancher Fleet para padronizar deployments entre múltiplos clusters EKS

3. Configure observabilidade: Instale SUSE Observability para correlacionar métricas, logs e traces em uma única interface

4. Integre segurança: Adicione NeuVector (incluído no Rancher Prime) para scanning de vulnerabilidades e network policies

Recursos Adicionais

– Documentação oficial do Karpenter

– Guia de instalação do Rancher no EKS

– Best Practices para Amazon EKS

– Karpenter Best Practices Guide

– SUSE Rancher Prime Documentation

Autores

Bruno Lopes é Sr. Specialist Solutions Architect na AWS LATAM, com mais de 17 anos de experiência em TI. Especialista em Containers e Kubernetes na AWS, ele atua com clientes em toda a América Latina, acelerando a modernização de aplicações e a adoção de ambientes híbridos. Ao longo da carreira, também atuou como Consultor, Technical Trainer e Evangelista, ajudando equipes a superarem desafios técnicos com soluções inovadoras e práticas.
Michael Silva é Sr. Solutions Architect na AWS com foco em Fundações e Containers, incluindo expertise na integração do Amazon EKS com ferramentas open source como Crossplane, Terraform e GitOps. Em seu papel, Michael se dedica a ajudar os clientes a alcançar seus objetivos de negócios implementando as melhores práticas em design e gestão de infraestrutura em nuvem.

Lucas Amaral é Partner Solutions Architect na SUSE para a América Latina, com foco em plataformas Linux, Kubernetes e IA aplicada à infraestrutura. Trabalha apoiando parceiros e clientes em projetos de modernização de infraestrutura Linux, Kubernetes e edge, com foco em arquitetura, automação e competitivos em ambientes on-premises e de nuvem pública.