Kubernetes a un problème d’image : la moitié du secteur le porte comme un badge, l’autre le considère comme une taxe. Pour moi, c’est un outil dont le domaine d’utilisation est clair. Un site marketing ou un MVP fonctionne très bien sur un seul serveur avec un gestionnaire de processus et une tâche CI — c’est ainsi que ce site est déployé. Kubernetes commence à se justifier lorsqu’il y a plusieurs services, une charge irrégulière et plusieurs équipes qui livrent sur la même infrastructure.
Tout commence par le conteneur. Dockerfiles multi-stage, image d’exécution légère, aucune dépendance de développement, utilisateur non-root, un processus par conteneur. Une application Next.js est construite en mode standalone ; une API NestJS ne livre que dist et les dépendances de production dans node_modules. La même image passe de la CI au staging puis à la production. Seule la configuration change, par variables d’environnement, ConfigMaps et Secrets — jamais une reconstruction pour chaque environnement.
J’utilise peu d’objets au quotidien : un Deployment par service, un Service devant lui, un Ingress avec TLS pour le trafic public et un HorizontalPodAutoscaler pour les composants dont la charge varie vraiment. Chaque conteneur reçoit des requests et des limits de ressources — sans elles, le scheduler devine. Les sondes readiness et liveness sont distinctes à dessein : readiness signifie « ne m’envoie pas encore de trafic », liveness « redémarre-moi ». Les confondre transforme une base lente en tempête de redémarrages. Chaque service Node.js traite également SIGTERM et termine les requêtes en cours, afin qu’un rolling update n’interrompe pas un paiement à mi-chemin.
Tout n’est pas un serveur web. Les workers de file d’attente ont leurs propres Deployments et s’adaptent à la longueur de la file, pas au CPU. Les tâches planifiées — rapports, nettoyage, rapprochement avec un prestataire de paiement — s’exécutent en CronJobs avec concurrencyPolicy: Forbid, pour qu’une exécution lente ne chevauche jamais la suivante. Les migrations de base de données sont un Job avant le déploiement, pas au démarrage de l’application : cinq réplicas qui démarrent en même temps ne doivent pas tous tenter de migrer le schéma. Je préfère un PostgreSQL géré, comme RDS, à un StatefulSet — le cluster est destiné aux services sans état.
Les manifestes sont dans Git et passent en revue comme du code. Le déploiement passe par une pipeline CI avec Helm ou Kustomize, ou par GitOps avec Argo CD : revenir en arrière consiste alors à faire un revert, pas à lancer une session kubectl au milieu de la nuit. kubectl apply depuis un ordinateur portable sert à apprendre, pas à la production. Les logs vont sur stdout puis dans un stockage central, les métriques dans Prometheus et Grafana ; je surveille le déploiement avec kubectl rollout status au lieu de croiser les doigts. Sur AWS, cela signifie généralement EKS avec des groupes de nœuds gérés, pour que l’équipe se consacre au produit plutôt qu’au control plane.
Je refuse Kubernetes pour un site de deux pages, un service mesh avant d’avoir plusieurs services, des secrets en YAML clair dans le dépôt et des pods sans limites sous prétexte que « ça marchait en staging ». Si vous ne savez pas si un cluster est nécessaire, envoyez-moi vos services, votre trafic et la taille de l’équipe. Je vous dirai franchement s’il vous faut Kubernetes, quelques conteneurs sur un seul hôte ou une plateforme comme Vercel — et combien chaque option coûte à peu près par mois.
Donnez à votre prochain produit quelqu’un qui reste.
Prêt à commencer ? Écrivez-moi — je peux démarrer immédiatement et rester dans la durée. Des collaborations à long terme, pas une passation après deux semaines. Discutons de votre projet, de vos exigences et de la meilleure façon d’avancer.