Kubernetes en AWS: Autoescalado Inteligente para Ahorro del 30% en 2026

La optimización de costos en entornos cloud elásticos se ha consolidado como la métrica de rendimiento más crítica para las organizaciones modernas. A principios de 2026, el despilfarro de recursos en la infraestructura de computación en la nube sigue siendo una realidad persistente; las estimaciones conservadoras sugieren que hasta un 35-40% del gasto en la nube se asigna a recursos subutilizados o mal dimensionados. Este desafío no es meramente financiero; impacta directamente la capacidad de innovación, la agilidad del desarrollo y la competitividad empresarial.

Para las empresas que operan cargas de trabajo intensivas y dinámicas en Kubernetes sobre AWS, la promesa de una infraestructura elástica a menudo se ve empañada por la complejidad de lograr un autoescalado verdaderamente inteligente. Este artículo no solo abordará los fundamentos de un escalado eficiente en Amazon Elastic Kubernetes Service (EKS), sino que presentará una estrategia holística y de vanguardia para 2026, diseñada para reducir el gasto operativo en al menos un 30% sin comprometer la disponibilidad ni el rendimiento. Exploraremos cómo la sinergia entre HPA, VPA, Karpenter, KEDA y herramientas de observabilidad FinOps puede transformar su huella en AWS EKS de un centro de costos a un motor de eficiencia.

---

Fundamentos Técnicos: La Orquestación del Autoescalado Inteligente en EKS

El autoescalado inteligente en Kubernetes sobre AWS EKS es una estrategia multifacética que aborda la elasticidad en múltiples niveles: a nivel de pod, a nivel de nodo y a nivel de evento. Entender cómo estas capas interactúan es fundamental para construir un sistema resilente y rentable.

La Tríada de Autoescalado en Kubernetes (HPA, VPA, Cluster Autoscaler)

Hasta 2026, la base del autoescalado en Kubernetes sigue siendo el conjunto de tres componentes principales, aunque sus implementaciones y sinergias han evolucionado:

1. Horizontal Pod Autoscaler (HPA): El HPA ajusta el número de réplicas de un Pod o Deployment en función de métricas observadas. Históricamente, estas métricas se centraban en el uso de CPU y memoria. Sin embargo, la madurez del ecosystema en 2026 ha estandarizado el uso de métricas personalizadas provenientes de fuentes como Prometheus, AWS CloudWatch o directamente desde un metrics server de Kubernetes.

   • Funcionamiento: El HPA consulta un servidor de métricas (por ejemplo, metrics-server para CPU/memoria básica o adaptadores para métricas personalizadas) y compara el valor actual con un umbral objetivo. Si el uso de CPU supera el 70% en promedio, el HPA incrementará el número de réplicas de pods hasta alcanzar el objetivo, o viceversa para el escalado descendente.
   • Importancia en 2026: Sigue siendo la primera línea de defensa para la elasticidad de las aplicaciones. La capacidad de escalar en función de métricas de negocio (por ejemplo, longitud de cola de SQS, latencia de API, conexiones activas) a través de métricas personalizadas y KEDA (como veremos más adelante) es crucial para la eficiencia.

2. Vertical Pod Autoscaler (VPA): El VPA es responsable de ajustar automáticamente las solicitudes y límites de CPU y memoria para los contenedores. A diferencia del HPA, que cambia el número de pods, el VPA modifica los recursos asignados a cada pod individual.

   • Funcionamiento: El VPA observa el uso histórico de recursos de los pods y recomienda (o aplica directamente) valores óptimos para requests y limits. Esto es vital para asegurar que los pods no soliciten más recursos de los que necesitan (desperdicio) ni menos de los que requiere su carga (throttling y problemas de rendimiento).
   • Consideraciones en 2026: La interacción entre VPA y HPA sigue siendo un punto delicado. Si VPA ajusta requests y HPA escala horizontalmente basándose en CPU, pueden surgir conflictos. La práctica recomendada en 2026 es utilizar VPA en modo recommender para obtener sugerencias y aplicarlas de forma controlada (manual o mediante un CI/CD), o en combinación con herramientas como Goldilocks para visualización, en lugar de permitir que VPA actualice directamente los pods cuando HPA está activo. Esto evita reinicios inesperados de pods y asegura una asignación de recursos estable para el HPA.

