FinOps : réduire vos coûts Kubernetes de 40%

Nous avons audité une centaine de clusters Kubernetes en Suisse et France. Résultat : 60-70% des organisations surpaie entre 30-50% de leur facture cloud. Pourquoi ? Outils mal configurés, ressources surdimensionnées, aucune allocation des coûts par équipe.

Avec une stratégie FinOps simple, vous retrouvez cette moitié de facture.

C'est quoi, FinOps ?

FinOps = Finance + Operations. C'est la discipline de gérer les coûts cloud comme un CFO gère le budget d'une usine.

Trois piliers :

1. Visibility : savoir où va chaque centime
2. Optimization : réduire le waste
3. Accountability : les équipes responsables de leurs coûts

La plupart des organisations font zéro sur ces trois points.

Visibility : le diagnostic

Avant d'optimiser, vous devez voir le problème.

Étape 1 : Exporter vos coûts

Si vous êtes sur Azure, AWS, ou GCP :

Azure :

az costmanagement query --metric ActualCost --timeframe MonthToDate \
  --dataset granularity=Daily aggregation={totalCost=sum}

AWS :

aws ce get-cost-and-usage --time-period Start=2026-01-01,End=2026-02-01 \
  --granularity MONTHLY --metrics BlendedCost --group-by Type=DIMENSION,Key=SERVICE

GCP :

gcloud billing accounts list
bq query --use_legacy_sql=false < query.sql

Étape 2 : Instrumenter votre cluster

Vous avez besoin de voir qui consomme quoi.

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    cost-center: "platform-engineering"
    owner-team: "infrastructure"
---
apiVersion: v1
kind: Pod
metadata:
  name: api-server
  namespace: production
  labels:
    app: api
    cost-allocation: "api-team"
spec:
  containers:
  - name: api
    image: myapp:1.0
    resources:
      requests:
        memory: "512Mi"
        cpu: "250m"
      limits:
        memory: "1Gi"
        cpu: "500m"

Les labels sont critiques. Ils permettent de backcharger les coûts.

Étape 3 : Utiliser un outil de monitoring des coûts

Plusieurs options (du simple au complexe) :

Pour 90% des cas, kubecost est parfait.

# Installation Helm
helm repo add kubecost https://kubecost.github.io/cost-analyzer
helm install kubecost kubecost/cost-analyzer -n kubecost --create-namespace \
  --set kubecostModel.warmCache=true \
  --set kubecostModel.warmSavingsCache=true

Ensuite, accédez à http://localhost:9090 et vous avez :

• Coûts par namespace
• Coûts par pod
• Coûts par cluster
• Économies potentielles

Status : - Kubecost (ou équivalent) installé et exposé

Optimization : retrouver 40%

1. Right-sizing : le 80% du gain

Problème : les requests/limits sont souvent devinées ou copiées. Résultat : sur-allocation massif.

# ❌ MAUVAIS : requests trop hauts
resources:
  requests:
    memory: "2Gi"      # réellement utilisé : 256Mi
    cpu: "1000m"       # réellement utilisé : 100m
  limits:
    memory: "4Gi"
    cpu: "2000m"
---
# ✅ BON : rightsized
resources:
  requests:
    memory: "256Mi"    # observation réelle + 20% headroom
    cpu: "100m"
  limits:
    memory: "512Mi"    # 2x les requests pour pic
    cpu: "250m"

Comment trouver les bons chiffres :

# Voir l'utilisation réelle des pods
kubectl top pods -n production

Ou plus détaillé avec Prometheus :

# CPU utilisé par pod (95e percentile sur 7 jours)
quantile_over_time(0.95, rate(container_cpu_usage_seconds_total[5m])[7d:5m])

# Mémoire utilisée par pod (95e percentile)
quantile_over_time(0.95, container_memory_usage_bytes[7d:5m])

Process :

1. Déployer l'app avec requests génériques
2. Observer 1-2 semaines en production
3. Ajuster à 95e percentile + 20% headroom
4. Valider que ça tient en pic

Gain attendu : 25-35% de réduction de coûts rien qu'en right-sizing.

2. Namespace & resource quotas : fairness

Sans quotas, un service mal comporté peut consommer toutes les ressources du cluster.

apiVersion: v1
kind: Namespace
metadata:
  name: staging
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: staging-quota
  namespace: staging
spec:
  hard:
    requests.cpu: "10"           # max 10 CPU pour tout le namespace
    requests.memory: "20Gi"      # max 20 GB RAM
    limits.cpu: "20"
    limits.memory: "40Gi"
    pods: "100"
    persistentvolumeclaims: "5"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: staging-limits
  namespace: staging
spec:
  limits:
  - type: Pod
    max:
      cpu: "2"
      memory: "2Gi"
    min:
      cpu: "10m"
      memory: "10Mi"
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"

Maintenant, chaque équipe sait son budget. Les devs ne peuvent pas accidentellement réserver 1000 CPU.

Gain : 5-10% (surtout prévention de bleeders).

3. Spot instances : le risque calculé

Sur AWS, une instance spot coûte 60-90% moins cher qu'une instance on-demand. Le compromis : AWS peut la killer avec 2 min de notice.

Bon pour : batch jobs, workloads stateless, environnements non-prod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: batch-processor
spec:
  replicas: 10
  template:
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            preference:
              matchExpressions:
              - key: karpenter.sh/capacity-type
                operator: In
                values: ["spot"]      # Préférer spot
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
      tolerations:
      - key: karpenter.sh/do-not-evict
        operator: Equal
        value: "false"
      containers:
      - name: processor
        image: my-processor:1.0
        resources:
          requests:
            cpu: "1"
            memory: "1Gi"

Outil recommandé : Karpenter (AWS) ou Spot (GCP) qui gère le cycle spot automatiquement.

