Découverte de Kubernetes : l'orchestrateur de containers ultime
Introduction
Kubernetes a gagné le titre d'orchestrateur ultime, et ce n'est pas un hasard. En le pratiquant quotidiennement depuis 2017, d'abord comme PoC chez SFR Business Team puis en production critique chez KNDS, Bloomflow, Coopengo, Okeiro et F2R2, j'ai pu mesurer son impact sur la gestion des applications conteneurisées. J'ai opéré des clusters sur 6 providers cloud différents (AWS, GCP, Azure, Scaleway, OVH, Outscale), avec des contraintes allant de la défense nationale à la santé réglementée. Voici pourquoi Kubernetes mérite ce titre, avec les situations concrètes qui l'ont prouvé.
L'orchestration qui absorbe la complexité
Chez Bloomflow, pendant mes 5 ans en CDI, on gérait plus de 30 microservices en production sur un cluster Kubernetes multi-providers (AWS, Outscale, OVH selon les clients). Sans Kubernetes, chaque déploiement aurait été un casse-tête de coordination : quelle version de chaque service est compatible avec quelle autre, comment router le trafic pendant la mise à jour, comment gérer les pannes. Avec K8s, chaque service a son Deployment avec ses probes de readiness et liveness, son HPA (Horizontal Pod Autoscaler) pour scaler automatiquement, et le tout est orchestré sans intervention humaine.
Un exemple concret : un mercredi matin, un pod du service de paiement s'est mis à OOM-kill (dépassement mémoire) à cause d'un bug de fuite mémoire. Kubernetes a automatiquement redémarré le pod 3 fois en 5 minutes, puis l'a marqué en CrashLoopBackOff. L'alerte Prometheus a notifié l'équipe en 30 secondes. Pendant ce temps, les 2 autres replicas du service continuaient à servir le trafic. L'utilisateur n'a rien vu. Sans Kubernetes, sur une architecture traditionnelle avec un seul serveur, c'aurait été un incident de production avec un impact client direct.
Les managed services : le choix rationnel
Chez F2R2, j'ai déployé EKS Fargate sur AWS : chaque pod tourne dans sa propre microVM Firecracker, isolation totale, pas de noeuds à gérer. Chez Okeiro, GKE Autopilot sur le cloud souverain S3NS pour la conformité HDS : Google gère les noeuds, on ne gère que les workloads. Chez Metronome, Kubernetes managé sur OVH Cloud, un bon compromis coût/fonctionnalités pour une startup. Chez Cardiologs, AKS sur Azure, intégré avec leur écosystème Microsoft et Datadog.
Mon conseil après avoir opéré sur 6 providers : sauf besoin très spécifique (air-gapped, latence ultra-faible, hardware custom), utilisez un service Kubernetes managé. La gestion du control plane -- mises à jour de l'API server, haute disponibilité etcd, rotation des certificats, backups du state -- est un travail à plein temps qui nécessite une expertise pointue. Les managed services l'éliminent et vous laissent vous concentrer sur vos workloads, c'est-à-dire sur votre valeur ajoutée. Chez Bloomflow, cette décision nous a fait économiser l'équivalent d'un poste d'ingénieur SRE à temps plein.
L'écosystème qui étend la puissance
L'écosystème Kubernetes a explosé depuis que je l'utilise. Les Operators automatisent la gestion des applications stateful (bases de données, queues, caches). Les CRDs (Custom Resource Definitions) étendent le modèle de données de K8s pour vos propres ressources. Les service meshes (Istio, Linkerd) gèrent le trafic inter-services avec mTLS, circuit breaking et observabilité.
Chez Bloomflow, on utilisait External Secrets Operator (pour synchroniser les secrets depuis HashiCorp Vault), cert-manager (pour les certificats TLS automatiques via Let's Encrypt), et un operator custom que j'avais développé pour les environnements éphémères de PR (un merge créait un namespace complet avec base de données et services, un close de PR le détruisait). Chez WizOps.fr, le Helm Chart utilise cert-manager avec un ClusterIssuer Scaleway pour le renouvellement automatique des certificats TLS. L'écosystème K8s n'est pas juste un orchestrateur de conteneurs, c'est une plateforme extensible qui s'adapte à votre contexte.
Kubernetes pour les petits projets : la preuve par WizOps
On pense souvent que K8s n'est que pour les gros projets avec 50 microservices. C'est une idée reçue que je combats régulièrement. WizOps.fr -- un site vitrine avec un frontend Nuxt et un backend Django -- tourne sur Kubernetes Scaleway. Le Helm Chart est simple et lisible : 2 Deployments, 2 Services, 1 Ingress NGINX, 1 ExternalSecret pour les credentials Docker. Le coût mensuel est comparable à deux VPS chez n'importe quel hébergeur.
Mais les avantages sont incomparables : auto-healing (si un pod crashe, K8s le redémarre en 10 secondes), rolling update sans downtime (le déploiement met à jour les pods un par un, en vérifiant la santé de chaque nouveau pod avant de supprimer l'ancien), et TLS automatique via cert-manager. Pour WizStatus.com, WizArmor.com et MongoAdmin.dev -- les produits de l'écosystème WizOps -- Kubernetes offre la même infrastructure de qualité production sans surcoût opérationnel. Un seul cluster, plusieurs namespaces, des Helm Charts réutilisables.
Les pièges que je vois encore en 2025
Après des dizaines de clusters opérés sur 8 ans, voici les erreurs que je rencontre encore chez mes nouveaux clients : ne pas définir de resource requests/limits (le cluster devient imprévisible : un pod gourmand peut asphyxier tous les autres), utiliser latest comme tag d'image Docker (déploiements non reproductibles : impossible de savoir quelle version tourne en production), négliger les NetworkPolicies (par défaut, tous les pods communiquent entre eux -- chez KNDS pour la Défense, c'était un no-go immédiat), et stocker les secrets en clair dans les fichiers YAML versionnés dans Git.
Chez KNDS, j'ai implémenté les NetworkPolicies comme premier chantier : chaque pod ne peut communiquer qu'avec les services dont il a besoin, pas avec le reste du cluster. Les secrets sont gérés par External Secrets Operator connecté à OKMS (le service de gestion de clés OVH Cloud). Chez Bloomflow (ISO 27001), les mêmes principes avec Vault comme backend. Ces erreurs sont faciles à éviter mais coûteuses quand elles surviennent, surtout dans des contextes réglementés.
Conclusion
Kubernetes est l'orchestrateur ultime parce qu'il combine puissance d'orchestration, flexibilité multi-cloud, un écosystème extensible sans égal, et une capacité d'adaptation qui va du site vitrine (WizOps) aux architectures de 30+ microservices (Bloomflow). En 8 ans de pratique sur 6 providers cloud et des contextes aussi variés que la défense, la santé et le e-commerce, Kubernetes a toujours tenu ses promesses. Le temps investi dans l'apprentissage de K8s est un investissement dans la fiabilité de vos applications et dans votre carrière.