3. Cluster Autoscaler (CA): El Cluster Autoscaler, un componente de Kubernetes establecido desde hace años, gestiona el escalado de nodos en el clúster. Si hay pods pendientes de ser programados porque no hay suficiente capacidad de CPU o memoria en los nodos existentes, el CA provisionará nuevos nodos. Si los nodos están infrautilizados y todos sus pods pueden reubicarse en otros nodos, el CA los eliminará.

   • Funcionamiento: Se integra con los proveedores de la nube (AWS en este caso) para interactuar con Auto Scaling Groups (ASGs). Monitorea la capacidad del clúster y los pods pendientes.
   • Limitaciones en 2026: Aunque robusto, el CA tiene limitaciones que han llevado a la adopción de alternativas más avanzadas. Su dependencia de los ASG preconfigurados (con tipos de instancia fijos o limitados) y su lógica de escalado, a veces más lenta y menos optimizada para el coste, pueden resultar en nodos sobredimensionados o en un escalado reactivo que no satisface las demandas de carga pico con la suficiente celeridad. Esto ha abierto la puerta a soluciones como Karpenter.

La Nueva Generación de Aprovisionamiento de Nodos: Karpenter

En 2026, Karpenter ha emergido como el estándar de facto para el aprovisionamiento dinámico de nodos en AWS EKS. Desarrollado por AWS, Karpenter es un aprovisionador de nodos de Kubernetes de código abierto diseñado para ser significativamente más rápido y eficiente en costos que el Cluster Autoscaler tradicional.

• Funcionamiento: Karpenter monitorea los pods pendientes en el clúster y decide la forma más óptima de provisionar capacidad para ellos. En lugar de depender de ASGs preconfigurados, Karpenter interactúa directamente con la API de EC2 para lanzar y terminar instancias.
  • Selección Óptima de Instancias: Puede elegir entre miles de tipos de instancias EC2, incluyendo instancias Spot y On-Demand, encontrando la combinación más barata y adecuada para los requisitos de recursos de los pods.
  • Rapidez: Al eliminar la abstracción del ASG y el tiempo que le lleva sincronizarse con EC2, Karpenter puede lanzar nodos en segundos, no minutos.
  • Optimización de Costos: Prioriza las instancias Spot, lo que puede generar ahorros significativos (hasta un 90% en comparación con On-Demand). Su lógica de "bin-packing" asegura que los pods se ajusten de la manera más densa posible en los nodos, minimizando el número de nodos necesarios y su desperdicio.
  • Desescalado Inteligente: Elimina nodos cuando ya no son necesarios, consolidando los pods en otros nodos para optimizar la utilización y reducir el conteo de instancias.

Escalado Reactivo a Eventos Externos: KEDA (Kubernetes Event-Driven Autoscaling)

Más allá de CPU y memoria, las cargas de trabajo modernas en 2026 a menudo reaccionan a eventos asíncronos. KEDA llena este vacío, permitiendo que las aplicaciones de Kubernetes escalen desde 0 hasta N instancias basándose en la métrica de cualquier fuente de eventos externa.

• Funcionamiento: KEDA extiende el HPA de Kubernetes, permitiéndole escalar Deployments, Jobs u otros recursos de Kubernetes en función del número de eventos que necesitan procesarse. Se integra con una plétora de escaladores (más de 50 en 2026), incluyendo colas de mensajes (SQS, Kafka, RabbitMQ), bases de datos (DynamoDB Streams, Azure Cosmos DB), servicios serverless (Lambda), y muchos otros.
• Valor en 2026: KEDA es indispensable para arquitecturas basadas en eventos, microservicios asíncronos y cargas de trabajo tipo "serverless" ejecutadas en EKS. Permite un escalado mucho más preciso y rentable, ya que las aplicaciones solo consumen recursos cuando hay eventos que procesar, incluso escalando a cero pods cuando no hay actividad.

Visibilidad y Optimización de Costos: Goldilocks y FinOps

La instrumentación de autoescalado debe ir de la mano con la visibilidad de costos.

