Karpenter en AWS: domina el autoescalado de nodos en EKS

Karpenter vs. Kubernetes Cluster Autoscaler en AWS

Tanto Karpenter como Kubernetes Cluster Autoscaler agregan capacidad de cómputo cuando los pods no se pueden programar, pero utilizan modelos de escalado diferentes.

Cluster Autoscaler trabaja con grupos de nodos existentes, como los managed node groups de Amazon EKS o los Auto Scaling groups. Aumenta o reduce el tamaño de esos grupos según los pods pendientes y los nodos sin uso. Funciona bien cuando los workloads encajan en un número reducido de tipos de nodo conocidos. Es predecible y de uso muy extendido, pero suele requerir una planificación cuidadosa. Los equipos deben definir los grupos de nodos, establecer tamaños mínimos y máximos, y decidir qué tipos de instancia debe usar cada grupo.

Karpenter no requiere grupos de nodos predefinidos. En su lugar, aprovisiona instancias EC2 según los requisitos de los pods pendientes. Esto le permite elegir entre una gama más amplia de tipos de instancia y opciones de capacidad en el momento del aprovisionamiento. Karpenter es adecuado para entornos donde los requisitos de los workloads cambian con frecuencia. Puede seleccionar nodos según CPU, memoria, arquitectura, zona de disponibilidad y tipo de capacidad.

La principal disyuntiva es control frente a flexibilidad:

• Cluster Autoscaler usa un modelo basado en grupos de nodos fijos.
• Karpenter ofrece un aprovisionamiento más dinámico, pero requiere que los equipos administren recursos propios de Karpenter, como NodePool y EC2NodeClass.

Contenido relacionado: Para una comparación más detallada, lee nuestra guía de Karpenter vs. Cluster Autoscaler.

Tutorial: primeros pasos con Karpenter en AWS

Este tutorial muestra cómo crear un clúster de Amazon EKS, instalar Karpenter, definir un NodePool predeterminado y probar el aprovisionamiento automático de nodos. El flujo utiliza eksctl, kubectl, helm y la AWS CLI.

Paso 1: Antes de comenzar, instala las herramientas necesarias:

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

Karpenter necesita permisos de AWS para poder lanzar y terminar instancias EC2. En esta configuración, esos permisos se asocian a la cuenta de servicio de Karpenter mediante pod identity.

Paso 2: Comienza definiendo las variables de entorno principales:

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)"

Estas variables se reutilizan en los comandos posteriores. CLUSTER_NAME identifica el clúster de EKS, mientras que AWS_ACCOUNT_ID se usa al crear los roles y políticas de IAM.

Paso 3: A continuación, obtén los IDs de las AMIs de Amazon Linux 2 recomendadas para la versión de 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 usa estas AMIs cuando crea nodos EC2. Mantenerlas en variables facilita reutilizar más adelante la definición del EC2NodeClass.

Paso 4: Crea la infraestructura de AWS de soporte y el clúster de 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}"

Este stack de CloudFormation crea los recursos de AWS que Karpenter necesita, incluidos los permisos de IAM para aprovisionar nodos.

Paso 5: Ahora crea el clúster de 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

Esto crea un pequeño managed node group para ejecutar los componentes del sistema y el propio Karpenter. El clúster se etiqueta con karpenter.sh/discovery, que Karpenter usa más adelante para descubrir subredes y grupos de seguridad.

Paso 6: Instala 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

Esto despliega el controlador de Karpenter en el clúster. El controlador detecta los pods que Kubernetes no puede programar y luego llama a las APIs de AWS para crear instancias EC2 adecuadas.

Paso 7: A continuación, crea un NodePool y un EC2NodeClass predeterminados:

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

El NodePool define qué nodos puede crear Karpenter. En este ejemplo, permite instancias On-Demand de Linux amd64 de las familias de cómputo, propósito general y optimizadas para memoria.

El EC2NodeClass contiene la configuración específica de AWS. Le indica a Karpenter qué rol de IAM, subredes, grupos de seguridad y AMIs usar al lanzar los nodos.

