Simplifiez vos déploiements avec Kubernetes et Docker
Introduction
Simplifier les déploiements est un objectif permanent de mon travail de SRE et DevOps. La complexité apparente de Kubernetes rebute beaucoup d'équipes, mais avec les bons patterns et les bons outils, un déploiement Kubernetes devient plus simple et plus fiable qu'un déploiement manuel sur VM. Voici comment j'ai simplifié les déploiements sur des projets allant de la startup au grand compte.
Du docker-compose au Kubernetes : la transition pragmatique
Beaucoup d'équipes démarrent avec docker-compose et hésitent à passer à Kubernetes. Chez Metronome, la transition s'est faite en douceur. J'ai d'abord écrit un docker-compose qui reproduisait l'architecture cible (services, dépendances, réseau), puis j'ai converti chaque service en manifeste Kubernetes via Helm. L'astuce : garder le docker-compose pour le développement local et Kubernetes pour le staging/production. Les développeurs continuaient à utiliser docker-compose up pour développer, tandis que le CI/CD déployait sur Kubernetes. Cette approche a permis une transition sans disruption : les développeurs n'ont pas eu à apprendre Kubernetes pour continuer à travailler.
Helm : le gestionnaire de packages Kubernetes
Helm est l'outil que j'utilise systématiquement pour packager les déploiements Kubernetes. Chez Coopengo, la migration de Helm v2 à v3 que j'ai menée a simplifié l'architecture en supprimant Tiller (le composant serveur de Helm v2 qui posait des problèmes de RBAC). Chaque service avait son chart Helm avec des values par environnement. Le template Helm permettait de factoriser la configuration commune (probes, resources, labels, annotations) tout en permettant des overrides par environnement. Sur WizOps.fr, le chart Helm dans wizops_charts/wizops/ définit le Deployment, le Service, l'Ingress NGINX avec cert-manager, et les External Secrets. Un seul helm upgrade déploie ou met à jour l'ensemble.
Le pattern Kustomize pour les overlays d'environnement
Pour les projets qui préfèrent rester proches du YAML natif Kubernetes, Kustomize est une alternative à Helm que j'utilise parfois. Chez Padam Mobility, la structure était : un répertoire base/ avec les manifestes communs, et des overlays par environnement (overlays/dev/, overlays/staging/, overlays/prod/). Chaque overlay modifiait les replicas, les resources, les variables d'environnement et les ingress. ArgoCD déployait chaque environnement depuis son overlay. L'avantage de Kustomize : pas de template engine, le YAML est lisible directement. L'inconvénient : moins de flexibilité que Helm pour les charts complexes. Mon critère de choix : Helm pour les applications avec beaucoup de variantes de configuration, Kustomize pour les applications simples.
L'Ingress Controller et le TLS automatique
La gestion du routage HTTP et du TLS est un aspect que je simplifie systématiquement avec Ingress NGINX et cert-manager. Sur tous mes clusters, cert-manager provisionne automatiquement des certificats Let's Encrypt pour chaque Ingress. Chez Bloomflow, l'ajout d'un nouveau service exposé publiquement se résumait à créer un Ingress avec une annotation cert-manager : le certificat TLS était provisionné en 30 secondes. Sur WizOps.fr, l'Ingress NGINX route wizops.fr vers le frontend Nuxt et api.wizops.fr vers le backend Django, avec un cluster issuer Scaleway pour le TLS. Cette simplicité de configuration est un gain énorme par rapport à la gestion manuelle de certificats et de reverse proxies.
Les déploiements canary simplifiés
Le déploiement canary, souvent perçu comme complexe, peut être simplifié. Chez TEKYN, j'ai utilisé un pattern basique sans Istio ni Argo Rollouts : deux Deployments (stable et canary), un seul Service Kubernetes avec un sélecteur de label commun, et un ratio de replicas pour contrôler la répartition du trafic. Avec 9 replicas stable et 1 replica canary, 10% du trafic allait vers la nouvelle version. Pour augmenter, il suffisait d'ajuster les replicas. Ce pattern est moins sophistiqué qu'Argo Rollouts mais ne nécessite aucun outil supplémentaire. Pour les équipes qui débutent avec le canary, c'est un excellent point de départ avant de passer à des solutions plus avancées.
Conclusion
Simplifier les déploiements Kubernetes passe par les bons outils (Helm, Kustomize, cert-manager) et les bons patterns (transition progressive, overlays d'environnement, canary basique). L'objectif est qu'un déploiement devienne un non-événement : automatique, fiable, réversible. Quand un développeur peut merger une PR et voir son code en production 10 minutes plus tard sans intervention manuelle, la promesse de Kubernetes est tenue.