• Goldilocks: Es una herramienta de recomendación de recursos que se basa en las recomendaciones de VPA para proporcionar una interfaz de usuario fácil de usar. Muestra qué solicitudes y límites de recursos deben configurarse para cada pod, basándose en el uso real. Esto es crucial para ajustar manualmente (o mediante CI/CD) los requests y limits sin el riesgo de conflicto directo entre VPA y HPA.
• FinOps Tools (e.g., Kubecost, AWS Cost Explorer): En 2026, la disciplina FinOps es un pilar fundamental. Herramientas como Kubecost (que se integra profundamente con Kubernetes) y el propio AWS Cost Explorer, complementado con un etiquetado exhaustivo, son esenciales para asignar costos a equipos, proyectos y aplicaciones específicos. Esto permite una identificación precisa del despilfarro y la validación de los ahorros logrados a través de estrategias de autoescalado.

---

Implementación Práctica: Autoescalado Coste-Eficiente en AWS EKS con Karpenter y KEDA

Para demostrar la implementación, asumiremos que ya tiene un clúster EKS operativo. Nos centraremos en la configuración de los componentes clave de autoescalado.

1. Requisitos Previos: Métricas Esenciales

El metrics-server es fundamental para que HPA funcione con métricas básicas de CPU y memoria.

# Verificar si metrics-server ya está desplegado (común en EKS)
kubectl get apiservices v1beta1.metrics.k8s.io

# Si no está presente, desplegarlo (o actualizar a la última versión compatible con su K8s 2026)
# Este ejemplo usa la versión recomendada para K8s 1.28/1.29 en 2026
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Nota: En 2026, asegúrese de que la versión de metrics-server sea compatible con su versión de EKS. Las URLs de latest/download suelen apuntar a la versión más reciente.

2. Despliegue de HPA para Escalar Pods por CPU

Vamos a desplegar una aplicación Nginx simple y configurar un HPA.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-hpa-demo
spec:
  replicas: 1 # Comenzamos con 1 réplica
  selector:
    matchLabels:
      app: nginx-hpa-demo
  template:
    metadata:
      labels:
        app: nginx-hpa-demo
    spec:
      containers:
      - name: nginx
        image: nginx:1.25.3 # Versión estable de Nginx en 2026
        resources:
          requests:
            cpu: "100m" # Solicitud inicial de CPU
            memory: "128Mi"
          limits:
            cpu: "200m" # Límite de CPU
            memory: "256Mi"
        ports:
        - containerPort: 80
---
# hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-cpu-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-hpa-demo
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60 # Escalar cuando la utilización media de CPU sea del 60%

kubectl apply -f deployment.yaml
kubectl apply -f hpa.yaml
kubectl get hpa nginx-cpu-hpa --watch
# Para generar carga:
# kubectl run -it --rm load-generator --image=busybox -- /bin/sh -c "while true; do wget -q -O- http://nginx-hpa-demo; done"

3. Configuración de VPA en Modo Recommender

Para evitar conflictos con HPA, configuraremos VPA para que solo proporcione recomendaciones.

# Instalación de VPA (usando el Helm chart oficial para 2026)
helm repo add sealed-secrets https://charts.bitnami.com/bitnami
helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm repo update
helm upgrade --install vpa fairwinds-stable/vpa \
  --namespace kube-system \
  --set recommender.enabled=true \
  --set updater.enabled=false # Deshabilitar el updater para evitar conflictos
  --set admissionController.enabled=true

Luego, cree un objeto VPA para su Deployment:

# vpa-nginx-recommender.yaml
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: nginx-vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       nginx-hpa-demo
  updatePolicy:
    updateMode: "Off" # Solo recomendar, no aplicar
  resourcePolicy:
    containerPolicies:
      - containerName: '*'
        controlledResources: ["cpu", "memory"]

kubectl apply -f vpa-nginx-recommender.yaml
# Después de un tiempo, y con carga, puede obtener recomendaciones:
kubectl get vpa nginx-vpa-recommender -o yaml

4. Despliegue de Karpenter para Aprovisionamiento de Nodos Eficiente

La instalación de Karpenter implica configurar roles IAM, la política del controlador y el propio Karpenter.

# Asegúrese de tener la CLI de AWS configurada y el ID de su clúster EKS.
CLUSTER_NAME="my-eks-cluster-2026"
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
REGION=$(aws configure get region)

# 1. Crear el perfil de instancia para Karpenter
# Esto permite que los nodos lanzados por Karpenter se unan al clúster EKS
aws cloudformation deploy \
  --stack-name KarpenterNodeStack-${CLUSTER_NAME} \
  --template-file ./karpenter-node-iam-template.yaml \ # Este archivo debe crearse, ver ejemplo abajo
  --capabilities CAPABILITY_IAM \
  --parameter-overrides ClusterName=${CLUSTER_NAME}

