Fiabiliser les applications Kubernetes en production

Un déploiement Kubernetes fonctionne en dehors des incidents, mais résiste-t-il vraiment à une maintenance, une saturation de nœud ou un pic de charge ? Fiabiliser, c’est configurer le cluster et les workloads pour que la disponibilité soit garantie structurellement — pas par chance.

Quatre mécanismes couvrent l’essentiel de la fiabilité applicative : les PodDisruptionBudgets pour les maintenances, l’anti-affinité pour la dispersion des réplicas, les probes pour la bonne visibilité du cycle de vie des pods, et les requests/limits pour le scheduling stable.

Les 4 piliers de la disponibilité applicative

1. PodDisruptionBudget (PDB)

Garantit que Kubernetes ne supprime pas plus d’un certain nombre de pods lors d’une opération volontaire (drain, mise à jour).

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: mon-app-pdb
spec:
  minAvailable: 2       # ou maxUnavailable: 1
  selector:
    matchLabels:
      app: mon-app

2. Anti-affinité

Empêche plusieurs réplicas d’un même déploiement d’être placés sur le même nœud — une défaillance nœud n’emporte pas toute l’application.

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: mon-app
        topologyKey: kubernetes.io/hostname

3. Probes de santé

Readiness : Kubernetes ne route le trafic vers un pod que s’il est prêt à traiter des requêtes.
Liveness : Kubernetes redémarre un pod bloqué (deadlock, OOM silencieux).
Startup : évite les faux positifs de liveness au démarrage lent.

4. Requests et Limits

Les requests définissent les ressources garanties au scheduling. Les limits plafonnent la consommation. Un pod sans requests peut être évincé à tout moment lors d’une pression mémoire.

Guides de cette section

Disponibilité applicative sur Kubernetes PodDisruptionBudget, anti-affinité, probes : le guide complet pour garantir la continuité de service.

1 guide publié 3 à venir

À retenir

Sans PDB, un kubectl drain peut tuer tous vos réplicas si le cluster manque de capacité
Sans anti-affinité, tous vos pods peuvent atterrir sur le même nœud — votre déploiement tient sur un seul point de défaillance
Sans readiness probe, Kubernetes route du trafic vers un pod qui n’est pas encore prêt
Sans requests, le scheduler ne peut pas garantir les ressources nécessaires — les évictions sont imprévisibles
La combinaison PDB + anti-affinité + probes + requests couvre l’essentiel de la résilience sans infrastructure supplémentaire

Prochaines étapes

SRE et exploitation Kubernetes Routine d'exploitation, runbooks, SLO/SLI : industrialiser l'exploitation au quotidien.

Maintenance et changements Cordon, drain, mise à jour : intervenir sur le cluster sans interruption de service.