Costos Kubernetes EKS AKS GKE Guía 2026

Introducción: por qué Kubernetes se come tu presupuesto cloud

Si gestionas cargas de trabajo en contenedores, esto no te va a sorprender: Kubernetes es brutal para orquestar aplicaciones, pero también lo es para quemar dinero cuando no se configura bien. Según datos recientes de Datadog, más del 80% del gasto en contenedores se desperdicia por sobreaprovisionamiento de CPU y memoria. Piénsalo un segundo. No es un margen de error menor — es dinero que desaparece literalmente cada mes.

Y en 2026, el problema va a peor.

La adopción de Kubernetes no para de crecer. Más equipos migran cargas de trabajo a clústeres gestionados (EKS, AKS, GKE), pero muy pocos implementan las prácticas de FinOps necesarias para mantener los costos bajo control. El resultado es predecible: facturas cloud que crecen mucho más rápido que el valor que generan las aplicaciones desplegadas. Yo lo he visto en proyectos reales — equipos que pasan de $3,000 a $12,000 al mes sin haber añadido ninguna funcionalidad nueva.

Bueno, vamos a ir directo a lo práctico. En esta guía cubriremos la anatomía completa de costos de Kubernetes en los tres grandes proveedores, configuraciones reales de autoescalado (HPA, VPA, KEDA, Karpenter), estrategias de instancias spot específicas para cada cloud, y las herramientas que necesitas para tener visibilidad real de lo que gastas. Todo con ejemplos de código que puedes implementar hoy mismo.

Anatomía de los costos de Kubernetes por proveedor

Antes de optimizar nada, necesitas entender exactamente qué estás pagando. Los costos de un clúster Kubernetes se descomponen en cuatro categorías principales, y cada proveedor los gestiona de forma bastante diferente.

Costo del plano de control (Control Plane)

Esta es la primera diferencia significativa entre proveedores, y honestamente, es la que más sorprende a los equipos que están evaluando opciones:

Proveedor	Costo del control plane	Detalle
AWS EKS	$0.10/hora (~$73/mes)	Tarifa fija por clúster, independiente del tamaño
Azure AKS	Gratuito (nivel básico)	Sin SLA; nivel premium disponible con costo
Google GKE	Gratuito (zonal) / $0.10/hora (regional)	$74.40/mes en créditos gratuitos por cuenta de facturación

Un detalle que muchos equipos pasan por alto en EKS: AWS cobra $0.60/hora por clúster ($432/mes) si ejecutas una versión de Kubernetes no soportada. Eso es un incremento del 600% sobre la tarifa estándar. Así que sí, mantener tus clústeres actualizados es literalmente una acción de optimización de costos de alto impacto.

Costo de cómputo (nodos worker)

Aquí es donde duele de verdad. El cómputo representa típicamente entre el 60% y el 80% de tu factura total de Kubernetes, y es donde se concentran la mayoría de las oportunidades de ahorro. Para una referencia rápida con instancias de propósito general:

Instancia equivalente	AWS (m7i.xlarge)	Azure (D4s_v5)	GCP (n2-standard-4)
vCPUs / RAM	4 vCPU / 16 GB	4 vCPU / 16 GB	4 vCPU / 16 GB
On-demand (hora)	~$0.2016	~$0.192	~$0.1942
On-demand (mes)	~$147	~$140	~$142
Spot/Preemptible	~$0.06–$0.08	~$0.04–$0.06	~$0.04–$0.06
Reservado 1 año	~$0.127 (37% desc.)	~$0.121 (37% desc.)	~$0.122 (CUD 37%)

Costo de almacenamiento

Los volúmenes persistentes (PV) son un costo que se acumula silenciosamente. Nadie presta atención hasta que la factura llega. Comparativa para discos SSD de 200 GB:

AWS EBS gp3: ~$22/mes
Azure Premium SSD: ~$80/mes
GCP Persistent Disk SSD: ~$9/mes

GCP tiene una ventaja clara aquí. Si tu aplicación es intensiva en disco, esta diferencia puede ser determinante a la hora de elegir proveedor. Además (y esto es algo que poca gente revisa), muchos clústeres acumulan PersistentVolumes huérfanos — volúmenes que quedan tras eliminar pods o StatefulSets sin que nadie se dé cuenta. Auditar y eliminar estos volúmenes regularmente puede ahorrar cientos de dólares al mes.