# karpenter-node-iam-template.yaml (ejemplo simplificado)
# Este archivo crea el InstanceProfile y los roles necesarios para los nodos.
apiVersion: 2010-09-09
Description: |
  This CloudFormation stack creates the IAM roles and instance profiles that Karpenter will use
  to provision EC2 instances for your EKS cluster.
Resources:
  KarpenterNodeInstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      InstanceProfileName: karpenter-node-instance-profile-${ClusterName}
      Path: "/"
      Roles:
        - Ref: KarpenterNodeRole

  KarpenterNodeRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: karpenter-node-role-${ClusterName}
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - ec2.amazonaws.com
            Action:
              - sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
        - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
        - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore # Para SSH/SSM opcional

# 2. Configurar el rol IAM para el controlador de Karpenter
# El controlador de Karpenter necesita permisos para interactuar con AWS APIs (EC2, EKS, etc.)
# Esto utiliza un OIDC Provider para EKS y una cuenta de servicio de Kubernetes.
EXISTS=$(aws iam list-open-id-connect-providers | grep ${OIDC_PROVIDER} | wc -l)
if [ ${EXISTS} -eq 0 ]; then
  # Crear OIDC Provider si no existe
  eksctl utils associate-iam-oidc-provider --cluster=${CLUSTER_NAME} --approve
fi

# Crear el IAM Role y asociar la ServiceAccount de Karpenter
SERVICE_ACCOUNT_NAME="karpenter"
SERVICE_ACCOUNT_NAMESPACE="karpenter"
TRUST_POLICY=$(cat <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/oidc.eks.${REGION}.amazonaws.com/id/${OIDC_PROVIDER}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.${REGION}.amazonaws.com/id/${OIDC_PROVIDER}:aud": "sts.amazonaws.com",
          "oidc.eks.${REGION}.amazonaws.com/id/${OIDC_PROVIDER}:sub": "system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}"
        }
      }
    }
  ]
}
EOF
)

# Creamos el rol y adjuntamos las políticas necesarias para Karpenter
aws iam create-role --role-name KarpenterControllerRole-${CLUSTER_NAME} --assume-role-policy-document "$TRUST_POLICY" --description "IAM role for Karpenter controller"

# Adjuntar las políticas de AWS gestionadas para Karpenter
aws iam attach-role-policy --role-name KarpenterControllerRole-${CLUSTER_NAME} --policy-arn arn:aws:iam::aws:policy/AmazonEC2FullAccess
aws iam attach-role-policy --role-name KarpenterControllerRole-${CLUSTER_NAME} --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
aws iam attach-role-policy --role-name KarpenterControllerRole-${CLUSTER_NAME} --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy # Puede ser más granular
aws iam attach-role-policy --role-name KarpenterControllerRole-${CLUSTER_NAME} --policy-arn arn:aws:iam::aws:policy/IAMReadOnlyAccess # Para detectar roles de instancia

# 3. Despliegue de Karpenter vía Helm
helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter --version 0.32.0 \ # Versión estable de Karpenter en 2026
  --namespace karpenter --create-namespace \
  --set serviceAccount.create=true \
  --set serviceAccount.name=${SERVICE_ACCOUNT_NAME} \
  --set controller.resources.requests.cpu=1 \
  --set controller.resources.requests.memory=1Gi \
  --set controller.clusterName=${CLUSTER_NAME} \
  --set controller.clusterEndpoint=$(aws eks describe-cluster --name ${CLUSTER_NAME} --query "cluster.endpoint" --output text) \
  --set controller.aws.defaultInstanceProfile=karpenter-node-instance-profile-${CLUSTER_NAME} \
  --set controller.aws.interruptionQueue=$(aws sqs get-queue-url --queue-name karpenter-${CLUSTER_NAME} --query 'QueueUrl' --output text) # Necesita crear una SQS queue para interrupciones de Spot

# Crear Provisioner de Karpenter
# provisioner.yaml
apiVersion: karpenter.sh/v1beta1
kind: Provisioner
metadata:
  name: default
