Les coulisses de Kubernetes : du "ça tourne" à "prêt pour la prod"

On connaît tous cette sensation. L’application fonctionne parfaitement en local sur Docker. On la conteneurise, on lance un cluster Kubernetes, et voilà : c’est « déployé ». Le CTO est content. L’équipe célèbre.

Puis la réalité s’impose.

Le cluster qui a permis de faire tourner l’application n’est pas le même que celui qui supporte des utilisateurs réels, des données sensibles et des incidents à 3 heures du matin.

Pourquoi « tourner sur Kubernetes » ne suffit pas

La vérité est simple : un cluster de développement et un cluster de production n’ont presque rien en commun, à part l’orchestrateur lui-même.

En développement, on trouve souvent :

• des clusters locaux avec minikube
• des certificats autosignés valables uniquement sur la machine
• des domaines fictifs comme *.127.0.0.1.nip.io
• des identifiants codés en dur dans des variables d’environnement
• des commandes helm install lancées à la main
• un monitoring « qu’on fera plus tard »
• des sauvegardes jamais testées

En production, il faut répondre à d’autres questions :

• Comment déployer sans intervention humaine ?
• Où stocker les secrets et qui y a accès ?
• Que se passe-t-il si le stockage tombe en panne ?
• Peut-on restaurer les données en cas de sinistre ?
• Respecte-t-on les règles de sécurité ?
• Détecte-t-on les problèmes avant que les utilisateurs ne s’en rendent compte ?

Ce ne sont pas des options. Ce sont les conditions pour que l’application devienne un outil dont l’entreprise dépend.

Un parcours en cinq étapes

Transformer un setup de développement en plateforme exploitable suit une logique claire. On ne code pas de nouvelles fonctionnalités. On construit de la maturité opérationnelle.

Phase 1 : Poser les bases

Il faut d’abord faire fonctionner les composants fondamentaux dans des conditions réalistes :

• Utiliser des noms de domaine réels
• Connecter un fournisseur d’identité (OIDC ou SAML)
• Sortir les données persistantes du cluster (bases de données, stockage objet)
• Gérer les secrets sans les stocker dans des fichiers YAML

Ce travail est invisible. Il ne se voit pas dans une démo. Mais sans lui, tout le reste reste fragile.

Phase 2 : Faire fonctionner le produit

Une fois l’infrastructure stable, l’application doit s’adapter à elle :

• Les flux d’authentification doivent être complets
• Les uploads doivent se stocker durablement
• Le caching ne doit pas tomber en panne
• L’Ingress doit gérer des volumes de trafic réels

À ce stade, on découvre souvent que le setup de développement reposait sur des hypothèses qui ne survivent pas à la production.

Phase 3 : Contrôler les changements

Le manuel helm install devient un risque. On doit maintenant :

• Appliquer les principes de GitOps : l’état du cluster vit dans Git
• Valider automatiquement chaque déploiement
• Garder une trace de chaque modification
• Pouvoir revenir en arrière facilement

GitOps n’est pas seulement une question de confort. Il donne une sécurité réelle.

Phase 4 : Rendre la récupération possible

C’est ici que beaucoup d’équipes échouent. Elles pensent avoir des sauvegardes… jusqu’à ce que le temps de les tester.

Un backup sans test de restauration n’est pas un backup.

Production-ready signifie :

• Sauvegardes automatiques régulières
• Procédures de restauration testées régulièrement
• Objectives claires de RTO/RPO
• Procédures documentées, indépendantes d’une seule personne

Phase 5 : Voir ce qui se joue

Enfin, on doit savoir ce qui est réellement en cours :

• Métriques de performance et de ressource
• Tableaux de bord lisbar