Autoscaling dei nodi EKS con Karpenter: la guida completa

Karpenter vs. Kubernetes Cluster Autoscaler su AWS

Karpenter e Kubernetes Cluster Autoscaler aggiungono entrambi capacità di compute quando i pod non possono essere schedulati, ma utilizzano modelli di scaling diversi.

Cluster Autoscaler lavora con gruppi di nodi esistenti, come i managed node group di Amazon EKS o gli Auto Scaling group. Aumenta o riduce le dimensioni di tali gruppi in base ai pod in pending e ai nodi inutilizzati. Funziona bene quando i workloads rientrano in un numero ridotto di tipi di nodo noti. È prevedibile e ampiamente utilizzato, ma spesso richiede un'attenta pianificazione: i team devono definire i gruppi di nodi, impostare dimensioni minime e massime e decidere quali tipi di istanza utilizzare per ciascun gruppo.

Karpenter non richiede gruppi di nodi predefiniti. Esegue invece il provisioning di istanze EC2 in base ai requisiti dei pod in pending. Questo gli consente di scegliere tra una gamma più ampia di tipi di istanza e opzioni di capacità al momento del provisioning. Karpenter è adatto agli ambienti in cui i requisiti dei workloads cambiano spesso. Può selezionare i nodi in base a CPU, memoria, architettura, availability zone e tipo di capacità.

Il compromesso principale è tra controllo e flessibilità:

• Cluster Autoscaler utilizza un modello basato su gruppi di nodi fissi.
• Karpenter offre un provisioning più dinamico ma richiede ai team di gestire risorse specifiche come NodePool ed EC2NodeClass.

Contenuti correlati: per un confronto più approfondito, consulti la nostra guida Karpenter vs. Cluster Autoscaler.

Tutorial: primi passi con Karpenter su AWS

Questo tutorial mostra come creare un cluster Amazon EKS, installare Karpenter, definire un NodePool predefinito e testare il provisioning automatico dei nodi. Il flusso utilizza eksctl, kubectl, helm e la AWS CLI.

Step 1: prima di iniziare, installare gli strumenti richiesti:

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

Karpenter ha bisogno di permessi AWS per poter avviare e terminare istanze EC2. In questa configurazione, tali permessi vengono associati al service account di Karpenter tramite pod identity.

Step 2: iniziare impostando le principali variabili d'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)"

Queste variabili vengono riutilizzate dai comandi successivi. CLUSTER_NAME identifica il cluster EKS, mentre AWS_ACCOUNT_ID viene utilizzato per la creazione di ruoli e policy IAM.

Step 3: recuperare quindi gli ID delle AMI Amazon Linux 2 consigliate per la versione di 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)"

Karpenter utilizza queste AMI quando crea i nodi EC2. Salvarle in variabili rende più semplice riutilizzarle nella successiva definizione della EC2NodeClass.

Step 4: creare l'infrastruttura AWS di supporto e il 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}"

Questo stack CloudFormation crea le risorse AWS necessarie a Karpenter, inclusi i permessi IAM per il provisioning dei nodi.

Step 5: creare ora il 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

Questo crea un piccolo managed node group per eseguire i componenti di sistema e Karpenter stesso. Il cluster viene taggato con karpenter.sh/discovery, che Karpenter utilizzerà in seguito per individuare subnet e security group.

Step 6: installare Karpenter con 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

Questo comando distribuisce il controller Karpenter nel cluster. Il controller monitora i pod che Kubernetes non riesce a schedulare e chiama poi le API AWS per creare istanze EC2 adeguate.

Step 7: creare quindi un NodePool e una EC2NodeClass predefiniti:

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

Il NodePool definisce quali nodi Karpenter è autorizzato a creare. In questo esempio, consente istanze Linux amd64 On-Demand delle famiglie compute, general-purpose e memory-optimized.

La EC2NodeClass contiene le impostazioni specifiche di AWS. Indica a Karpenter quali ruolo IAM, subnet, security group e AMI utilizzare per l'avvio dei nodi.

Step 8: per testare lo scaling, creare un deployment con zero repliche:

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

