Maintenir la haute disponibilité des services critiques tout en maîtrisant les dépenses cloud : c'est la tension permanente de toute équipe platform. Dans la plupart des architectures GKE, les traitements batch — ingestion de données, calculs asynchrones, jobs d'export — consomment du compute 24h/24 à plein tarif, alors qu'ils ne nécessitent pas le même niveau de fiabilité que les services de production.

Ce REX présente comment les instances Spot GCP permettent de réduire drastiquement cette facture, en isolant proprement les workloads non-critiques via une approche FinOps by design.

Les instances Spot : -80 % sur le compute, avec une contrepartie claire

Les instances Spot sont des machines virtuelles GCP proposées avec une réduction tarifaire de 80 à 90 % par rapport aux instances à la demande. La contrepartie est explicite : GCP peut interrompre la machine à tout moment, avec un préavis court, pour récupérer la capacité.

Ce modèle est parfaitement adapté aux workloads qui présentent trois caractéristiques :

  • Tâches courtes ou idempotentes — une interruption ne cause pas de perte de données
  • Tolérance aux pannes by design — le job peut redémarrer sans impact métier
  • Pas de contrainte de latence temps-réel — les traitements batch en sont l'exemple parfait
L'objectif n'est pas de faire tourner toute l'infrastructure sur Spot, mais de cartographier la criticité réelle de chaque workload et d'allouer les ressources en conséquence. C'est ça, le FinOps by design.

Première étape : isoler les workloads avec un Namespace dédié

Avant de placer des pods sur des nœuds Spot, il faut isoler logiquement les jobs batch des services critiques. Un namespace dédié remplit plusieurs rôles :

  • Séparation logique des ressources entre environnements
  • Suivi de consommation par namespace — indispensable pour le reporting FinOps
  • Application de politiques (NetworkPolicy, ResourceQuota) ciblées
apiVersion: v1
kind: Namespace
metadata:
  name: job-processing
  labels:
    environment: batch
    cost-center: finops-spot

Le label cost-center permet aux outils FinOps (Kubecost, GCP Billing Export) de ventiler la consommation par périmètre fonctionnel.

Deuxième étape : isolation technique avec Taints, Tolerations et Node Affinity

La séparation logique ne suffit pas. Il faut une étanchéité technique garantissant que les pods de production ne finissent jamais sur un nœud Spot, et inversement, que les jobs batch ciblent exclusivement ces nœuds. Trois mécanismes Kubernetes combinés permettent d'atteindre cet objectif.

1. Taint sur les nœuds Spot — interdit tout pod non explicitement autorisé :

# Sur le node pool GKE Spot (via la console ou Terraform)
taints:
  - key: cloud.google.com/gke-spot
    value: "true"
    effect: NoSchedule

2. Toleration sur le pod batch — autorise le pod à ignorer le Taint :

tolerations:
  - key: cloud.google.com/gke-spot
    operator: Equal
    value: "true"
    effect: NoSchedule

3. Node Affinity — force le placement exclusif sur nœuds Spot :

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: cloud.google.com/gke-spot
              operator: In
              values:
                - "true"

Assemblé dans un Deployment complet dans le namespace job-processing, ce triptyque garantit :

  • Aucun pod de production n'atterrit sur un nœud Spot (le Taint le bloque)
  • Les pods batch ciblent uniquement les nœuds Spot (l'Affinity les y force)
  • L'étanchéité est déclarative — pas de garde-fous à maintenir manuellement

Bilan et perspectives

Cette approche produit deux types de bénéfices immédiatement mesurables :

Réduction des coûts 80–90 % sur le compute batch. Visible directement dans GCP Billing avec le label namespace.
Séparation stricte Les pods production ne touchent jamais les nœuds Spot. La stabilité des services critiques est préservée.
FinOps lisible Consommation ventilée par namespace et label cost-center. Chaque euro est traçable.

Le principe sous-jacent est simple : allouer les ressources selon la criticité réelle de chaque workload, pas selon une politique uniforme appliquée à toute l'infrastructure. Les services critiques méritent des nœuds stables. Les jobs batch méritent des instances Spot. C'est ça, le FinOps by design.