Exploiter Kubernetes pour optimiser l'orchestration des containers
Kubernetes en production : retour d'expérience sur 8 ans d'orchestration
J'ai déployé mon premier cluster Kubernetes en 2017 chez SFR Business Team, à l'époque un PoC sur Docker Swarm qui a rapidement montré ses limites. Depuis, j'ai opéré des clusters K8s sur pratiquement tous les cloud providers du marché : AWS (EKS), GCP (GKE), Azure (AKS), OVH Cloud, Scaleway et même du bare-metal. Voici ce que j'ai appris.
Le choix du provider Kubernetes : un vrai sujet
Tous les Kubernetes managés ne se valent pas. Chez Okeiro dans le secteur e-Santé HDS, nous avons choisi GKE Autopilot sur le cloud souverain S3NS de Google. L'avantage d'Autopilot est radical : plus de gestion de nodes, plus de dimensionnement à anticiper. Google gère le scaling, le patching et la sécurité des noeuds. Pour une startup avec une équipe réduite, c'est un gain de temps considérable.
À l'inverse, chez KNDS dans la Défense, le choix s'est porté sur OVH Cloud Managed Kubernetes. La raison est simple : souveraineté des données. Les workloads ne pouvaient pas quitter le territoire européen, et OVH offrait les garanties nécessaires. Le compromis : plus de travail opérationnel sur les nodes, les NetworkPolicies, le RBAC.
Chez Bloomflow, nous opérions du Kubernetes multi-providers avec des clusters sur AWS, Scaleway et Outscale (SecNumCloud pour le projet DGE). La couche d'abstraction via Helm et ArgoCD nous permettait de déployer la même application sur trois providers différents sans modifier le code applicatif.
L'orchestration au quotidien : ce qui change vraiment
La promesse de Kubernetes est de gérer automatiquement le cycle de vie des containers. En pratique, cela fonctionne remarquablement bien quand on respecte quelques principes fondamentaux.
Le premier est le dimensionnement des requests et limits. Chez Coopengo, en environnement HDS sur AWS, j'ai passé des semaines à affiner les requests CPU et mémoire de chaque microservice. Un mauvais dimensionnement entraîne soit du gaspillage (requests trop élevées, les pods réservent des ressources inutilisées), soit de l'instabilité (limits trop basses, les pods sont OOMKilled en pic de charge). L'outil qui m'a le plus aidé : Grafana avec les métriques Prometheus du kubelet, pour visualiser la consommation réelle vs. les requests déclarées.
Le second principe est l'utilisation des health checks. Les liveness probes et readiness probes ne sont pas optionnelles. Sur un projet chez Metronome, un service sans readiness probe recevait du trafic avant d'avoir fini sa connexion à la base de données. Les erreurs 502 étaient intermittentes et difficiles à reproduire. Deux lignes de YAML ont résolu le problème.
Le scaling : automatique mais pas magique
Le Horizontal Pod Autoscaler (HPA) est puissant, mais il faut comprendre ses limites. Il réagit aux métriques, pas aux prédictions. Chez TEKYN, plateforme e-commerce, les pics de trafic liés aux campagnes marketing étaient prévisibles. Plutôt que de compter uniquement sur le HPA, nous avions mis en place des CronJobs qui pré-scalaient les déploiements critiques 30 minutes avant les campagnes. Le HPA gérait ensuite les ajustements fins.
Sur EKS Fargate chez F2R2, le scaling est différent : chaque pod tourne dans sa propre micro-VM. Le temps de démarrage est plus long (30-60 secondes vs. quelques secondes sur des nodes classiques), ce qui impose de pré-scaler davantage. Le trade-off en isolation de sécurité en vaut souvent la peine pour des environnements sensibles.
Ce que Kubernetes ne résout pas tout seul
Kubernetes orchestre les containers, mais il ne résout pas les problèmes d'architecture applicative. J'ai vu des équipes migrer un monolithe vers K8s en espérant gagner en scalabilité. Sans refactoring en microservices, elles ont juste ajouté de la complexité opérationnelle. Mon conseil : commencez par conteneuriser proprement votre application avec un Dockerfile optimisé, validez que cela fonctionne en Docker Compose, puis migrez vers Kubernetes quand vous avez un vrai besoin d'orchestration (scaling, rolling updates, multi-environnements).