Paso 8: Para probar el escalado, crea un deployment con cero 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

Este deployment usa la imagen ligera pause. Cada réplica solicita una CPU, lo que lo hace útil para probar el aprovisionamiento de nodos.

Paso 9: Escala el deployment para generar pods sin programar:

kubectl scale deployment inflate --replicas 5

Karpenter debería detectar los pods pendientes y crear nuevos nodos EC2. Puedes seguir los logs del controlador con:

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

Después de la prueba, elimina el deployment:

kubectl delete deployment inflate

Como el NodePool usa WhenEmptyOrUnderutilized, Karpenter puede eliminar los nodos vacíos o infrautilizados tras la consolidación. Esto ayuda a reducir costos cuando los workloads ya no necesitan la capacidad adicional.

Paso 10: Para limpiar el entorno de demostración, desinstala Karpenter y elimina el clúster:

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

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

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

Esto elimina los principales recursos creados durante el tutorial y ayuda a evitar cargos adicionales en AWS.

Mejores prácticas para Karpenter en AWS

Estas son algunas prácticas útiles a considerar al usar Karpenter en AWS.

1. Fija las AMIs en producción

En entornos de producción, evita depender de AMIs seleccionadas automáticamente. En su lugar, fija IDs de AMI específicos en tus definiciones de EC2NodeClass. Esto da a los equipos control sobre la imagen del sistema operativo que usan los nodos de trabajo y reduce el riesgo de cambios inesperados causados por nuevas versiones de AMI. Las AMIs fijadas también mejoran la consistencia entre entornos y simplifican la resolución de problemas.

Acciones recomendadas:

• Los equipos pueden validar los parches de seguridad, los runtimes de contenedores y la compatibilidad con Kubernetes antes de desplegar actualizaciones.
• Prueba las nuevas AMIs en entornos que no sean de producción antes de actualizar los NodePools de producción.
• Mantén un proceso documentado de actualización de AMIs que incluya revisiones de seguridad, procedimientos de rollback y seguimiento de versiones.

2. Usa controles de disrupción

Karpenter incluye funciones de disrupción y consolidación que ayudan a reducir costos al reemplazar o eliminar nodos infrautilizados. Aunque estas capacidades mejoran la eficiencia, una consolidación agresiva puede afectar la disponibilidad de los workloads si los nodos se terminan demasiado rápido. Los controles de disrupción permiten a los equipos equilibrar la optimización de costos con la estabilidad de las aplicaciones, controlando cómo y cuándo ocurren los reemplazos de nodos.

Acciones recomendadas:

• Usa las políticas de consolidación junto con pod disruption budgets, restricciones de distribución por topología y prioridades de workloads.
• Para los servicios críticos, considera aumentar los retrasos de consolidación o limitar los reemplazos de nodos durante el horario laboral.
• En los clústeres de producción, configura con cuidado los ajustes de disrupción y consolidación para evitar interrupciones innecesarias de los workloads.

3. Separa los tipos de workloads con NodePools

Los distintos workloads suelen tener requisitos de infraestructura diferentes. Por ejemplo, los workloads por lotes sin estado pueden ejecutarse en NodePools basados en Spot, mientras que las aplicaciones de cara al cliente pueden usar capacidad On-Demand. Los workloads con GPU, los basados en ARM y las aplicaciones con alto consumo de memoria también pueden usar NodePools dedicados con restricciones de instancia específicas.

Acciones recomendadas:

• Separa los workloads en NodePools dedicados según la sensibilidad al costo, los requisitos de rendimiento, la arquitectura o la tolerancia a interrupciones.
• Usa taints, tolerations, selectores de nodos y reglas de afinidad para garantizar que los workloads se programen en los NodePools adecuados.
• Aplica diferentes políticas de disrupción, consolidación y tipo de capacidad a cada NodePool según las características de los workloads.

4. Monitorea el comportamiento de Karpenter

