Déployer sur Kubernetes en démo est facile. Le faire tenir en production est une autre histoire. Voici les sept pièges qui reviennent le plus souvent, et qui coûtent en disponibilité, en facture cloud ou en sécurité.
1. Aucune limite de ressources définie
Sans requests et limits, un pod peut consommer toute la mémoire d’un nœud et faire tomber ses voisins. Définissez systématiquement des ressources : c’est la base de la stabilité d’un cluster.
2. Des probes mal configurées (ou absentes)
Sans liveness et readiness probes, Kubernetes ne sait pas si votre application est réellement prête ou bloquée. Résultat : du trafic envoyé vers des pods morts. Des probes bien réglées sont indispensables.
3. Tout faire tourner en latest
Utiliser le tag latest rend les déploiements non reproductibles. Vous ne savez plus quelle version tourne réellement. Taguez vos images avec des versions explicites.
4. Négliger le RBAC
Un cluster sans contrôle d’accès fin (RBAC) est une bombe à retardement. Appliquez le principe du moindre privilège : chaque service, chaque utilisateur n’a que les droits strictement nécessaires.
5. Pas de stratégie de mise à jour
Déployer sans rolling update configuré, c’est risquer une coupure à chaque release. Maîtrisez les stratégies (rolling, blue/green, canary) selon votre tolérance au risque.
6. Aucune observabilité
Sans métriques ni logs centralisés, diagnostiquer un incident devient un cauchemar. Prometheus et Grafana ne sont pas optionnels en production.
7. Ignorer la gestion d’état
Lancer une base de données dans un pod sans StatefulSet ni volume persistant, c’est perdre ses données au premier redémarrage. Distinguez clairement charges sans état et avec état.
Le dénominateur commun
Ces pièges viennent presque toujours d’un passage trop rapide de la démo à la production, sans comprendre les mécanismes sous-jacents. Notre formation Kubernetes consacre une part importante à l’exploitation réelle : RBAC, ressources, observabilité et stratégies de déploiement.