Kubernetes en production : les pièges que personne ne vous dit

Les tutoriels Kubernetes montrent rarement les problèmes qu’on ne voit qu’en production : les nœuds qui évincent des pods au mauvais moment, le DNS qui dépasse sa limite de connexions, les déploiements en rolling update qui coupent du trafic. Voici les pièges les plus courants et leurs solutions.

1. Les pods évincés à cause du manque de requests

Sans requests définis, Kubernetes classe les pods en BestEffort — les premiers à être évincés quand un nœud manque de ressources. En production, un nœud peut manquer de mémoire lors d’un pic de charge et évincer vos pods applicatifs pour libérer de l’espace.

# ❌ Sans resources : pod BestEffort, premier à être évincé
containers:
  - name: api
    image: myapp:1.0

# ✅ Avec resources : pod Burstable ou Guaranteed
containers:
  - name: api
    image: myapp:1.0
    resources:
      requests:
        memory: "256Mi"
        cpu: "250m"
      limits:
        memory: "512Mi"
        cpu: "500m"

2. Les rolling updates qui coupent du trafic

Par défaut, un rolling update démarre un nouveau pod et arrête l’ancien dès que le nouveau est “Ready”. Si le readiness probe devient vert trop vite (avant que l’application soit vraiment prête), des requêtes arrivent sur un pod pas encore opérationnel.

spec:
  readinessProbe:
    httpGet:
      path: /health/ready    # vérifier que l'app est vraiment prête
      port: 8080
    initialDelaySeconds: 30  # attendre 30s avant le premier check
    periodSeconds: 10
    failureThreshold: 3
    successThreshold: 1

  # S'assurer qu'un pod gère ses connexions avant d'arrêter
  lifecycle:
    preStop:
      exec:
        command: ["/bin/sh", "-c", "sleep 10"]  # laisser le temps aux connexions de drainer
  terminationGracePeriodSeconds: 60

3. PodDisruptionBudget : protéger la disponibilité lors des maintenances

Sans PDB, lors d’un kubectl drain node (maintenance nœud), Kubernetes peut terminer plusieurs pods du même Deployment simultanément — causant une coupure de service.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  selector:
    matchLabels:
      app: api
  minAvailable: 2   # toujours au moins 2 pods disponibles (même pendant un drain)
  # ou : maxUnavailable: 1

4. Le DNS CoreDNS surchargé

Sur les clusters à fort trafic, CoreDNS peut devenir un goulot d’étranglement — chaque résolution DNS passe par lui. L’erreur la plus courante : des applications qui résolvent le DNS dans chaque requête HTTP au lieu de cacher les résultats.

# Scaler CoreDNS horizontalement
kubectl scale deployment coredns --replicas=4 -n kube-system

# Activer NodeLocal DNSCache — résolution DNS en local sur chaque nœud
# Réduit la charge CoreDNS de 60-80% sur les gros clusters

5. Pas de topologySpreadConstraints

Sans contraintes de topologie, Kubernetes peut scheduler tous vos pods sur le même nœud ou dans la même zone — un seul nœud down impacte tout.

spec:
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: DoNotSchedule
      labelSelector:
        matchLabels:
          app: api
    - maxSkew: 2
      topologyKey: kubernetes.io/hostname
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          app: api

Notre formation Kubernetes couvre ces problèmes de production avec des ateliers sur des clusters réels.