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)
histogram_quantile(0.95, rate(container_cpu_usage_seconds_total[7d]))

# Mémoire utilisée par pod (95e percentile)
histogram_quantile(0.95, rate(container_memory_usage_bytes[7d]))

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.

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