spec:
  # Provisión de nodos de hasta 1000 pods
  limits:
    resources:
      cpu: 1000
  # Estrategia de aprovisionamiento
  requirements:
    - key: karpenter.k8s.aws/instance-category
      operator: In
      values: ["c", "m", "r"] # Priorizar categorías de propósito general y computación/memoria
    - key: karpenter.k8s.aws/instance-family
      operator: In
      values: ["t3", "m5", "c5", "r5"] # Familias de instancias comunes en 2026
    - key: karpenter.sh/capacity-type # Priorizar instancias Spot
      operator: In
      values: ["spot", "on-demand"]
    - key: kubernetes.io/arch
      operator: In
      values: ["amd64"]
    - key: karpenter.sh/restriction-id
      operator: Exists # Restricción única para este provisioner
  # Configuración del tipo de nodo
  providerRef:
    name: default # Referencia al AWSNodeTemplate
  ttlSecondsAfterEmpty: 300 # Terminar nodos después de 5 minutos vacíos
  ttlSecondsUntilExpired: 604800 # 7 días antes de rotar nodos (seguridad, actualizaciones)
  weight: 10 # Prioridad del provisioner
---
apiVersion: karpenter.k8s.aws/v1beta1
kind: AWSNodeTemplate
metadata:
  name: default
spec:
  amiSelector:
    # Selector de AMI de Bottlerocket o Amazon Linux 2023 optimizada para EKS en 2026
    # Asegúrese de usar la AMI adecuada para su versión de Kubernetes y región
    # Ejemplo para Bottlerocket (amd64, k8s 1.29)
    # Puede obtener las AMI ID con la AWS CLI o SSM Parameter Store
    # aws ssm get-parameters --names /aws/service/ami-bottlerocket/eks-1.29/recommended/image_id --region ${REGION}
    karpenter.k8s.aws/instance-family: "bottlerocket"
    k8s.io/instance-type: "amd64"
    eks-distro-base: "bottlerocket-aws"
  subnetSelector:
    karpenter.sh/discovery: ${CLUSTER_NAME} # Descubrir subnets de EKS automáticamente
  securityGroupSelector:
    karpenter.sh/discovery: ${CLUSTER_NAME} # Descubrir security groups de EKS
  tags:
    # Etiquetas para la atribución de costos en Cost Explorer
    Environment: Production
    Project: MyApplication
    ManagedBy: Karpenter

kubectl apply -f provisioner.yaml

Cuando su HPA escale el Deployment de Nginx más allá de la capacidad de los nodos existentes, Karpenter provisionará nuevos nodos.

5. Configuración de KEDA para Autoescalado Basado en Eventos (Ejemplo SQS)

Primero, instale KEDA:

# Instalación de KEDA (usando el Helm chart oficial para 2026)
helm repo add keda https://kedacore.github.io/charts
helm repo update
helm install keda keda/keda --namespace keda --create-namespace

Ahora, desplegaremos una aplicación de consumidor de SQS y un ScaledObject de KEDA.

# sqs-consumer-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sqs-consumer-app
spec:
  replicas: 0 # KEDA puede escalar desde 0
  selector:
    matchLabels:
      app: sqs-consumer
  template:
    metadata:
      labels:
        app: sqs-consumer
    spec:
      containers:
      - name: consumer
        image: your-repo/sqs-consumer:1.0.0 # Reemplace con su imagen de consumidor SQS
        env:
        - name: SQS_QUEUE_URL
          value: "https://sqs.REGION.amazonaws.com/ACCOUNT_ID/my-keda-queue" # URL de su cola SQS
        resources:
          requests:
            cpu: "50m"
            memory: "64Mi"
          limits:
            cpu: "100m"
            memory: "128Mi"
---
# scaledobject.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sqs-consumer-scaledobject
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: sqs-consumer-app
  minReplicaCount: 0 # Escalar a cero cuando no haya mensajes
  maxReplicaCount: 20
  pollingInterval: 30 # Verificar la cola cada 30 segundos
  cooldownPeriod: 300 # Esperar 5 minutos antes de escalar a cero
  triggers:
  - type: aws-sqs
    metadata:
      queueURL: "https://sqs.REGION.amazonaws.com/ACCOUNT_ID/my-keda-queue"
      queueLength: "5" # Objetivo: 5 mensajes por pod
      awsRegion: "REGION"
      identityOwner: pod # Usar el rol IAM asociado al ServiceAccount del pod
    authenticationRef:
      name: keda-aws-secrets # Ver la siguiente sección

