Les secrets d'une gestion efficace de Kubernetes sur le cloud
Introduction
Gérer Kubernetes efficacement sur le cloud, c'est un art qui se perfectionne avec l'expérience -- et les erreurs. Après avoir opéré des clusters sur 6 providers cloud différents (AWS EKS, GCP GKE, Azure AKS, Scaleway Kapsule, OVH Managed Kubernetes, Outscale), j'ai accumulé des pratiques qui font la différence entre un cluster qui fonctionne et un cluster qui fonctionne bien : performant, économique et résilient. Voici les cinq piliers que j'applique systématiquement chez mes clients.
Le rightsizing : l'économie commence par les requests
Le premier secret est le dimensionnement correct des ressources, et c'est aussi le levier d'économie le plus rapide. Chez F2R2, l'audit initial de 15 jours a révélé que 40% des pods étaient oversizés : ils demandaient 1 Go de RAM en resource request mais n'en utilisaient que 200 Mo en pic de charge. Le scheduler Kubernetes réservait 1 Go par pod sur les noeuds, et cette mémoire réservée mais inutilisée empêchait le provisionnement de nouveaux pods sans ajouter de noeuds.
J'ai déployé le VPA (Vertical Pod Autoscaler) en mode "recommend" (pas en mode "auto" -- trop risqué en production au début) pendant 2 semaines. Le VPA a analysé la consommation réelle de chaque pod et proposé des requests optimales. En ajustant les requests sur la base de ces recommandations (avec une marge de 20% pour absorber les pics), on a libéré suffisamment de ressources pour supprimer 2 noeuds sur 6. Economie : 33% sur la facture compute, soit plusieurs centaines d'euros par mois. Chez Bloomflow, je faisais cette revue trimestriellement en croisant les données Prometheus (actual usage) avec les Helm values (requested resources).
La gouvernance multi-namespace : isoler sans cloisonner
Chez Padam Mobility, chaque environnement (dev, staging, production) avait son namespace Kubernetes avec des ResourceQuotas soigneusement calibrés. Le namespace dev avait un quota de 4 CPU et 8 Go de RAM -- suffisant pour les tests, mais pas assez pour qu'un développeur qui lance un kubectl apply mal configuré asphyxie le cluster. Le staging avait 8 CPU et 16 Go. La production n'avait pas de limite explicite mais des alertes budget qui notifiaient si la consommation dépassait le seuil prévu.
Les LimitRanges définissaient des valeurs par défaut pour les pods qui n'avaient pas de requests/limits spécifiées : 100m CPU et 256 Mo de RAM par défaut, avec un maximum de 2 CPU et 4 Go par conteneur. Cette gouvernance empêchait un scénario que j'avais vécu chez un client précédent : un développeur avait lancé un pod de test qui consommait 16 Go de RAM, ce qui avait évicté les pods de production par pression mémoire sur le noeud. Chez KNDS, les ResourceQuotas étaient complétés par du RBAC : chaque équipe ne pouvait déployer que dans son namespace, avec des roles limités aux opérations nécessaires.
Backups et résilience : préparer le pire
Un cluster Kubernetes managé sauvegarde le control plane (la base etcd, les certificats), mais pas vos données applicatives ni vos manifestes custom. Chez Coopengo (HDS), les bases PostgreSQL hébergées sur des PersistentVolumes EBS étaient sauvegardées quotidiennement avec Velero. Les snapshots étaient répliqués dans une autre région AWS (eu-west-1 vers eu-central-1) pour la disaster recovery -- une exigence HDS. Le RPO (Recovery Point Objective) était de 24h, le RTO (Recovery Time Objective) de 4h.
Chez Bloomflow, Velero sauvegardait aussi les manifestes Kubernetes eux-mêmes : Deployments, ConfigMaps, Secrets (chiffrés), CRDs, et les External Secrets. Cette sauvegarde permettait de reconstruire un namespace complet sur un nouveau cluster en cas de catastrophe. Un test de restauration était effectué le premier lundi de chaque mois : on restaurait un namespace de staging à partir du backup de production, on vérifiait que l'application fonctionnait, puis on le supprimait. En 5 ans, ce test a détecté 3 fois un problème dans le processus de backup (un CRD manquant, un secret non chiffré correctement, un volume non inclus). Sans ces tests mensuels, on aurait découvert ces problèmes le jour du sinistre.
Le monitoring qui anticipe les problèmes
La stack que je déploie systématiquement sur chaque cluster client : Prometheus pour les métriques (pods, noeuds, réseau, latences applicatives), Grafana pour la visualisation (dashboards pré-configurés par namespace et par service), et Loki pour les logs (centralisés et requêtables). Le tout déployé via Helm Charts Terraform pour être reproductible.
Chez Metronome sur OVH Cloud, les dashboards Grafana montraient par namespace : l'utilisation CPU/mémoire réelle vs demandée (le ratio révèle le gaspillage ou le sous-provisionnement), les restart counts par pod (un pod qui redémarre souvent a un problème de stabilité -- OOMKill, probe failure, crash applicatif), la latence des requêtes par service (P50, P95, P99 -- le P99 est le plus révélateur), et les erreurs HTTP 5xx. Chez Bloomflow, OpenTelemetry ajoutait le tracing distribué, indispensable pour diagnostiquer les latences dans l'architecture de 30+ microservices. Un dashboard Grafana montrait le "flame graph" de chaque requête à travers les services, permettant d'identifier en 30 secondes le service responsable d'un ralentissement.
L'automatisation de la maintenance : réduire l'effort humain
La maintenance Kubernetes doit être automatisée autant que possible pour réduire la charge opérationnelle et les erreurs humaines. Chez KNDS, le dispositif d'automatisation était complet : les mises à jour mineures du cluster OVH étaient planifiées et d'abord appliquées sur le cluster staging le mardi, puis validées, puis appliquées en production le jeudi. Les certificats TLS étaient renouvelés automatiquement par cert-manager sans aucune intervention (un Let's Encrypt qui expire silencieusement, c'est un incident classique que je ne veux plus voir). Les secrets étaient synchronisés automatiquement depuis OKMS par External Secrets Operator.
Les images Docker étaient mises à jour par Renovate dans les Helm values : chaque semaine, Renovate ouvrait des PRs pour les nouvelles versions des images de base (Alpine, Node, Python), la CI les testait automatiquement, et un lead tech approuvait le merge. ArgoCD détectait le changement et déployait. Ce niveau d'automatisation a réduit la charge opérationnelle de maintenance Kubernetes à environ 3 heures par semaine, contre 15 heures dans une gestion manuelle classique.
Conclusion
Gérer efficacement Kubernetes sur le cloud repose sur cinq piliers interdépendants : rightsizing des ressources (33% d'économies chez F2R2), gouvernance multi-namespace (isolation sans cloisonnement), backups testés mensuellement (Velero + réplication cross-region), monitoring proactif (Prometheus + Grafana + Loki) et automatisation de la maintenance (Renovate + ArgoCD + cert-manager). Ces pratiques, affinées sur des dizaines de clusters en production sur 6 providers cloud, transforment Kubernetes d'un outil complexe en une plateforme fiable et économique.