Ahorra 60% en AWS con Karpenter y Spot Instances

👻El problema: estás pagando por capacidad fantasma

En un setup típico de EKS con el Cluster Autoscaler tradicional, la historia suele ser así: ASGs con tipos de instancia fijos, nodos On-Demand las 24 horas, y un autoscaler que escala en bloques enteros.

• Los nodos se agregan en minutos, pero tardan mucho más en removerse — el autoscaler es conservador por diseño.
• Todos los nodos son del mismo tipo y tamaño, aunque tus workloads tengan necesidades muy diferentes.
• Los nodos corren como On-Demand, pagando precio completo las 24 horas.
• La utilización real rara vez supera el 40-50%, porque el autoscaler escala en bloques enteros.

⚡La solución: Karpenter + Spot Instances

Karpenter reemplaza al Cluster Autoscaler con un enfoque radicalmente distinto. En vez de trabajar con Auto Scaling Groups pre-definidos, mira directamente los pods que no pueden ser programados y provisiona exactamente la instancia que necesita en ese momento.

• Selección inteligente: ¿Tenés un pod que necesita 2 vCPUs y 8 GB de RAM? Karpenter elige entre docenas de tipos de instancia y selecciona la opción más barata disponible en ese instante.
• Consolidación activa: si detecta que puede mover pods de un nodo subutilizado a otro y liberar ese nodo, lo hace. Menos nodos ociosos, menos dinero desperdiciado.

🔧Instalar y configurar Karpenter

Karpenter necesita permisos IAM específicos para crear y destruir instancias EC2, gestionar ENIs, lanzar en subnets específicas y asumir roles. No es un simple helm install.

apiVersion: karpenter.sh/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  role: "KarpenterNodeRole"
  amiSelectorTerms:
    - alias: al2023@latest
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: "my-cluster"
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: "my-cluster"
  tags:
    Environment: production
    ManagedBy: karpenter

🗂️Definir NodePools con la estrategia correcta

Aquí empieza la complejidad real. Un NodePool define qué tipos de instancias puede usar Karpenter, en qué capacity types (Spot vs On-Demand), con qué límites. Un NodePool mal configurado puede generar más problemas que soluciones.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general-workloads
spec:
  template:
    spec:
      requirements:
        # Más variedad = más disponibilidad Spot
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["m5","m5a","m6i","m6a","m7i","c5","c6i","r5","r6i"]
        # Muy chicos = overhead, muy grandes = desperdicio
        - key: karpenter.k8s.aws/instance-size
          operator: In
          values: ["large","xlarge","2xlarge"]
        # Spot primero, On-Demand como fallback
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot","on-demand"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  # Límites para no despertar con una factura sorpresa
  limits:
    cpu: "200"
    memory: "400Gi"
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

⚖️Separar workloads críticos de no-críticos

No todo debería correr en Spot. Tu base de datos, tu sistema de colas, tu control plane — necesitan estabilidad. Esto implica múltiples NodePools con estrategias distintas.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: critical
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]   # Sin Spot para lo crítico
      taints:
        - key: workload-type
          value: critical
          effect: NoSchedule     # Solo pods que toleren este taint
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "50"

🛡️Manejar las interrupciones de Spot

Spot Instances se interrumpen. Es parte del trato. AWS te da 2 minutos de aviso, y si no estás preparado, tus pods mueren sin gracia. Para manejar esto correctamente necesitás:

• Integración nativa de Karpenter con las señales de interrupción de Spot (o AWS Node Termination Handler).
• Pod Disruption Budgets (PDB) en cada deployment crítico para garantizar que siempre haya réplicas disponibles.
• Topology spread constraints para que las réplicas de un mismo servicio no caigan todas en el mismo nodo o zona.
• Graceful shutdown configurado en tus aplicaciones para terminar requests en vuelo antes de morir.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2    # Siempre al menos 2 réplicas disponibles
  selector:
    matchLabels:
      app: my-app
---
# Deployment con topology spread para distribuir réplicas
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: DoNotSchedule
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway

📊Monitorear y ajustar continuamente

Karpenter no es “configurar y olvidarse”. Para mantener los ahorros necesitás visibilidad continua sobre preguntas como:

• ¿Cuál es la proporción real de Spot vs On-Demand en este momento?
• ¿Con qué frecuencia se interrumpen tus Spot Instances?
• ¿Cuál es la utilización real de los nodos después de la consolidación?
• ¿Estás cerca de los límites de tu NodePool?
• ¿Hay Spot pools que se están agotando y deberías agregar más familias de instancias?

🌙Apagado programado de clusters no productivos

Hay un ahorro más que la mayoría de los equipos ni siquiera considera: ¿para qué tener prendidos tus clusters de dev y staging las 24 horas si tu equipo trabaja 8?