Questo deployment utilizza l'immagine pause, molto leggera. Ogni replica richiede una CPU, il che lo rende utile per testare il provisioning dei nodi.

Step 9: scalare il deployment per generare pod non schedulabili:

kubectl scale deployment inflate --replicas 5

Karpenter dovrebbe rilevare i pod in pending e creare nuovi nodi EC2. È possibile seguire i log del controller con:

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

Al termine del test, eliminare il deployment:

kubectl delete deployment inflate

Poiché il NodePool utilizza WhenEmptyOrUnderutilized, Karpenter può rimuovere i nodi vuoti o sottoutilizzati dopo la consolidation. Questo aiuta a ridurre i costi quando i workloads non hanno più bisogno della capacità aggiuntiva.

Step 10: per ripulire l'ambiente demo, rimuovere Karpenter ed eliminare il cluster:

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

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

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

Questo rimuove le principali risorse create durante il tutorial e aiuta a evitare costi AWS aggiuntivi.

Best practice per Karpenter su AWS

Ecco alcune pratiche utili da considerare quando si utilizza Karpenter su AWS.

1. Fissare le AMI in produzione

Negli ambienti di produzione, evitare di affidarsi ad AMI selezionate automaticamente. Fissare invece ID di AMI specifici nelle definizioni delle EC2NodeClass. Questo dà ai team il controllo sull'immagine del sistema operativo utilizzata per i worker node e riduce il rischio di cambiamenti imprevisti causati dal rilascio di nuove AMI. Le AMI fissate migliorano inoltre la coerenza tra gli ambienti e semplificano il troubleshooting.

Azioni consigliate:

• I team possono convalidare patch di sicurezza, container runtime e compatibilità con Kubernetes prima di distribuire gli aggiornamenti.
• Testare le nuove AMI in ambienti non di produzione prima di aggiornare i NodePool di produzione.
• Mantenere un processo documentato di aggiornamento delle AMI che includa revisioni di sicurezza, procedure di rollback e tracciamento delle versioni.

2. Utilizzare i controlli di disruption

Karpenter include funzionalità di disruption e consolidation che aiutano a ridurre i costi sostituendo o rimuovendo i nodi sottoutilizzati. Sebbene queste capacità migliorino l'efficienza, una consolidation aggressiva può compromettere la disponibilità dei workloads se i nodi vengono terminati troppo rapidamente. I controlli di disruption consentono ai team di bilanciare ottimizzazione dei costi e stabilità delle applicazioni, regolando come e quando avvengono le sostituzioni dei nodi.

Azioni consigliate:

• Utilizzare le policy di consolidation insieme a pod disruption budget, topology spread constraint e priorità dei workloads.
• Per i servizi critici, valutare di aumentare i ritardi di consolidation o limitare le sostituzioni dei nodi durante l'orario lavorativo.
• Nei cluster di produzione, configurare con attenzione le impostazioni di disruption e consolidation per evitare interruzioni superflue dei workloads.

3. Separare i tipi di workload con i NodePool

Workloads diversi hanno spesso requisiti infrastrutturali diversi. Ad esempio, i workloads batch stateless possono girare su NodePool basati su Spot, mentre le applicazioni rivolte ai clienti possono utilizzare capacità On-Demand. Anche i workloads GPU, quelli basati su ARM e le applicazioni ad alta memoria possono utilizzare NodePool dedicati con vincoli di istanza specifici.

Azioni consigliate:

• Separare i workloads in NodePool dedicati in base a sensibilità ai costi, requisiti di prestazioni, architettura o tolleranza alle interruzioni.
• Utilizzare taint, toleration, node selector e regole di affinity per garantire che i workloads vengano schedulati sui NodePool appropriati.
• Applicare a ciascun NodePool policy di disruption, consolidation e tipo di capacità differenti, in base alle caratteristiche dei workloads.

4. Monitorare il comportamento di Karpenter