Para la autenticación de KEDA con AWS SQS, necesita un TriggerAuthentication y un rol IAM para su ServiceAccount del pod consumidor.

# keda-aws-secrets.yaml
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-aws-secrets
  namespace: keda # O el namespace de su aplicación
spec:
  podIdentity:
    provider: aws # Utilizar IAM Roles for Service Accounts (IRSA)

Configure un IAM Role for Service Accounts (IRSA) para su ServiceAccount sqs-consumer-app (que debe crear) con permisos para leer SQS.

# Ejemplo de creación de ServiceAccount con IRSA
eksctl create iamserviceaccount \
    --name sqs-consumer-app \
    --namespace default \
    --cluster ${CLUSTER_NAME} \
    --attach-policy-arn arn:aws:iam::aws:policy/AmazonSQSReadOnlyAccess \
    --approve

kubectl apply -f sqs-consumer-deployment.yaml
kubectl apply -f keda-aws-secrets.yaml
kubectl apply -f scaledobject.yaml

Ahora, cuando envíe mensajes a my-keda-queue, KEDA escalará su sqs-consumer-app desde cero.

6. Instalación y Uso de Goldilocks

Goldilocks es un chart de Helm simple.

helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm repo update
helm upgrade --install goldilocks fairwinds-stable/goldilocks \
  --namespace goldilocks --create-namespace

Acceda a la interfaz web de Goldilocks con un port-forward: kubectl port-forward svc/goldilocks-dashboard 8080:80 --namespace goldilocks Abra http://localhost:8080 en su navegador. Verá recomendaciones de CPU y memoria para sus pods, basadas en los datos de VPA. Utilice estas recomendaciones para ajustar los requests y limits de sus Deployments.

---

💡 Consejos de Experto: Desde la Trinchera

Como arquitecto de soluciones que ha gestionado clústeres a escala global, he destilado lecciones cruciales que pueden potenciar sus ahorros y estabilidad en EKS:

• Evite el VPA updater con HPA a toda costa (2026): Aunque la documentación técnica muestra que VPA y HPA pueden coexistir bajo ciertas condiciones, en la práctica, el VPA updater puede provocar reinicios de pods en momentos inoportunos o entrar en un bucle de ajuste con el HPA. En 2026, la estrategia más robusta es usar VPA en modo recommender (o solo el VPA admissionController) y usar herramientas como Goldilocks para visualizar las recomendaciones. Aplique estas recomendaciones a sus manifiestos de Deployment de forma manual o a través de su pipeline CI/CD, permitiendo un control más preciso. Esto le da los beneficios del dimensionamiento vertical sin la imprevisibilidad del VPA automático.

• Maximice el uso de Instancias Spot con Karpenter: Karpenter sobresale en la optimización de Spot. En su Provisioner, especifique capacity-type: ["spot", "on-demand"] y asegúrese de que sus instance-category y instance-family sean lo suficientemente diversos (c, m, r y múltiples familias como t3, m5, c5, r5, a1 si aplica). Esto minimiza las interrupciones de Spot y asegura que Karpenter siempre encuentre capacidad disponible y rentable. Para cargas de trabajo críticas, combine Spot con un porcentaje mínimo de On-Demand o considere estrategias de PodDisruptionBudget robustas.

• Etiquetado de Recursos para la Contabilidad FinOps: Implemente una política de etiquetado estricta para todos sus recursos de AWS. Para Karpenter, esto significa añadir etiquetas significativas en el AWSNodeTemplate (por ejemplo, Project, Environment, Owner). Estas etiquetas se propagarán a las instancias EC2 y le permitirán desagregar costos en AWS Cost Explorer o en herramientas FinOps como Kubecost, identificando qué equipos o aplicaciones consumen qué recursos y validando sus ahorros.

• Cargas de Prueba y Benchmarking para la Configuración de Autoescalado: Las configuraciones de HPA (averageUtilization), KEDA (queueLength, threshold) y los tiempos de cooldownPeriod no deben ser adivinanzas. Realice pruebas de carga exhaustivas en entornos de preproducción. Simule picos de tráfico esperados y analice el comportamiento de escalado. Un HPA demasiado sensible puede causar oscilaciones, mientras que uno demasiado lento puede generar latencia. Ajustar estos parámetros con datos reales es clave para la eficiencia y el rendimiento.