Costo de red (transferencia de datos)

El tráfico de red es, sin duda, el costo más subestimado en Kubernetes:

AWS: $0.01/GB por tráfico entre zonas de disponibilidad (cross-AZ). Un service mesh con 10 TB/mes de tráfico inter-pod genera $100/mes solo en networking. Parece poco hasta que lo multiplicas por varios clústeres.
Azure: Tráfico entre zonas de disponibilidad gratuito. Esta es una ventaja real para despliegues multi-AZ y, francamente, un punto que Azure no publicita lo suficiente.
GCP: Egress inter-región a $0.08/GB, el más caro de los tres. Eso sí, tráfico intra-zona gratuito.

Autoescalado inteligente: la clave para reducir costos

El autoescalado bien configurado es la herramienta más poderosa para reducir costos en Kubernetes. Pero ojo: mal configurado, puede ser exactamente lo contrario. Nodos que se mantienen activos sin necesidad, pods que nunca escalan hacia abajo, recursos reservados que nadie usa... Veamos cómo configurar cada componente correctamente.

HPA (Horizontal Pod Autoscaler): escalar réplicas según demanda

El HPA ajusta el número de réplicas de un pod basándose en métricas observadas. La configuración más básica usa CPU, pero en 2026 deberías escalar también por métricas de aplicación. ¿Por qué? Para evitar el efecto de "indicador retrasado" — cuando la CPU sube, la cola de peticiones ya está llena y tus usuarios ya están experimentando latencia.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-gateway-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-gateway
  minReplicas: 2
  maxReplicas: 20
  metrics:
  # Métrica primaria: peticiones por segundo (custom metric)
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "100"
  # Métrica secundaria: CPU como safety net
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        targetAverageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # Esperar 5 min antes de escalar abajo
      policies:
      - type: Percent
        value: 25           # Máximo 25% de reducción por ciclo
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Percent
        value: 100          # Duplicar réplicas si es necesario
        periodSeconds: 60

La sección behavior es fundamental para costos. Sin stabilizationWindowSeconds en el scale-down, el HPA puede oscilar constantemente entre escalado arriba y abajo (lo que se conoce como flapping), generando inestabilidad y desperdicio. Los 300 segundos de ventana de estabilización previenen que el sistema escale hacia abajo prematuramente después de un pico transitorio. Es un detalle pequeño que marca una diferencia enorme en la factura.

VPA (Vertical Pod Autoscaler): dimensionamiento correcto automático

El VPA ajusta las requests y limits de CPU y memoria de los pods existentes basándose en el uso histórico. Es especialmente valioso para cargas stateful donde añadir réplicas no es una opción.

Mi recomendación: úsalo en modo Off o Initial para obtener recomendaciones sin aplicar cambios automáticos que podrían reiniciar pods en producción. Nadie quiere un reinicio sorpresa a las 3 de la madrugada.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: backend-api-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: backend-api
  updatePolicy:
    updateMode: "Off"  # Solo recomendaciones, sin aplicación automática
  resourcePolicy:
    containerPolicies:
    - containerName: backend
      minAllowed:
        cpu: "100m"
        memory: "128Mi"
      maxAllowed:
        cpu: "4"
        memory: "8Gi"
      controlledResources: ["cpu", "memory"]

Para consultar las recomendaciones del VPA, ejecuta:

kubectl describe vpa backend-api-vpa -n production

Busca la sección Recommendation en la salida. Compara los valores sugeridos con tus requests actuales. En mi experiencia, lo típico es descubrir que tus pods solicitan 2x o 3x más recursos de los que realmente consumen. Es un desperdicio silencioso que se repite en prácticamente todos los clústeres que he auditado.

KEDA: escalar a cero y basado en eventos

KEDA es un auténtico game-changer para costos porque permite algo que el HPA estándar no puede: escalar a cero réplicas. Esto es especialmente potente para entornos de desarrollo, procesamiento de colas y trabajos batch.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor
  namespace: production