Monitorare Karpenter come qualsiasi altro componente del cluster. La visibilità sulle decisioni di provisioning, sugli eventi del ciclo di vita dei nodi e sugli esiti dello scheduling aiuta i team a individuare inefficienze, diagnosticare problemi e verificare che il comportamento di scaling sia in linea con i requisiti dei workloads. Un monitoraggio regolare aiuta inoltre a rilevare vincoli di capacità AWS, problemi di configurazione o un churn imprevisto dei nodi prima che impattino le applicazioni.

Azioni consigliate:

• Tracciare gli eventi di provisioning dei nodi, i tentativi di avvio falliti, l'attività di consolidation, i pod in pending e le interruzioni delle istanze EC2.
• Utilizzare Amazon CloudWatch, Prometheus e gli eventi Kubernetes per osservare il comportamento di Karpenter. Le metriche importanti includono latenza di provisioning, tempo di avvio dei nodi, ritardi di scheduling dei pod e churn dei nodi.
• Esaminare i log del controller per diagnosticare problemi relativi a permessi IAM, discovery delle subnet o tipi di istanza non disponibili.

5. Testare prima di abilitare policy aggressive

Funzionalità come consolidation aggressiva, scadenza rapida dei nodi o uso esteso di Spot possono ridurre i costi, ma rischiano di introdurre instabilità se non vengono testate. I workloads possono rispondere in modo diverso alle frequenti sostituzioni dei nodi, in particolare quelli con tempi di avvio lunghi, componenti stateful o requisiti stringenti di disponibilità. I test aiutano i team a comprendere l'impatto operativo prima di applicare queste impostazioni in produzione.

Azioni consigliate:

• Prima di abilitare queste impostazioni in produzione, convalidarle in ambienti non di produzione con workloads e pattern di scaling realistici.
• Prestare attenzione ai workloads con connessioni di lunga durata, tempi di avvio elevati o requisiti stringenti di disponibilità.
• Testare il comportamento delle applicazioni durante la sostituzione dei nodi, gli eventi di interruzione Spot e le operazioni di scale-down rapido.

Come PerfectScale massimizza l'autoscaling di Karpenter su AWS

Gli autoscaler di nodi come Karpenter e Cluster Autoscaler sono strumenti potenti per aumentare e ridurre il numero di nodi in base alla domanda, migliorando la disponibilità del cluster e riducendo i costi delle risorse inattive. Ma anche quando l'autoscaling è ben configurato, i team si scontrano spesso con tre problemi che ne compromettono l'efficacia: container sovradimensionati che sprecano capacità e costringono l'autoscaler ad avviare più nodi del necessario, container sottodimensionati che causano eviction dei pod e pressione sui nodi, e un bin-packing inefficiente che lascia risorse sottoutilizzate generando al contempo eventi di scaling superflui. PerfectScale risolve questi problemi applicando in autonomia il right-sizing dei workloads e offrendo una visibilità approfondita sull'efficienza a livello di nodo, così che Karpenter esegua il provisioning esattamente del compute di cui il cluster ha realmente bisogno.

Funzionalità chiave di PerfectScale:

• Correzione proattiva degli errori di configurazione: analizza continuamente i workloads per identificare e correggere errori di configurazione — come CPU Request Not Set, Memory Request Not Set e Memory Limit Not Set — prevenendo eviction imprevedibili, over-commitment dei nodi e autoscaling inefficiente.
• Right-sizing autonomo dei workloads: adegua istantaneamente le risorse dei workloads in base all'utilizzo effettivo e migliora il bin-packing dei pod per aumentare l'efficienza dell'autoscaling, il tutto senza interventi manuali.
• Massima efficienza dell'autoscaling: offre una visibilità eccezionale su costi e utilizzo dei gruppi di autoscaling e dei node pool, fa emergere le inefficienze e aiuta a selezionare i tipi di nodo ottimali per migliorare l'utilizzo, ottenere una distribuzione precisa delle risorse e massimizzare l'efficienza dei costi.

Vuole ottenere il massimo da Karpenter su AWS? Scopra come PerfectScale ottimizza in autonomia i workloads e l'autoscaling dei nodi nella pagina della soluzione di node autoscaling di PerfectScale.