Ce qui casse vraiment quand on passe des conteneurs à Kubernetes managé
Contexte & contraintes
Application conteneurisée en production, montée en charge attendue, migration des pods menée pendant le projet et non après.
Les options envisagées
- Rester sur des conteneurs pilotés à la main : moins de concepts, pas de mise à l'échelle
- AKS : mise à l'échelle et redémarrage automatiques, courbe d'apprentissage réelle sur le réseau et les certificats
La décision
Migrer pendant le projet
MotifUne migration sous incident coûte trois fois plus cher qu'une migration planifiée.
Conséquence acceptéeDes semaines de charge supplémentaires sur un planning déjà tendu.
Ce qui a cassé
Les sondes de disponibilité calquées sur les sondes de vivacité : au premier ralentissement de la base, Kubernetes redémarrait des pods parfaitement sains. Et le renouvellement de certificat, oublié dans la procédure de bascule.
Le résultat
- Bascule sans interruption de service
- Comportement sous charge mesuré avec k6 avant mise en production
Ce que je referais autrement
Écrire les tests de charge avant la migration, pas après : ils servent alors de référence de comparaison.
L'univers étendu
Questions liées
Comment s'est passée la migration des pods sur AKS ?
Menée pendant le projet, pas après — une migration sous incident coûte trois fois plus cher. Ce qui a cassé : les sondes de disponibilité calquées sur les sondes de vivacité, qui faisaient redémarrer des pods sains au premier ralentissement de la base, et un renouvellement de certificat absent de la procédure de bascule. Les tests k6 ont servi de référence avant / après.
SourcesDocker → AKSEngie