spec:
  scaleTargetRef:
    name: order-processor
  minReplicaCount: 0    # Escalar a cero cuando no hay mensajes
  maxReplicaCount: 30
  cooldownPeriod: 120   # Esperar 2 min sin actividad antes de escalar a 0
  pollingInterval: 15   # Verificar cola cada 15 segundos
  triggers:
  - type: aws-sqs-queue
    metadata:
      queueURL: https://sqs.us-east-1.amazonaws.com/123456789/orders
      queueLength: "5"       # 1 pod por cada 5 mensajes en cola
      awsRegion: us-east-1
      identityOwner: operator

Con KEDA, un servicio que procesa órdenes de una cola SQS puede pasar de 0 pods (sin costo de cómputo) a 30 pods durante picos de Black Friday, y volver a 0 cuando la cola se vacía. En entornos de desarrollo, esto puede reducir costos de cómputo en más del 90% para servicios que solo se activan de vez en cuando. Sí, 90%. No es una exageración.

Karpenter vs Cluster Autoscaler: provisión de nodos optimizada

El Cluster Autoscaler ha sido el estándar durante años, pero Karpenter está cambiando las reglas del juego. Datos de producción muestran que migrar de Cluster Autoscaler a Karpenter puede reducir costos de cómputo en un 30%, y estas son las razones:

Provisión dinámica: Karpenter selecciona el tipo de instancia óptimo para cada carga de trabajo en tiempo real, sin depender de node groups predefinidos.
Consolidación proactiva: Desaloja pods y consolida nodos subutilizados automáticamente, en lugar de solo eliminar nodos vacíos.
Velocidad: Provisiona nuevos nodos en ~55 segundos vs. 3-4 minutos del Cluster Autoscaler. La diferencia se nota.
Integración nativa con Spot: Evaluación automática de instancias spot disponibles con fallback a on-demand.

Veamos un ejemplo de un NodePool de Karpenter optimizado para costos:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: cost-optimized
spec:
  template:
    spec:
      requirements:
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]  # Priorizar spot
      - key: kubernetes.io/arch
        operator: In
        values: ["amd64", "arm64"]      # Incluir ARM para mejor precio
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - m7i.large
        - m7i.xlarge
        - m7g.large       # Graviton — ~20% más barato
        - m7g.xlarge
        - c7i.large
        - c7g.large
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 60s   # Consolidar nodos subutilizados tras 60s
  limits:
    cpu: "200"              # Límite total del NodePool
    memory: "400Gi"

Un punto clave que no debes ignorar: incluir instancias ARM (Graviton en AWS) en la lista de tipos permitidos puede reducir costos un 20% adicional respecto a instancias x86 equivalentes, siempre que tus contenedores tengan imágenes multi-arquitectura. Merece totalmente la pena el esfuerzo de mantener builds multi-arch.

Karpenter está disponible actualmente en AWS y Azure, con soporte beta para GCP. Si tu clúster está en GKE, el Cluster Autoscaler con perfil optimize-utilization sigue siendo la mejor opción nativa por ahora.

Instancias spot en Kubernetes: configuración por proveedor

Las instancias spot ofrecen descuentos del 60% al 91% sobre precios on-demand. La clave está en configurar tus clústeres para tolerar interrupciones de forma elegante. A continuación van las configuraciones específicas para cada proveedor — todas probadas en entornos reales.

EKS: node groups con instancias spot

# eks-spot-nodegroup.yaml — Terraform
resource "aws_eks_node_group" "spot_workers" {
  cluster_name    = aws_eks_cluster.main.name
  node_group_name = "spot-workers"
  node_role_arn   = aws_iam_role.eks_node.arn
  subnet_ids      = var.private_subnet_ids

  capacity_type = "SPOT"

  instance_types = [
    "m7i.large", "m7i.xlarge",
    "m7g.large", "m7g.xlarge",   # Graviton
    "m6i.large", "m6i.xlarge",
    "c7i.large", "c7g.large"
  ]

  scaling_config {
    desired_size = 3
    max_size     = 20
    min_size     = 1
  }

  labels = {
    "workload-type" = "spot-tolerant"
  }

  taint {
    key    = "spot"
    value  = "true"
    effect = "NO_SCHEDULE"
  }

  tags = {
    "cost-center"  = "platform"
    "environment"   = "production"
  }
}

La diversificación de tipos de instancia es crítica en AWS. AWS tiene la mayor volatilidad de precios spot (hasta 197 cambios de precio al mes para instancias populares), así que a mayor variedad de tipos, menor probabilidad de que todas tus instancias se interrumpan a la vez.