Gain : 20-40% pour workloads batch. 0% pour production critique.

4. Auto-scaling horizontal et vertical

Horizontal Pod Autoscaling (HPA) : ajouter des pods quand charge augmente.

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

Vertical Pod Autoscaling (VPA) : ajuster les requests/limits au fil du temps.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  updatePolicy:
    updateMode: "Auto"    # Redémarrer le pod avec nouvelles ressources
  resourcePolicy:
    containerPolicies:
    - containerName: api
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 2
        memory: 2Gi

Gain : 10-20% avec HPA bien configuré.

5. Idle resource cleanup

Des pods/services dead depuis 3 mois qui tournent gratuitement ? Soyez agressif.

# Trouver les deployments avec 0 replicas depuis X jours
kubectl get deployments -A -o json | \
  jq '.items[] | select(.spec.replicas==0) | .metadata.name'

# Supprimer les PVCs orphelins
kubectl get pvc -A -o json | \
  jq '.items[] | select(.status.phase=="Available")'

Ou via policy : "Si pas de traffic depuis 30 jours, delete."

Gain : 5-15% (dépend du housekeeping).

Cost allocation : backcharging

Une fois les coûts réduits, allouez-les par équipe. Cela crée une accountability naturelle.

# Le coût de ce pod est attribué à l'équipe "backend"
apiVersion: v1
kind: Pod
metadata:
  name: api-v2
  namespace: production
  labels:
    app: api
    team: backend
    cost-center: "CC-1234"
    environment: production

Alors kubecost affichera :

Team: backend
  - api deployment:    $1,234/mois
  - database pod:      $2,456/mois
  Total: $3,690/mois

Team: frontend
  - web deployment:    $567/mois
  Total: $567/mois

Les CTO/DSI veulent voir "$3,690/mois" pour chaque team. Ça crée de la pression pour optimiser.

Dashboards de suivi des coûts : ce qu'il faut afficher

Un dashboard FinOps efficace ne se contente pas de montrer des chiffres. Il doit raconter une histoire que chaque stakeholder comprend.

Pour le CTO/DSI -- vue stratégique :

• Coût total mensuel avec tendance sur 6 mois (le CFO veut voir la courbe descendre)
• Coût par environnement (production vs staging vs dev) -- le staging oublié est souvent le premier poste de gaspillage
• Ratio coût/revenu par service : combien coûte l'infrastructure de votre API qui génère CHF 500k/mois ?

Pour les tech leads -- vue opérationnelle :

• Top 10 des pods les plus coûteux avec leur taux d'utilisation réel
• Alertes de dépassement de budget par namespace (seuil à 80% et 100%)
• Recommandations de right-sizing automatiques générées par kubecost ou VPA

Pour le CFO -- vue financière :

• Prévision de dépenses à 3 mois basée sur la tendance actuelle
• Économies réalisées depuis le début du programme FinOps (cumul)
• Comparaison avec le budget prévu : êtes-vous on-track ou en dérive ?

Configurez ces dashboards dans Grafana en connectant kubecost comme source de données. Planifiez un envoi automatique par email chaque lundi matin aux stakeholders concernés. La visibilité régulière est le meilleur moteur de changement comportemental.

Gouvernance FinOps : pérenniser les gains

Optimiser une fois ne suffit pas. Sans gouvernance, les économies se résorbent en 6 mois.

Revue mensuelle obligatoire. Chaque mois, réunissez les tech leads pendant 30 minutes pour passer en revue les coûts par équipe. Affichez les recommandations kubecost, identifiez les dérives, assignez des actions. Cette cadence courte empêche les petites dérives de devenir des gouffres.

Politique de TTL (Time-to-Live). Tout environnement non-production doit avoir une date d'expiration. Les namespaces de test, de staging temporaire, de démo client : s'ils n'ont pas été utilisés depuis 30 jours, ils sont supprimés automatiquement. Implémentez cela avec un CronJob Kubernetes qui vérifie les labels de date de création.

Budget par équipe avec alertes. Allouez un budget cloud mensuel à chaque équipe et configurez des alertes à 80% et 100% du seuil. Les équipes qui dépassent systématiquement doivent justifier et obtenir une approbation avant d'augmenter leur allocation. Cette contrainte pousse naturellement à l'efficacité.

Le full impact : 40% de réduction

Regardez les gains combinés :

En conservateur, vous visez 40%. Ça veut dire :

• Facture de $100k/mois → $60k/mois
• Économies de $40k/mois = $480k/année

Pour une PME de 500 personnes, c'est notable.

Roadmap 3 mois

Semaine 1-2 : Installer kubecost, exporter les données actuelles, établir la baseline.

Semaine 3-6 : Right-sizing : observer l'utilisation réelle, ajuster les requests/limits.

Semaine 7-8 : Quotas par namespace, LimitRanges.

Semaine 9-10 : HPA pour services criticaux.

Semaine 11-12 : Spot instances (si AWS/GCP), cleanup des ressources idle.

Outcome : Réduction de 30-40% validée par les chiffres.

Conclusion

FinOps n'est pas une technique. C'est une mentalité d'efficacité opérationnelle.

Les trois points clés :

1. Visibility : vous ne pouvez pas optimiser ce que vous ne mesurez pas
2. Right-sizing : c'est la 80/20 du gain
3. Accountability : les équipes responsables de leurs coûts optimisent naturellement

Si vous avez besoin d'aide, Hidora propose des audits FinOps et support à long terme sur l'optimisation continue.

À lire aussi :

• Cloud cost optimisation pour les CTO
• Comment choisir son MSP DevOps : guide pour DSI

Cet article vous a été utile ? Découvrez comment Hidora peut vous accompagner : Professional Services · Managed Services · SLA Expert