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 PodDisruptionBudget pour les maintenances, l'anti-affinité pour la dispersion des répliques, les sondes pour rendre visible le cycle de vie des Pods, et les requests et limits pour une planification 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 à la planification. Les limits plafonnent la consommation. Un Pod sans requests peut être évincé à tout moment dès qu'une pression mémoire apparaît sur le nœud.

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

Pour aller plus loin

SRE et exploitation Kubernetes : Les SLO, les runbooks et l'industrialisation de ces pratiques de fiabilité.
Routine d'exploitation : Le rythme quotidien, hebdomadaire et mensuel qui tient ce niveau de fiabilité.