0

Votre panier

TOTAL HT
TOTAL TTC
Payer
Retour

Le déploiement qui a mis 92% des requêtes en erreur — et la gate qui l'aurait évité

REXAutomatisationCI/CDMonitoring

10/12/2026 | 11h40 - 12h00

Description

Sur un cluster Kubernetes saturé, un simple rolling update a provoqué 92% d'erreurs et 13s de latence p95. On l'a mesuré, reproduit, puis bloqué avec 3 requêtes Prometheus dans Jenkins. REX chiffré, artefacts publics.

On avait un cluster Kubernetes "bien configuré" : HPA actif, rolling update avec maxSurge=1, readiness probes en place. Et pourtant, en conditions de charge réelle, un déploiement a suffi à faire s'effondrer le service à 92% d'erreurs HTTP et 13 secondes de latence p95.

Le problème, en vrai
Quand le HPA est déjà à maxReplicas, il ne peut plus rien faire. Un rolling update dégrade alors la capacité disponible au moment précis où le système a le moins de marge. Pour Magento (45 secondes pour passer la readiness probe), la fenêtre de vulnérabilité dure assez longtemps pour que les queues saturent et que les requêtes expirent en masse.

Ce qui nous a surpris : maxSurge=1, le réglage que tout le monde considère comme la protection contre ça, n'a rien changé. 92,4% d'erreurs sans maxSurge, 93,2% avec. À saturation, le pod surgissant ne sert pas encore de trafic pendant ses 45 secondes de démarrage — pendant lesquelles l'ancien pod commence déjà à se vider. Effet net sur la capacité effective : négatif.

Ce qu'on a mesuré
  • Scénario de base (HPA saturé, pas de déploiement) : < 1% d'erreurs — le cluster tient
  • Déploiement sous saturation, maxSurge=0 : 92,4% d'erreurs, p95 à 13,05s
  • Déploiement sous saturation, maxSurge=1 : 93,2% d'erreurs, p95 à 11,97s
  • Même cluster, même saturation, avec Nginx (démarrage en 1,8s) : 0,03% d'erreurs
Le seul paramètre qui change entre l'effondrement et la stabilité : le temps de démarrage de l'application.

La gate : 3 requêtes, 1 décision
On a ajouté une étape dans le pipeline Jenkins avant le kubectl rollout. Elle interroge Prometheus sur trois métriques : utilisation CPU agrégée du namespace, taux d'erreurs 5xx sur l'ingress, ratio replicas courants / maxReplicas. Si l'un des trois seuils est dépassé, le déploiement est bloqué.

Pas de dépendance supplémentaire : curl + jq, c'est tout.

Validation live sur le même cluster :
  • CPU à 1,73 cores → gate bloquée, kubectl ne s'exécute pas, zéro interruption de service
  • CPU à 0,09 cores → gate passée, déploiement effectué, zéro erreur
Ce que vous repartirez avec
  • Les 3 requêtes PromQL à copier dans votre pipeline aujourd'hui
  • Pourquoi maxSurge ne vous protège pas dans ce cas précis
  • Comment le ratio HPA (current/max replicas) est le signal le plus sous-utilisé en monitoring

Conférenciers