What really breaks moving from containers to managed Kubernetes
Context & constraints
Application conteneurisée en production, montée en charge attendue, migration des pods menée pendant le projet et non après.
Options considered
- 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
The decision
Migrer pendant le projet
RationaleUne migration sous incident coûte trois fois plus cher qu'une migration planifiée.
Accepted consequenceDes semaines de charge supplémentaires sur un planning déjà tendu.
What broke
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.
The outcome
- Bascule sans interruption de service
- Comportement sous charge mesuré avec k6 avant mise en production
What I would do differently
Écrire les tests de charge avant la migration, pas après : ils servent alors de référence de comparaison.
Extended universe
Related questions
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