Karpenter na AWS: o guia completo de autoscaling de nós no EKS

Karpenter vs. Kubernetes Cluster Autoscaler na AWS

O Karpenter e o Kubernetes Cluster Autoscaler adicionam capacidade de computação quando os pods não podem ser agendados, mas usam modelos de escalonamento diferentes.

O Cluster Autoscaler trabalha com grupos de nós existentes, como grupos de nós gerenciados do Amazon EKS ou grupos de Auto Scaling. Ele aumenta ou diminui o tamanho desses grupos com base em pods pendentes e nós ociosos. Funciona bem quando os workloads cabem em um número pequeno de tipos de nó conhecidos. É previsível e amplamente usado, mas costuma exigir planejamento cuidadoso. As equipes precisam definir grupos de nós, configurar tamanhos mínimos e máximos e decidir quais tipos de instância cada grupo deve usar.

O Karpenter não exige grupos de nós predefinidos. Em vez disso, ele provisiona instâncias EC2 com base nos requisitos dos pods pendentes. Isso permite escolher entre uma variedade maior de tipos de instância e opções de capacidade no momento do provisionamento. O Karpenter é indicado para ambientes em que os requisitos dos workloads mudam com frequência. Ele pode selecionar nós com base em CPU, memória, arquitetura, zona de disponibilidade e tipo de capacidade.

O principal trade-off é controle versus flexibilidade:

• O Cluster Autoscaler usa um modelo baseado em grupos de nós fixos.
• O Karpenter oferece provisionamento mais dinâmico, mas exige que as equipes gerenciem recursos específicos do Karpenter, como NodePool e EC2NodeClass.

Conteúdo relacionado: para uma comparação lado a lado mais aprofundada, leia nosso guia Karpenter vs. Cluster Autoscaler.

Tutorial: primeiros passos com o Karpenter na AWS

Este tutorial mostra como criar um cluster Amazon EKS, instalar o Karpenter, definir um NodePool padrão e testar o provisionamento automático de nós. O fluxo usa eksctl, kubectl, helm e a AWS CLI.

Passo 1: Antes de começar, instale as ferramentas necessárias:

aws --version
kubectl version --client
eksctl version
helm version

O Karpenter precisa de permissões da AWS para poder provisionar e encerrar instâncias EC2. Nesta configuração, essas permissões são vinculadas à service account do Karpenter via pod identity.

Passo 2: Comece definindo as principais variáveis de ambiente:

export KARPENTER_NAMESPACE="kube-system"
export KARPENTER_VERSION="1.14.0"
export K8S_VERSION="1.36"
export AWS_PARTITION="aws"
export CLUSTER_NAME="${USER}-karpenter-demo"
export AWS_DEFAULT_REGION="us-west-2"
export AWS_ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)"
export TEMPOUT="$(mktemp)"

Essas variáveis são reutilizadas pelos comandos seguintes. CLUSTER_NAME identifica o cluster EKS, enquanto AWS_ACCOUNT_ID é usado na criação de roles e políticas do IAM.

Passo 3: Em seguida, obtenha os IDs das AMIs Amazon Linux 2 recomendadas para a versão do Kubernetes:

export ARM_AMI_ID="$(aws ssm get-parameter \
  --name /aws/service/eks/optimized-ami/${K8S_VERSION}/amazon-linux-2-arm64/recommended/image_id \
  --query Parameter.Value --output text)"

export AMD_AMI_ID="$(aws ssm get-parameter \
  --name /aws/service/eks/optimized-ami/${K8S_VERSION}/amazon-linux-2/recommended/image_id \
  --query Parameter.Value --output text)"

O Karpenter usa essas AMIs ao criar nós EC2. Mantê-las em variáveis facilita a reutilização na definição do EC2NodeClass mais adiante.

Passo 4: Crie a infraestrutura de suporte na AWS e o cluster EKS:

curl -fsSL https://raw.githubusercontent.com/aws/karpenter-provider-aws/v"${KARPENTER_VERSION}"/website/content/en/preview/getting-started/getting-started-with-karpenter/cloudformation.yaml > "${TEMPOUT}"

aws cloudformation deploy \
  --stack-name "Karpenter-${CLUSTER_NAME}" \
  --template-file "${TEMPOUT}" \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameter-overrides "ClusterName=${CLUSTER_NAME}"

Essa stack do CloudFormation cria os recursos da AWS de que o Karpenter precisa, incluindo as permissões do IAM para provisionar nós.

Passo 5: Agora crie o cluster EKS:

eksctl create cluster -f - <<EOF
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: ${CLUSTER_NAME}
  region: ${AWS_DEFAULT_REGION}
  version: "${K8S_VERSION}"
  tags:
    karpenter.sh/discovery: ${CLUSTER_NAME}

iam:
  withOIDC: true
  podIdentityAssociations:
  - namespace: "${KARPENTER_NAMESPACE}"
    serviceAccountName: karpenter
    roleName: ${CLUSTER_NAME}-karpenter
    permissionPolicyARNs:
    - arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:policy/KarpenterControllerPolicy-${CLUSTER_NAME}