AKS: node pools con spot VMs

# aks-spot-nodepool.yaml — Terraform
resource "azurerm_kubernetes_cluster_node_pool" "spot" {
  name                  = "spotpool"
  kubernetes_cluster_id = azurerm_kubernetes_cluster.main.id
  vm_size               = "Standard_D4s_v5"
  priority              = "Spot"
  eviction_policy       = "Delete"
  spot_max_price        = -1  # Acepta precio de mercado actual

  min_count  = 1
  max_count  = 15
  node_count = 3

  enable_auto_scaling = true

  node_labels = {
    "kubernetes.azure.com/scalesetpriority" = "spot"
    "workload-type"                          = "spot-tolerant"
  }

  node_taints = [
    "kubernetes.azure.com/scalesetpriority=spot:NoSchedule"
  ]

  tags = {
    cost-center = "platform"
  }
}

Azure tiene la menor volatilidad de precios spot (~0.76 cambios/mes), lo que la convierte en la opción más predecible para cargas spot. Un dato que muchos olvidan: como AKS no cobra tráfico inter-AZ, los ahorros se amplifican al distribuir pods spot entre varias zonas sin penalización de red.

GKE: node pools con spot VMs

# gke-spot-nodepool.yaml — Terraform
resource "google_container_node_pool" "spot_pool" {
  name       = "spot-pool"
  cluster    = google_container_cluster.main.name
  location   = "us-central1"

  autoscaling {
    min_node_count = 1
    max_node_count = 15
  }

  node_config {
    spot         = true
    machine_type = "n2-standard-4"

    labels = {
      "workload-type" = "spot-tolerant"
    }

    taint {
      key    = "cloud.google.com/gke-spot"
      value  = "true"
      effect = "NO_SCHEDULE"
    }

    oauth_scopes = [
      "https://www.googleapis.com/auth/cloud-platform"
    ]
  }
}

GKE Spot VMs ofrecen los descuentos más profundos (hasta 91%), pero también la política de interrupción más agresiva. Son ideales para runners de CI/CD y trabajos batch donde puedes reintentar sin problema. Para cargas que necesitan mayor estabilidad, mejor usa el perfil optimize-utilization del Cluster Autoscaler de GKE en modo Standard.

Toleraciones y afinidad para cargas spot

Para que tus pods se ejecuten en nodos spot, necesitan toleraciones explícitas. Esto es lo que asegura que solo las cargas tolerantes a interrupciones se programen en nodos spot (no querrás que tu base de datos acabe ahí por accidente):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: batch-processor
spec:
  replicas: 5
  template:
    spec:
      tolerations:
      - key: "spot"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: workload-type
                operator: In
                values:
                - spot-tolerant
      terminationGracePeriodSeconds: 60
      containers:
      - name: processor
        image: myapp/batch-processor:latest
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1Gi"

GKE Autopilot: ¿alternativa más económica al modo Standard?

GKE Autopilot merece una mención aparte porque cambia el modelo de facturación por completo. En lugar de pagar por nodos (VMs), pagas únicamente por los recursos que tus pods solicitan. Esto elimina de raíz el desperdicio de capacidad ociosa.

Los números hablan solos: en pruebas documentadas por Google Cloud, ejecutar cargas de trabajo idénticas en Autopilot resultó entre un 12% y un 40% más barato que en modo Standard. ¿La razón? Si tu clúster Standard opera al 40% de utilización (algo bastante típico, seamos honestos), estás pagando por el 60% de capacidad que simplemente no usas.

Precios de referencia de Autopilot en 2026 (us-central1):

vCPU: $0.0445/hora
Memoria: $0.0049/GiB-hora
Almacenamiento efímero SSD: $0.00014/GiB-hora

Cuándo elegir Autopilot: equipos pequeños sin especialistas en Kubernetes, cargas de trabajo variables con picos impredecibles, o cuando quieres minimizar la sobrecarga operativa. Cuándo elegir Standard: si necesitas control granular sobre nodos, usas DaemonSets personalizados extensivamente, o tu clúster opera consistentemente por encima del 80% de utilización. En este último caso, Standard te sale más rentable.

Reducción de costos de red en Kubernetes

