L'Incident de 3 Heures du Matin
Il est 3 heures du matin un mardi. Un cluster de production est down. Le dashboard de monitoring montre tous les pods en crash loop. Quatre ingénieurs en visio, et personne n'arrive à comprendre pourquoi tout est mort en même temps.
Il s'avère que : l'équipe avait défini des resource limits, mais pas de resource requests. Quand un nouveau nœud s'est autoscalé, le scheduler n'avait aucune idée de comment distribuer les workloads. Il a tout entassé sur un seul nœud, qui est tombé en manque de mémoire, ce qui a déclenché une tempête d'évictions. En 90 secondes, le cluster est passé de "production stable" à "tout est en feu".
Voici cinq erreurs qui coûtent aux équipes du downtime, des clients frustrés, et des mois de travail non planifié lors d'une migration Kubernetes.
Erreur #1 : Traiter les Secrets Comme de la Config
Ce qu'on a fait : On a stocké les clés API et credentials de base de données dans des Kubernetes Secrets. On pensait être sécurisés parce que les Secrets sont "chiffrés au repos".
Ce qu'on a appris : Les Kubernetes Secrets(lien externe, nouvel onglet) sont encodés en base64 par défaut. Ce n'est pas du chiffrement. N'importe qui avec un accès cluster peut les décoder avec une commande.
Quand on a passé un audit de sécurité, l'auditeur a demandé : "Où est votre politique de rotation des secrets ?" On n'en avait pas. Parce que les Kubernetes Secrets sont des fichiers, pas des credentials managés. Quand vous devez faire tourner une clé, vous devez mettre à jour le Secret, redéployer chaque pod qui l'utilise, et espérer que rien ne casse.
Ce qu'on aurait dû faire : Intégrer Azure Key Vault(lien externe, nouvel onglet) dès le jour 1. Kubernetes supporte les secret stores externes via le driver Secrets Store CSI(lien externe, nouvel onglet). Vos pods récupèrent les credentials à runtime depuis un vrai gestionnaire de secrets. La rotation est gérée par Azure. Les credentials ne touchent jamais votre cluster.
Si on avait configuré ça avant la migration, on aurait économisé deux semaines à le retrofitter plus tard — un exemple typique de la façon dont la dette technique s'accumule quand on reporte le travail ingrat.
Erreur #2 : Pas de Stratégie de Rollback
Ce qu'on a fait : On déployait de nouvelles versions avec kubectl apply -f deployment.yaml. Si quelque chose cassait, on revertait frénétiquement le YAML et on redéployait.
Ce qu'on a appris : Ce n'est pas un rollback. C'est de l'opération en mode panique.
Incident typique : un déploiement casse l'authentification utilisateur. Il faut 8 minutes pour le réaliser, 4 minutes pour trouver la version précédente du YAML dans Git, et 6 minutes de plus pour redéployer. Downtime total : 18 minutes. Pour une feature censée prendre 5 minutes à déployer.
Le pire ? Kubernetes a des rollbacks intégrés. On ne les utilisait juste pas.
Ce qu'on aurait dû faire : Utiliser kubectl rollout(lien externe, nouvel onglet) depuis le début. Chaque déploiement est versionné. Si quelque chose casse, vous lancez kubectl rollout undo deployment/my-app et vous revenez à la version stable précédente en secondes.
Encore mieux : utiliser Helm ou Argo CD, qui rendent les rollbacks en un clic. Mais au minimum, apprenez les commandes rollout avant de déployer quoi que ce soit en production.
Erreur #3 : Ignorer les Resource Requests et Limits
Ce qu'on a fait : On a défini des memory et CPU limits sur nos pods ("n'utilise pas plus de 512MB"). On a sauté les resource requests ("je promets d'utiliser au moins X").
Ce qu'on a appris : Les requests sont plus importantes que les limits.
Les requests(lien externe, nouvel onglet) disent au scheduler Kubernetes de combien de capacité un pod a besoin. Si vous ne définissez pas de requests, le scheduler suppose que votre pod n'a besoin de zéro ressource. Donc il pourrait entasser 50 pods sur un nœud. Ce nœud tombe en manque de mémoire. Les pods commencent à être tués. Le chaos s'ensuit.
Des limits sans requests, c'est comme avoir une limitation de vitesse mais pas de route. Certes, vous n'irez pas plus vite que 100 km/h. Mais si 10 voitures essaient d'utiliser la même voie, vous aurez quand même un carambolage.
Ce qu'on aurait dû faire : Définir les requests d'abord, basées sur l'utilisation réelle des ressources. Lancez votre app en staging, regardez les métriques, et définissez les requests au 90e percentile. Ensuite définissez des limits légèrement plus hautes (peut-être 1,5x la request). Cela garantit que le scheduler place vos pods sur des nœuds qui peuvent réellement les gérer.
Erreur #4 : Déployer Avant Que le Monitoring Soit Prêt
Ce qu'on a fait : On a migré 12 microservices vers Kubernetes. Deux semaines plus tard, on a configuré Prometheus et Grafana.
Ce qu'on a appris : Vous volez à l'aveugle sans observabilité.
Pendant ces deux premières semaines, on n'avait aucune idée si les services étaient sains. On ne pouvait pas voir les fuites mémoire. On ne pouvait pas tracker la latence des requêtes. On savait seulement que quelque chose était cassé quand les utilisateurs se plaignaient.
Un service avait une fuite mémoire qui doublait l'utilisation RAM toutes les 6 heures. L'équipe ne l'a détecté qu'à la troisième panne. Avec du monitoring dès le jour 1, le pattern aurait été visible immédiatement.
Ce qu'on aurait dû faire : Configurer Prometheus(lien externe, nouvel onglet), Grafana(lien externe, nouvel onglet) et Loki(lien externe, nouvel onglet) avant de migrer les services en production. Traitez l'observabilité comme un prérequis, pas comme un nice-to-have.
Vous n'avez pas besoin d'un dashboard parfait. Vous avez besoin de :
- L'utilisation CPU et mémoire des pods
- La latence des requêtes (p50, p95, p99)
- Les taux d'erreur
- Des logs qu'on peut chercher
Si vous ne pouvez pas répondre à "Ce service est-il en bonne santé ?" en moins de 10 secondes, votre observabilité n'est pas assez bonne.
Erreur #5 : Personne Ne Savait Utiliser kubectl
Ce qu'on a fait : Un ingénieur a mené la migration — le seul à avoir utilisé Kubernetes auparavant. Tout le monde apprenait au fil de la mise en œuvre.
Ce qu'on a appris : Quand l'ingénieur d'astreinte ne peut pas débugger un pod en échec parce qu'il ne connaît pas les commandes kubectl, votre migration a un problème humain, pas un problème technique.
Trois semaines après la mise en production, une astreinte à 2 heures du matin. L'ingénieur d'astreinte ne pouvait pas redémarrer un pod. Pas parce que c'était un problème difficile — il ne connaissait juste pas la commande. Après avoir passé en revue kubectl delete pod, l'équipe a perdu 20 minutes à cause d'un gap de connaissance.
Ce qu'on aurait dû faire : Organiser des sessions de formation internes avant la migration. Enseigner à tout le monde kubectl get, kubectl logs, kubectl describe, kubectl exec. Organiser des game days où l'équipe pratique des scénarios d'échec courants.
Kubernetes n'est pas magique. Mais si votre équipe ne connaît pas les bases, chaque incident devient une escalade.
La Vraie Leçon
Ces erreurs n'étaient pas liées au fait que Kubernetes soit difficile. Elles étaient liées au fait qu'on avait sauté les fondamentaux parce qu'on était pressés — le même raccourci qui rend le fait de livrer vite sans fondations si dangereux.
On supposait que les Secrets étaient sécurisés. Ils ne le sont pas, par défaut. On supposait qu'on pouvait rollback facilement. On ne pouvait pas, jusqu'à ce qu'on apprenne les commandes. On supposait que le scheduler était intelligent. Il l'est — mais seulement si vous lui donnez les informations dont il a besoin.
Si vous planifiez une migration Kubernetes : ralentissez. Configurez le monitoring d'abord. Apprenez les commandes de rollback avant d'en avoir besoin. Et pour l'amour de l'uptime, utilisez un vrai gestionnaire de secrets.
La documentation vous apprendra comment déployer sur Kubernetes. L'expérience vous apprend comment le maintenir en fonctionnement.