iamIdentityMappings:
- arn: "arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:role/KarpenterNodeRole-${CLUSTER_NAME}"
  username: system:node:{{EC2PrivateDNSName}}
  groups:
  - system:bootstrappers
  - system:nodes

managedNodeGroups:
- instanceType: m5.large
  amiFamily: AmazonLinux2023
  name: ${CLUSTER_NAME}-ng
  desiredCapacity: 2
  minSize: 1
  maxSize: 10

addons:
- name: eks-pod-identity-agent
EOF

Isso cria um pequeno grupo de nós gerenciado para executar os componentes do sistema e o próprio Karpenter. O cluster recebe a tag karpenter.sh/discovery, que o Karpenter usa depois para descobrir sub-redes e grupos de segurança.

Passo 6: Instale o Karpenter com o Helm:

helm registry logout public.ecr.aws

helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter \
  --version "${KARPENTER_VERSION}" \
  --namespace "${KARPENTER_NAMESPACE}" \
  --create-namespace \
  --set "settings.clusterName=${CLUSTER_NAME}" \
  --set "settings.interruptionQueue=${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

Isso implanta o controlador do Karpenter no cluster. O controlador monitora pods que o Kubernetes não consegue agendar e então chama as APIs da AWS para criar instâncias EC2 adequadas.

Passo 7: Em seguida, crie um NodePool e um EC2NodeClass padrão:

