Kubernetes : L'automatisation réinventée pour le Cloud

Introduction

Kubernetes a transforme la gestion des infrastructures cloud d'une discipline reactive ("un serveur est en panne, je le repare") en une discipline declarative ("je declare l'etat desire, la plateforme s'en occupe"). Ayant opere des clusters sur 6 providers differents (OVH Cloud, AWS EKS, GKE, Azure AKS, Scaleway, Outscale), je mesure concretement ce que cette automatisation change au quotidien.

L'auto-healing : la feature qui justifie Kubernetes a elle seule

Le meilleur argument pour Kubernetes, c'est l'auto-healing. Un pod crashe : K8s le redemarre. Un noeud tombe : K8s redistribue les workloads. Ce n'est pas de la theorie, c'est du vecu.

Chez Metronome, un noeud OVH Cloud a subi une panne materielle un samedi matin. Le cluster comptait 4 noeuds avec une vingtaine de services repartis dessus. Les pods du noeud defaillant ont ete reschedules sur les 3 noeuds restants en moins d'une minute. Personne n'a ete alerte, personne n'est intervenu. Le dashboard Grafana a enregistre un pic de rescheduling et une augmentation temporaire de l'utilisation CPU sur les noeuds restants, puis tout s'est stabilise. Le lundi matin, on a constate la panne dans le dashboard et commande un noeud de remplacement.

Comparaison directe : chez SFR Business Team en 2016, sur Docker Swarm, une panne de noeud identique necessitait une intervention manuelle de 30 a 45 minutes. Identification du noeud, drain manuel, redemarrage des services, verification. Un samedi matin, ca signifiait un appel d'astreinte, du stress, et un temps de recovery beaucoup plus long.

Autoscaling : trois niveaux d'elasticite

Kubernetes propose un autoscaling a trois niveaux, et chez Bloomflow on les utilisait simultanement :

HPA (Horizontal Pod Autoscaler) : ajuste le nombre de pods. La configuration basique utilise le CPU, mais la vraie puissance vient des metriques custom Prometheus. Chez Bloomflow, le HPA de l'API principale scalait sur le nombre de requetes par seconde (via prometheus-adapter). Quand le trafic doublait apres une campagne marketing, les pods passaient de 3 a 8 en 90 secondes.

VPA (Vertical Pod Autoscaler) : ajuste les requests/limits des pods. En mode recommendation (le seul que j'utilise en production), il analyse l'utilisation reelle sur 7 jours et suggere des requests optimales. Chez F2R2, le VPA m'a permis de reduire les requests de 40% en moyenne, liberant de la capacite cluster pour d'autres workloads sans risque.

Cluster Autoscaler : ajuste le nombre de noeuds. Quand le scheduler ne peut plus placer de pods (requests totales > capacite), le Cluster Autoscaler ajoute des noeuds. Quand des noeuds sont sous-utilises, il les draine et les supprime. Chez Bloomflow, le scale-down automatique en heures creuses (nuit, week-end) reduisait la facture cloud de 25%.

La portabilite multi-cloud : un avantage commercial concret

L'abstraction applicative de Kubernetes m'a apporte un avantage commercial direct. Chez Bloomflow, on avait des clusters sur AWS, Outscale (SecNumCloud) et OVH Cloud. Les Helm Charts etaient identiques sur les trois providers. Seuls les values.yaml changeaient : StorageClass (gp3 sur AWS, csi-cinder-default sur OVH), annotations d'Ingress, type de LoadBalancer.

Quand un appel d'offres DGE a exige la certification SecNumCloud, on a deploye nos charts existants sur Outscale en 2 jours, sans modifier une seule ligne d'application. Sans Kubernetes, il aurait fallu recertifier et readapter chaque service pour le nouveau provider. La standardisation K8s a transforme une contrainte reglementaire en exercice routinier.

Operators : etendre Kubernetes pour votre metier

Les Operators sont le mecanisme qui transforme Kubernetes de simple orchestrateur en plateforme d'automatisation complete. Un Operator est un controleur qui etend Kubernetes avec des ressources custom (CRDs) et de la logique metier.

Sur mes projets, j'utilise systematiquement :

• External Secrets Operator : synchronise les secrets depuis Vault, AWS Secrets Manager ou OKMS vers les Kubernetes Secrets
• cert-manager : provisionne et renouvelle automatiquement les certificats TLS. Sur wizops.fr, un ClusterIssuer Scaleway genere et renouvelle le certificat Let's Encrypt sans intervention
• Prometheus Operator : deploie et configure Prometheus, Alertmanager et les ServiceMonitors de maniere declarative

Chez Bloomflow, j'avais developpe un Operator custom pour les environnements de dev ephemeres. Un developpeur creait une CRD DevEnvironment, et l'Operator provisionnait automatiquement un namespace dedie avec tous les services necessaires (base de donnees, cache, services dependants). L'environnement etait detruit automatiquement apres 48 heures d'inactivite. Ce mecanisme a elimine les conflits d'environnement entre developpeurs et reduit la consommation de ressources dev de 60%.

Observabilite automatisee : Prometheus, Loki, OpenTelemetry

L'automatisation ne s'arrete pas au deploiement. Le monitoring aussi doit etre automatique.

Chez Metronome, j'ai deploye la stack Grafana + Prometheus + Loki directement sur le cluster, via Helm. Prometheus decouvre automatiquement les services a monitorer grace aux annotations Kubernetes (prometheus.io/scrape: "true", prometheus.io/port: "8080"). Aucune configuration manuelle pour chaque nouveau service. Loki collecte les logs de tous les pods via un DaemonSet Promtail, sans configuration par service. Grafana fournit des dashboards pre-configures par namespace et par service.

Chez Bloomflow, j'ai ajoute OpenTelemetry pour le tracing distribue. Chaque requete HTTP recevait un trace-id propage entre tous les microservices. En cas de latence anormale, le dashboard Grafana Tempo permettait de visualiser la chaine complete d'appels et d'identifier le service responsable en quelques secondes. Sans tracing distribue, diagnostiquer un probleme de latence dans une architecture de 30 microservices aurait pris des heures.

Conclusion

Kubernetes n'est pas qu'un orchestrateur de conteneurs. C'est une plateforme d'automatisation complete : auto-healing, autoscaling multi-niveaux, portabilite multi-cloud, extensibilite via les Operators, et observabilite automatisee. Apres avoir opere des clusters sur 6 providers cloud, je peux affirmer que Kubernetes est le denominateur commun qui standardise et automatise la gestion des applications cloud, quel que soit le provider sous-jacent.