Réduire vos coûts Kubernetes de 30 à 50 %

Ceci couvre les trois niveaux où les clusters Kubernetes gaspillent réellement du compute, les requests/limits des pods, la composition du node pool, et le réglage du Cluster Autoscaler, et comment corriger les trois ensemble réduit généralement les coûts de 30 à 50 %.

Où les clusters Kubernetes saignent réellement de l'argent

Il y a trois niveaux indépendants, et la plupart des équipes n'en ont jamais ajusté qu'un seul (généralement les types d'instance des nodes) :

Niveau 1 : Requests/limits des pods   →  Demandez-vous plus que ce que vous utilisez ?
Niveau 2 : Composition du node pool   →  Payez-vous le tarif à la demande pour des workloads qui pourraient tourner en spot ?
Niveau 3 : Cluster Autoscaler         →  Le cluster réduit-il réellement sa taille quand la charge baisse ?

Corriger uniquement le Niveau 2 sans corriger le Niveau 1 signifie que vous surprovisionnez sur des nodes moins chers, des économies réelles, mais partielles. Les réductions de 30 à 50 % viennent de la correction des trois niveaux ensemble.

Niveau 1 : redimensionner requests et limits

Récupérez au moins 7 à 14 jours d'utilisation réelle par workload avant de toucher quoi que ce soit ; une seule journée chargée vous mentira. Si vous faites tourner metrics-server (vous devriez) plus Prometheus, faites une vérification kubectl top, puis interrogez container_memory_working_set_bytes / container_cpu_usage_seconds_total dans le temps.

Déployez le Vertical Pod Autoscaler en mode recommandation seule. Évitez le mode Auto lors d'un premier passage, il évince et redémarre les pods, et vous voulez voir les chiffres avant que quoi que ce soit ne redémarre en production :

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: checkout-api-vpa
  namespace: payments
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: checkout-api
  updatePolicy:
    updateMode: "Off" # recommandation seule, rien n'est évincé automatiquement
  resourcePolicy:
    containerPolicies:
      - containerName: "*"
        minAllowed:
          cpu: 50m
          memory: 64Mi
        maxAllowed:
          cpu: 2
          memory: 2Gi

Après une semaine de recommandations VPA, appliquez-les comme requests statiques (ou passez en updateMode: "Auto" une fois les chiffres validés). À elle seule, cette étape est généralement la plus rentable des trois : les clusters que nous avons audités avaient typiquement des requests CPU 2 à 4 fois supérieures à l'usage p95 réel.

Niveau 2 : node pools spot et préemptibles

Tous les workloads n'ont pas leur place en spot, segmentez par tolérance à la disruption, pas par équipe.

• Services stateless, à scaling horizontal, derrière un load balancer → spot/préemptible, toujours.
• Tout ce qui a un état local, les jobs batch longs sans checkpointing, ou tout ce qui tourne en réplique unique → à la demande.

resource "google_container_node_pool" "spot_workers" {
  name       = "spot-workers"
  cluster    = google_container_cluster.primary.name
  location   = var.region
 
  autoscaling {
    min_node_count = 0
    max_node_count = 20
  }
 
  node_config {
    machine_type = "e2-standard-4"
    spot         = true
 
    labels = {
      workload-class = "spot-tolerant"
    }
 
    taint {
      key    = "cloud.google.com/gke-spot"
      value  = "true"
      effect = "NO_SCHEDULE"
    }
  }
}

Associez le taint à une toleration correspondante + un nodeSelector, et définissez un PodDisruptionBudget pour qu'une vague de récupération spot ne puisse pas faire tomber toutes les répliques en même temps :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: checkout-api-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: checkout-api

La capacité spot/préemptible coûte généralement 60 à 80 % moins cher que le tarif à la demande pour le même type d'instance.

Niveau 3 : faire en sorte que le Cluster Autoscaler réduise réellement sa taille

Le mode d'échec le plus courant n'est pas « l'autoscaler ne scale pas vers le haut ». C'est qu'il ne redescend jamais. Quelque chose sur chaque node bloque l'éviction : un pod DaemonSet kube-system sans exception de PodDisruptionBudget, un pod sans contrôleur (Pod brut, pas un Deployment), ou du stockage local (emptyDir est acceptable ; hostPath ne l'est pas).

À vérifier explicitement :

# arguments du déploiement cluster-autoscaler
- --scale-down-utilization-threshold=0.5   # la valeur par défaut est conservatrice ; 0.5-0.6 est généralement sûr
- --scale-down-unneeded-time=10m
- --expander=least-waste                   # choisit le node group qui gaspille le moins de ressources
- --balance-similar-node-groups

L'expander par défaut random scalera un node group surdimensionné alors qu'un plus petit aurait suffi pour le pod en attente.

HPA : éviter le piège du thrashing

Le Horizontal Pod Autoscaler réglé uniquement sur le %CPU brut a tendance à osciller sous un trafic en rafales, ça monte, puis redescend aussitôt, au risque de brefs trous de capacité. Commencez par une fenêtre de stabilisation et une cible d'utilisation réaliste : 70 %, pas 50 %.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: checkout-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: checkout-api
  minReplicas: 3
  maxReplicas: 30
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 25
          periodSeconds: 60

Ce que cela représente généralement

Un avant/après représentatif d'un cluster de taille moyenne (42 nodes, workload mixte) :

Avant : 42 nodes, à la demande uniquement, utilisation moyenne des requests CPU 24 %   → 38 900 $/mois de calcul
Après : 27 nodes, mix spot 55 %, utilisation moyenne des requests CPU 61 %             → 21 300 $/mois de calcul
 
Réduction nette : 45 % (17 600 $/mois)

La réduction de 45 % est venue de la correction des trois niveaux ensemble, pas d'un nouvel outil ou d'une migration.