cat <<EOF | envsubst | kubectl apply -f -
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    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: ["on-demand"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      expireAfter: 720h
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 1m
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2023
  role: "KarpenterNodeRole-${CLUSTER_NAME}"
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: "${CLUSTER_NAME}"
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: "${CLUSTER_NAME}"
  amiSelectorTerms:
    - id: "${AMD_AMI_ID}"
EOF

O NodePool define quais nós o Karpenter pode criar. Neste exemplo, ele permite instâncias Linux amd64 sob demanda das famílias otimizadas para computação, de uso geral e otimizadas para memória.

O EC2NodeClass contém as configurações específicas da AWS. Ele informa ao Karpenter qual role do IAM, sub-redes, grupos de segurança e AMIs usar ao provisionar os nós.

Passo 8: Para testar o escalonamento, crie um deployment com zero réplicas:

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 0
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      terminationGracePeriodSeconds: 0
      containers:
      - name: inflate
        image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
        resources:
          requests:
            cpu: 1
EOF

Esse deployment usa a imagem leve pause. Cada réplica solicita uma CPU, o que o torna útil para testar o provisionamento de nós.

Passo 9: Escale o deployment para gerar pods não agendáveis:

kubectl scale deployment inflate --replicas 5

O Karpenter deve detectar os pods pendentes e criar novos nós EC2. Você pode acompanhar os logs do controlador com:

kubectl logs -f -n "${KARPENTER_NAMESPACE}" \
  -l app.kubernetes.io/name=karpenter \
  -c controller

Após o teste, exclua o deployment:

kubectl delete deployment inflate

Como o NodePool usa WhenEmptyOrUnderutilized, o Karpenter pode remover nós vazios ou subutilizados após a consolidação. Isso ajuda a reduzir custos quando os workloads não precisam mais da capacidade extra.

Passo 10: Para limpar o ambiente de demonstração, remova o Karpenter e exclua o cluster:

helm uninstall karpenter --namespace "${KARPENTER_NAMESPACE}"

aws cloudformation delete-stack \
  --stack-name "Karpenter-${CLUSTER_NAME}"

eksctl delete cluster --name "${CLUSTER_NAME}"

Isso remove os principais recursos criados durante o tutorial e ajuda a evitar cobranças adicionais da AWS.

Boas práticas para o Karpenter na AWS

Confira algumas práticas úteis ao usar o Karpenter na AWS.

1. Fixe AMIs em produção

Em ambientes de produção, evite depender de AMIs selecionadas automaticamente. Em vez disso, fixe IDs de AMI específicos nas definições do EC2NodeClass. Isso dá às equipes controle sobre a imagem do sistema operacional usada nos worker nodes e reduz o risco de mudanças inesperadas causadas por novas versões de AMI. AMIs fixadas também melhoram a consistência entre ambientes e simplificam a resolução de problemas.

Ações recomendadas:

• As equipes podem validar patches de segurança, runtimes de contêiner e compatibilidade com o Kubernetes antes de aplicar atualizações.
• Teste novas AMIs em ambientes de não produção antes de atualizar os NodePools de produção.
• Mantenha um processo documentado de atualização de AMIs que inclua revisões de segurança, procedimentos de rollback e rastreamento de versões.

2. Use controles de interrupção

O Karpenter inclui recursos de interrupção e consolidação que ajudam a reduzir custos ao substituir ou remover nós subutilizados. Embora esses recursos melhorem a eficiência, uma consolidação agressiva pode afetar a disponibilidade dos workloads se os nós forem encerrados rápido demais. Os controles de interrupção permitem equilibrar a otimização de custos com a estabilidade das aplicações, controlando como e quando as substituições de nós ocorrem.

Ações recomendadas:

• Use políticas de consolidação junto com pod disruption budgets, topology spread constraints e prioridades de workload.
• Para serviços críticos, considere aumentar os atrasos de consolidação ou limitar as substituições de nós durante o horário comercial.
• Em clusters de produção, configure as opções de interrupção e consolidação com cuidado para evitar interrupções desnecessárias nos workloads.

3. Separe tipos de workload com NodePools

Workloads diferentes costumam ter requisitos de infraestrutura diferentes. Por exemplo, workloads em lote sem estado podem rodar em NodePools baseados em Spot, enquanto aplicações voltadas ao cliente podem usar capacidade sob demanda. Workloads de GPU, baseados em ARM e aplicações com alto consumo de memória também podem usar NodePools dedicados com restrições de instância específicas.

Ações recomendadas:

• Separe os workloads em NodePools dedicados com base em sensibilidade a custos, requisitos de desempenho, arquitetura ou tolerância a interrupções.
• Use taints, tolerations, node selectors e regras de afinidade para garantir que os workloads sejam agendados nos NodePools adequados.
• Aplique políticas distintas de interrupção, consolidação e tipo de capacidade a cada NodePool conforme as características dos workloads.

4. Monitore o comportamento do Karpenter

Monitore o Karpenter como qualquer outro componente do cluster. A visibilidade das decisões de provisionamento, dos eventos do ciclo de vida dos nós e dos resultados de agendamento ajuda as equipes a identificar ineficiências, diagnosticar problemas e validar se o comportamento de escalonamento está alinhado aos requisitos dos workloads. O monitoramento regular também ajuda a detectar restrições de capacidade da AWS, problemas de configuração ou rotatividade inesperada de nós antes que afetem as aplicações.

Ações recomendadas:

• Acompanhe eventos de provisionamento de nós, falhas de provisionamento, atividade de consolidação, pods pendentes e interrupções de instâncias EC2.
• Use Amazon CloudWatch, Prometheus e eventos do Kubernetes para observar o comportamento do Karpenter. Métricas importantes incluem latência de provisionamento, tempo de inicialização dos nós, atrasos de agendamento de pods e rotatividade de nós.
• Revise os logs do controlador para diagnosticar problemas relacionados a permissões do IAM, descoberta de sub-redes ou tipos de instância indisponíveis.

5. Teste antes de habilitar políticas agressivas

Recursos como consolidação agressiva, expiração rápida de nós ou uso amplo de Spot podem reduzir custos, mas podem introduzir instabilidade se não forem testados. Workloads podem reagir de formas diferentes a substituições frequentes de nós, especialmente aqueles com tempos longos de inicialização, componentes com estado ou requisitos rígidos de disponibilidade. Os testes ajudam as equipes a entender os impactos operacionais antes de aplicar essas configurações em produção.

Ações recomendadas:

• Antes de habilitar essas configurações em produção, valide-as em ambientes de pré-produção usando workloads e padrões de escalonamento realistas.
• Preste atenção a workloads com conexões de longa duração, tempos de inicialização elevados ou requisitos rígidos de disponibilidade.
• Teste como as aplicações se comportam durante substituições de nós, eventos de interrupção de Spot e operações rápidas de redução de capacidade.

Como a PerfectScale maximiza seu autoscaling com Karpenter na AWS

Autoscalers de nós como o Karpenter e o Cluster Autoscaler são ferramentas poderosas para escalar nós conforme a demanda, melhorando a disponibilidade do cluster e reduzindo custos com ociosidade. Mas, mesmo com o autoscaling bem configurado, as equipes frequentemente enfrentam três problemas que o comprometem: contêineres superprovisionados que desperdiçam capacidade e forçam o autoscaler a provisionar mais nós que o necessário, contêineres subprovisionados que causam despejos de pods e pressão nos nós, e bin-packing ineficiente que deixa recursos subutilizados enquanto dispara eventos de escalonamento desnecessários. A PerfectScale resolve isso fazendo o right-sizing dos seus workloads de forma autônoma e dando a você visibilidade profunda da eficiência no nível dos nós, para que o Karpenter provisione exatamente a computação de que seu cluster realmente precisa.

Principais recursos da PerfectScale:

• Correção proativa de erros de configuração: Analisa continuamente seus workloads para identificar e corrigir erros de configuração — como CPU Request Not Set, Memory Request Not Set e Memory Limit Not Set — evitando despejos imprevisíveis, sobrecarga de nós e autoscaling ineficiente.
• Right-sizing autônomo de workloads: Ajusta instantaneamente os recursos dos workloads com base na utilização real e melhora o bin-packing dos pods para aumentar a eficiência do autoscaling, tudo sem intervenção manual.
• Eficiência máxima de autoscaling: Oferece visibilidade excepcional dos custos e da utilização dos seus grupos de autoscaling e node pools, revela ineficiências e ajuda você a selecionar os tipos de nó ideais para melhorar a utilização, alcançar uma distribuição precisa de recursos e maximizar a eficiência de custos.

Pronto para extrair o máximo do Karpenter na AWS? Descubra como a PerfectScale otimiza de forma autônoma seus workloads e o autoscaling de nós na página da solução de autoscaling de nós da PerfectScale.