Kubernetes et Docker : Des Piliers Incontournables du DevOps
Docker + Kubernetes : de la conteneurisation à l'orchestration en production
Mon premier contact avec Docker remonte à 2015 chez SFR Business Team. À l'époque, nous explorions Docker Swarm pour orchestrer des services de monitoring Grafana et Prometheus. Depuis, j'ai accompagné la transition Docker puis Kubernetes sur plus de 30 projets. Voici les leçons concrètes que j'en tire.
Docker : la fondation qu'il ne faut pas bâcler
Avant même de parler Kubernetes, il faut parler Docker. Et en pratique, je constate que 80% des problèmes K8s que je diagnostique chez mes clients trouvent leur origine dans un Dockerfile mal construit.
Chez TEKYN, plateforme e-commerce, les images Docker pesaient 1.8 Go. Le temps de pull sur les noeuds ECS Fargate ajoutait 90 secondes au démarrage de chaque tâche. En passant à des builds multi-stage avec des images Alpine finales, nous avons réduit la taille à 180 Mo. Le temps de démarrage est passé de 2 minutes à 15 secondes.
Les principes que j'applique systématiquement pour les Dockerfiles : utiliser des images de base légères et versionnées (jamais latest), séparer les couches qui changent rarement (dépendances) de celles qui changent souvent (code), et scanner l'image finale avec Trivy pour détecter les vulnérabilités.
De Docker Compose à Kubernetes : quand faire le saut
Docker Compose reste un excellent outil pour le développement local et les petits projets. Chez Epiconcept, certaines applications tournaient en Docker Compose en production pendant des années sans problème. La question du passage à Kubernetes se pose quand vous avez besoin de scaling horizontal automatique, de rolling updates sans downtime, ou de gérer plusieurs environnements (dev, staging, prod) avec des configurations différentes.
Chez Metronome, le point de bascule a été le besoin de scaling automatique pour absorber les pics de trafic. Docker Compose ne sait pas scaler un service en fonction de la charge CPU. Kubernetes avec un HPA a résolu le problème en quelques lignes de YAML.
Kubernetes en pratique : les patterns qui marchent
Après avoir opéré K8s sur OVH Cloud (KNDS, Metronome), GKE (Okeiro), EKS (F2R2, Coopengo, Earny SA), AKS (Cardiologs) et Scaleway (Bloomflow), voici les patterns que je reproduis systématiquement.
Le premier est la séparation des namespaces par environnement ou par équipe, avec des ResourceQuotas pour éviter qu'un namespace ne consomme toutes les ressources du cluster. Chez Bloomflow, un développeur a déployé un pod avec une fuite mémoire qui a saturé un noeud de 32 Go en 20 minutes. Les ResourceQuotas auraient contenu le dégât.
Le second est l'utilisation de Helm pour packager les applications. Un Helm Chart bien structuré avec des values par environnement (values-dev.yaml, values-staging.yaml, values-prod.yaml) permet de déployer la même application de manière cohérente partout. Chez Okeiro, nous avions un Helm Chart FHIR qui s'adaptait aux spécificités de chaque environnement HDS.
Le troisième est le GitOps avec ArgoCD. Plutôt que de lancer des kubectl apply ou des helm upgrade manuellement, tout passe par Git. Un merge dans la branche main déclenche le déploiement. C'est traçable, réversible, et auditable. Chez KNDS dans la Défense, cette traçabilité n'était pas un luxe mais une exigence réglementaire.
Le monitoring : Prometheus et Grafana en standard
Chez SFR Business Team, j'ai commencé avec Prometheus et Grafana il y a presque 10 ans. Aujourd'hui, c'est devenu mon stack de monitoring par défaut sur chaque cluster Kubernetes. Chez Metronome avec Rancher, chez Bloomflow avec la stack complète Grafana/Loki/Prometheus, chez Cardiologs avec Datadog sur Azure : l'observabilité est le nerf de la guerre. Sans métriques fiables, vous pilotez à l'aveugle.