• Observabilidad de Primera Clase: Un autoescalado inteligente sin observabilidad es un disparo a ciegas. Implemente una pila de observabilidad robusta (Prometheus + Grafana es el estándar en 2026) para monitorear:

  • Métricas de HPA/VPA: ¿Se están activando? ¿Son efectivos?
  • Métricas de Karpenter: ¿Cuántos nodos se están lanzando/terminando? ¿Qué tipos de instancias? ¿Cuál es la utilización del clúster?
  • Métricas de KEDA: ¿Cuál es el tamaño de las colas? ¿Cómo escala el consumidor en respuesta?
  • Costos: Integre Kubecost o métricas de costos de AWS en sus dashboards para ver el impacto en tiempo real. Esto le permitirá detectar problemas rápidamente y refinar continuamente sus estrategias de autoescalado.

---

Comparativa: Opciones de Autoescalado en EKS (2026)

🚀 Karpenter

✅ Puntos Fuertes

• 🚀 Velocidad de Aprovisionamiento: Lanza nodos en segundos, no minutos, interactuando directamente con la API de EC2.
• ✨ Optimización de Costos: Prioriza inteligentemente instancias Spot y selecciona la combinación más rentable de tipos de instancia para los pods pendientes.
• 🎯 Ajuste Preciso: Minimiza el desperdicio de recursos al consolidar pods y eliminar nodos cuando ya no son necesarios, mejorando la densidad.
• 🔄 Manejo de Interrupciones: Integra el manejo de interrupciones de Spot a través de SQS para una gestión más robusta.

⚠️ Consideraciones

• 💰 Requiere una configuración IAM y de roles más detallada que el Cluster Autoscaler, y una comprensión profunda de su lógica de Provisioner.

🐌 Cluster Autoscaler (CA)

✅ Puntos Fuertes

• 🚀 Madurez y Sencillez: Componente establecido de Kubernetes, fácil de configurar para casos de uso básicos con ASGs preexistentes.
• ✨ Compatibilidad Amplia: Funciona bien con Managed Node Groups de EKS y ASGs definidos manualmente.

⚠️ Consideraciones

• 💰 Dependencia de ASGs fijos que pueden ser sobredimensionados o con tipos de instancia limitados, resultando en un aprovisionamiento subóptimo en costos.
• 🐢 Velocidad Lenta: Mayor latencia en el aprovisionamiento y desaprovisionamiento de nodos debido a la interacción con ASGs y EC2, afectando la reactividad en picos de demanda.

⚖️ Horizontal Pod Autoscaler (HPA) con KEDA

✅ Puntos Fuertes

• 🚀 Escalado Event-Driven: Permite escalar pods desde 0 hasta N réplicas basándose en una amplia gama de eventos externos (colas, streams, etc.), no solo CPU/memoria.
• ✨ Granulometría: Ofrece un control de escalado mucho más granular y preciso para arquitecturas reactivas.
• 💰 Optimización de Costos: Al escalar a cero cuando no hay eventos, reduce drásticamente los costos de recursos ociosos.

⚠️ Consideraciones

• 💰 Añade una capa de complejidad al sistema, requiriendo la instalación y configuración de KEDA y ScaledObjects específicos para cada fuente de evento.
• 🔄 La definición de triggers y thresholds requiere un buen conocimiento de la carga de trabajo y las métricas de negocio.

📊 Horizontal Pod Autoscaler (HPA) Tradicional

✅ Puntos Fuertes

• 🚀 Simplicidad: Fácil de configurar y entender para escalar pods basándose en métricas de recursos estándar como CPU y memoria.
• ✨ Estabilidad: Bien probado y estable para cargas de trabajo predecibles donde la CPU o la memoria son los principales indicadores de carga.

⚠️ Consideraciones

• 💰 Limitado a métricas de recursos básicas; no puede reaccionar a eventos de negocio o métricas externas sin integraciones adicionales.
• 🚧 Puede llevar a una subutilización o sobreaprovisionamiento si las cargas de trabajo no se correlacionan directamente con el uso de CPU/memoria.

---

Preguntas Frecuentes (FAQ)

¿Es Karpenter un reemplazo completo para Cluster Autoscaler en 2026?