Monitorea Karpenter como cualquier otro componente del clúster. La visibilidad sobre las decisiones de aprovisionamiento, los eventos del ciclo de vida de los nodos y los resultados de programación ayuda a los equipos a identificar ineficiencias, diagnosticar problemas y validar que el comportamiento de escalado se alinee con los requisitos de los workloads. El monitoreo regular también ayuda a detectar limitaciones de capacidad de AWS, problemas de configuración o una rotación inesperada de nodos antes de que afecten a las aplicaciones.

Acciones recomendadas:

• Haz seguimiento de los eventos de aprovisionamiento de nodos, los lanzamientos fallidos, la actividad de consolidación, los pods pendientes y las interrupciones de instancias EC2.
• Usa Amazon CloudWatch, Prometheus y los eventos de Kubernetes para observar el comportamiento de Karpenter. Entre las métricas importantes están la latencia de aprovisionamiento, el tiempo de arranque de los nodos, los retrasos en la programación de pods y la rotación de nodos.
• Revisa los logs del controlador para diagnosticar problemas relacionados con permisos de IAM, descubrimiento de subredes o tipos de instancia no disponibles.

5. Prueba antes de habilitar políticas agresivas

Funciones como la consolidación agresiva, la expiración rápida de nodos o el uso amplio de Spot pueden reducir costos, pero también introducir inestabilidad si no se prueban. Los workloads pueden responder de manera diferente a los reemplazos frecuentes de nodos, especialmente aquellos con tiempos de arranque largos, componentes con estado o requisitos estrictos de disponibilidad. Las pruebas ayudan a los equipos a entender el impacto operativo antes de aplicar estos ajustes en producción.

Acciones recomendadas:

• Antes de habilitar estos ajustes en producción, valídalos en entornos previos a producción con workloads y patrones de escalado realistas.
• Presta atención a los workloads con conexiones de larga duración, tiempos de arranque prolongados o requisitos estrictos de disponibilidad.
• Prueba cómo se comportan las aplicaciones durante los reemplazos de nodos, los eventos de interrupción de Spot y las operaciones de reducción rápida de capacidad.

Cómo PerfectScale maximiza tu autoescalado con Karpenter en AWS

Los autoescaladores de nodos como Karpenter y Cluster Autoscaler son herramientas potentes para aumentar o reducir los nodos según la demanda, mejorando la disponibilidad del clúster y reduciendo los costos por capacidad ociosa. Pero incluso cuando el autoescalado está bien configurado, los equipos suelen enfrentarse a tres problemas que lo socavan: contenedores sobreaprovisionados que malgastan capacidad y obligan al autoescalador a lanzar más nodos de los necesarios, contenedores subaprovisionados que provocan desalojos de pods y presión sobre los nodos, y un bin-packing ineficiente que deja recursos infrautilizados mientras dispara eventos de escalado innecesarios. PerfectScale lo resuelve aplicando right-sizing autónomo a tus workloads y dándote una visibilidad profunda de la eficiencia a nivel de nodo, para que Karpenter aprovisione exactamente el cómputo que tu clúster realmente necesita.

Capacidades clave de PerfectScale:

• Corrección proactiva de errores de configuración: Analiza continuamente tus workloads para identificar y corregir errores de configuración —como CPU Request Not Set, Memory Request Not Set y Memory Limit Not Set—, evitando desalojos impredecibles, el sobrecompromiso de nodos y un autoescalado ineficiente.
• Right-sizing autónomo de workloads: Ajusta al instante los recursos de los workloads según la utilización real y mejora el bin-packing de los pods para aumentar la eficiencia del autoescalado, todo sin intervención manual.
• Eficiencia de autoescalado al máximo nivel: Ofrece una visibilidad excepcional de los costos y la utilización de tus grupos de autoescalado y pools de nodos, saca a la luz las ineficiencias y te ayuda a seleccionar los tipos de nodo óptimos para mejorar la utilización, lograr una distribución precisa de los recursos y maximizar la eficiencia de costos.

¿Listo para sacarle el máximo provecho a Karpenter en AWS? Descubre cómo PerfectScale optimiza de forma autónoma tus workloads y el autoescalado de nodos en la página de la solución de autoescalado de nodos de PerfectScale.