El tráfico entre zonas de disponibilidad es un gasto oculto que puede representar entre el 5% y el 15% de tu factura total. No es poco. Estas estrategias te ayudan a controlarlo:

Pod Affinity para minimizar tráfico cross-AZ

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  template:
    spec:
      affinity:
        podAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - cache-service  # Co-localizar con el cache
              topologyKey: topology.kubernetes.io/zone

Topology Aware Routing

Habilitar el ruteo consciente de topología hace que los servicios de Kubernetes prefieran endpoints en la misma zona. Es una configuración sencilla que puede ahorrarte bastante:

apiVersion: v1
kind: Service
metadata:
  name: api-service
  annotations:
    service.kubernetes.io/topology-mode: Auto
spec:
  selector:
    app: api-service
  ports:
  - port: 80
    targetPort: 8080

Consolidar load balancers con Ingress

Cada LoadBalancer de Kubernetes crea un balanceador de carga externo (~$16-18/mes en cualquier proveedor). Si tienes 20 servicios con LoadBalancer individual, estamos hablando de más de $300/mes. Consolidar con un controlador Ingress (NGINX, Traefik, o ALB Ingress Controller) reduce todo esto a un solo balanceador:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: consolidated-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: api.ejemplo.com
    http:
      paths:
      - path: /orders
        pathType: Prefix
        backend:
          service:
            name: orders-service
            port:
              number: 80
      - path: /users
        pathType: Prefix
        backend:
          service:
            name: users-service
            port:
              number: 80
      - path: /payments
        pathType: Prefix
        backend:
          service:
            name: payments-service
            port:
              number: 80

Monitoreo y visibilidad de costos

No puedes optimizar lo que no puedes medir. Parece un cliché, pero es absolutamente cierto en Kubernetes. Estas son las métricas clave y herramientas que todo equipo de FinOps debería tener en su radar.

Métricas esenciales

Costo por namespace: identifica qué equipos o proyectos generan más gasto.
CPU/memoria solicitada vs. consumida: la brecha entre requests y uso real es desperdicio directo. Así de simple.
Porcentaje de recursos ociosos: capacidad pagada pero no utilizada.
Costo por pod/servicio: para mapear el gasto a unidades de negocio concretas y tener conversaciones productivas sobre presupuesto.

Script de auditoría rápida de eficiencia

Este script identifica los namespaces con mayor desperdicio de recursos. Es un buen punto de partida para cualquier auditoría:

#!/bin/bash
# audit-k8s-efficiency.sh
# Identifica namespaces con recursos sin utilizar

echo "=== Auditoría de eficiencia de recursos Kubernetes ==="
echo "Fecha: $(date -u +'%Y-%m-%dT%H:%M:%SZ')"
echo ""

for ns in $(kubectl get namespaces -o jsonpath='{.items[*].metadata.name}'); do
  [[ "$ns" == kube-* ]] && continue
  [[ "$ns" == "default" ]] && continue

  cpu_req=$(kubectl top pods -n "$ns" --no-headers 2>/dev/null |     awk '{sum += $2} END {print sum+0}')
  mem_req=$(kubectl top pods -n "$ns" --no-headers 2>/dev/null |     awk '{sum += $3} END {print sum+0}')

  if [ "$cpu_req" -gt 0 ] 2>/dev/null; then
    echo "Namespace: $ns"
    echo "  CPU en uso: ${cpu_req}m"
    echo "  Memoria en uso: ${mem_req}Mi"
    echo ""
  fi
done

echo "=== PVs sin usar ==="
kubectl get pv -o json |   jq -r '.items[] | select(.status.phase == "Released") |
  "  PV: \(.metadata.name) - Capacidad: \(.spec.capacity.storage)"'

Herramientas recomendadas en 2026

Herramienta	Especialidad	Mejor para
Kubecost	Visibilidad de costos por namespace/pod	Equipos que necesitan cost allocation detallado
CAST AI	Optimización automatizada multi-cloud	Right-sizing y spot automation
Finout	Monitoreo en tiempo real con granularidad sub-hora	Entornos dinámicos con picos frecuentes
ScaleOps	Right-sizing automatizado de pods	Equipos sin bandwidth para ajustes manuales
AWS Compute Optimizer	Recomendaciones nativas AWS	Clústeres EKS exclusivos en AWS

Checklist de optimización: resumen accionable