Sí, en la mayoría de los casos para clústeres EKS, Karpenter se considera el reemplazo superior para Cluster Autoscaler en 2026. Sus capacidades de aprovisionamiento rápido, selección óptima de instancias (incluidas las Spot) y desescalado eficiente lo hacen más rentable y reactivo. Aunque CA sigue siendo funcional, Karpenter ofrece ventajas significativas para la mayoría de las organizaciones que buscan una optimización de costos y rendimiento de vanguardia.

¿Cómo puedo asegurar que mis pods no se interrumpan durante un escalado descendente de nodos?

La clave es una combinación de Pod Disruption Budgets (PDBs) y el manejo inteligente de la terminación de nodos. Configure PDBs para sus cargas de trabajo críticas, especificando el número mínimo de pods que deben estar disponibles. Karpenter respeta los PDBs durante el desescalado. Además, asegúrese de que sus aplicaciones tengan un terminationGracePeriodSeconds adecuado y manejen las señales SIGTERM para finalizar gracefulmente, lo que permite que los pods completen el trabajo en curso antes de ser terminados.

¿Cuál es el papel de Goldilocks si ya tengo VPA?

Goldilocks complementa a VPA de manera crucial en un entorno de producción en 2026. Mientras que VPA puede proporcionar recomendaciones de recursos (especialmente si se ejecuta en modo recommender), Goldilocks ofrece una interfaz visual intuitiva para explorar y comprender esas recomendaciones. Permite a los equipos de desarrollo y operaciones revisar las sugerencias históricas de VPA, aplicar los ajustes manualmente o integrarlos en su pipeline de CI/CD, sin el riesgo de que el VPA updater cause reinicios inesperados o conflictos con HPA. Es una herramienta de visibilidad y gobernanza, no de autoescalado directo.

¿Es seguro usar instancias Spot para cargas de trabajo críticas?

Las instancias Spot son seguras para cargas de trabajo críticas siempre que se implementen con una estrategia de resiliencia adecuada en 2026. Esto incluye:

1. Diseño tolerante a fallos: Sus aplicaciones deben ser stateless o capaces de recuperar el estado rápidamente, y estar distribuidas entre múltiples zonas de disponibilidad.
2. Diversificación de instancias: Configure Karpenter para usar una amplia gama de tipos de instancias y categorías de Spot para minimizar la probabilidad de interrupciones generalizadas.
3. Manejo de interrupciones: Karpenter integra la detección de avisos de interrupción de Spot de AWS, permitiendo un drenaje graceful del nodo antes de su terminación, dando tiempo a los pods para migrar.
4. Balanceo: Para cargas de trabajo extremadamente sensibles, considere usar una combinación de Spot y On-Demand (p.ej., 80% Spot, 20% On-Demand) o dedicar nodos On-Demand a los pods más críticos.

---

Conclusión y Siguientes Pasos

La era de la simple provisión de infraestructura ha quedado atrás. En 2026, la excelencia operativa en AWS EKS exige un autoescalado inteligente, orquestado y centrado en el valor. Al implementar una estrategia integral que combine la elasticidad a nivel de pod con HPA, la optimización de recursos con VPA (en modo recommender y Goldilocks), el aprovisionamiento de nodos coste-eficiente con Karpenter y el escalado basado en eventos con KEDA, las organizaciones pueden esperar ahorros significativos, fácilmente superando el 30% en comparación con prácticas menos maduras.

Este ahorro no es solo una reducción de costes; es una reinversión en innovación. Libera presupuestos que de otro modo se desperdiciarían, permitiendo a los equipos enfocarse en el desarrollo de productos en lugar de la gestión de la infraestructura.

Su próximo paso debe ser evaluar su clúster EKS actual. Comience por auditar sus costos y la utilización de recursos. Luego, adopte Karpenter como su aprovisionador de nodos principal, integre KEDA para sus cargas de trabajo basadas en eventos, y use las recomendaciones de VPA/Goldilocks para afinar los recursos de sus pods. La trayectoria hacia un clúster EKS verdaderamente optimizado es un viaje continuo de observación, ajuste y mejora.

¿Ha implementado estas estrategias en su entorno? Comparta sus experiencias y resultados en los comentarios. La sabiduría colectiva es el motor del avance en DevOps.

Artículos Relacionados

• Python 2026: Diagnóstico y Solución de Fugas de Memoria en Apps Críticas
• 5 Estrategias Clave: Autoescalado K8s en AWS para Ahorrar Costes 2026
• 5 Estrategias Clave: Escalado Automático Kubernetes para Reducir Costes AWS en 2026