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.

La fiabilité s'anticipe

La plupart des incidents de disponibilité sont évitables. Ils surviennent parce que les sondes sont absentes, les requests non définies, ou les répliques toutes sur le même nœud. Ces trois réglages prennent quelques minutes et évitent des heures d'incident.

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

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À 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é.

×

📖 Voir la documentation →