Antes de cerrar, aquí tienes una lista de verificación ordenada por impacto. Cada acción incluye el ahorro estimado que puedes esperar:

Configurar VPA en modo Off y revisar recomendaciones de right-sizing — ahorro del 20-40% en cómputo.
Migrar cargas tolerantes a interrupciones a instancias spot con diversificación de tipos — ahorro del 60-90% en esos workloads.
Implementar Karpenter (AWS/Azure) o perfil optimize-utilization (GKE) — ahorro del 30% por consolidación.
Configurar KEDA para servicios event-driven y entornos de desarrollo — escalar a cero elimina costos de cómputo inactivo.
Consolidar LoadBalancers con controlador Ingress — ahorro de $15-18/mes por cada servicio migrado.
Habilitar Topology Aware Routing y Pod Affinity — reducción del 40-60% en costos de tráfico cross-AZ.
Auditar PVs huérfanos y recursos olvidados mensualmente — recuperar 5-15% de gasto en almacenamiento.
Actualizar versiones de Kubernetes en EKS — evitar el recargo del 600% por versiones no soportadas.

La combinación de estas estrategias permite alcanzar reducciones del 40% al 70% en tu factura de Kubernetes, según datos de equipos de producción en 2026. Eso sí, la clave es tratarlo como un proceso continuo, no como un proyecto puntual que haces una vez y te olvidas.

Preguntas frecuentes

¿Cuánto cuesta realmente un clúster Kubernetes en la nube?

Depende mucho del tamaño y la configuración. Un clúster pequeño de desarrollo (3 nodos, instancias de propósito general) cuesta entre $150 y $300/mes. Un clúster de producción con 20+ nodos puede superar fácilmente los $3,000-$5,000/mes. El plano de control en EKS añade $73/mes fijos; en AKS es gratuito (nivel básico) y en GKE es gratuito para clústeres zonales. El cómputo (nodos worker) representa entre el 60% y el 80% de la factura total.

¿Es mejor usar Karpenter o Cluster Autoscaler para reducir costos?

Para clústeres en AWS, Karpenter ofrece hasta un 30% de ahorro adicional frente al Cluster Autoscaler gracias a su capacidad de seleccionar dinámicamente el tipo de instancia óptimo y consolidar nodos proactivamente. Dicho esto, el Cluster Autoscaler sigue siendo la mejor opción para entornos multi-cloud, clústeres con GPUs, o cuando necesitas máxima estabilidad y compatibilidad. Karpenter ya tiene soporte en Azure y soporte beta en GCP.

¿Cómo puedo usar instancias spot en Kubernetes sin afectar la disponibilidad?

La estrategia clave es segregar. Usa node pools dedicados para spot con taints, y asegúrate de que solo cargas tolerantes a interrupciones (con toleraciones explícitas) se programen allí. Diversifica los tipos de instancia (al menos 5-6 tipos diferentes) para reducir la probabilidad de interrupción simultánea. Implementa Pod Disruption Budgets para controlar cuántos pods pueden interrumpirse a la vez, y mantén cargas críticas (bases de datos, servicios con estado) siempre en nodos on-demand o reservados.

¿GKE Autopilot es más barato que el modo Standard?

Depende de tu utilización. Si tu clúster Standard opera por debajo del 60% de utilización (algo bastante común), Autopilot será entre un 12% y un 40% más barato porque solo pagas por los recursos que tus pods solicitan, no por la capacidad total del nodo. Si tu equipo optimiza activamente y mantiene una utilización por encima del 80%, el modo Standard puede resultar más económico. Autopilot brilla especialmente en equipos pequeños sin especialistas dedicados en Kubernetes.

¿Cuáles son los costos ocultos más comunes en Kubernetes?

Los cinco que veo con más frecuencia: (1) tráfico cross-AZ en AWS y GCP, que puede acumular cientos de dólares mensuales en clústeres distribuidos; (2) PersistentVolumes huérfanos que permanecen tras eliminar workloads sin que nadie los revise; (3) el recargo de EKS por versiones de Kubernetes no soportadas ($432/mes extra por clúster); (4) load balancers individuales por servicio (~$18/mes cada uno, que se suman rápido); y (5) sobrecostos de logging y monitoreo cuando se envían todas las métricas y logs sin filtrar a herramientas de observabilidad.