Maîtriser Kubernetes: guide essentiel pour les débutants
Introduction
Mon premier contact avec Kubernetes remonte a 2017, chez SFR Business Team. On operait une vingtaine de services sur Docker Swarm, et la moindre panne de noeud necessitait une intervention manuelle de 30 a 45 minutes. Le jour ou j'ai monte un PoC Kubernetes et qu'un pod redemarrait tout seul en 15 secondes apres un crash simule, j'ai compris qu'on changeait d'ere. Depuis, j'ai deploye et gere des clusters sur OVH Cloud, AWS EKS, GKE Autopilot, Azure AKS et Scaleway pour plus d'une quinzaine de clients. Ce guide condense les fondamentaux que j'aurais aime avoir a mes debuts.
L'orchestration : bien plus que du scaling
Quand on parle d'orchestration, beaucoup pensent immediatement au scaling horizontal. En realite, le premier benefice que j'ai constate chez mes clients est la resilience. Chez Metronome, la migration de Docker Compose (12 conteneurs) vers Kubernetes sur OVH Cloud (80+ pods) n'a pas ete motivee par un besoin de montee en charge, mais par la fatigue operationnelle. Un samedi matin, un noeud OVH a subi une panne materielle. Sans intervention humaine, les pods ont ete redistribues sur les noeuds restants en moins d'une minute. Grafana a enregistre un pic de rescheduling, mais aucun utilisateur n'a ete impacte. Sur Docker Swarm, cette meme situation nous aurait coute une heure d'astreinte.
Chez Coopengo, l'enjeu etait different : un cluster HA sur AWS pour un environnement HDS (Hebergeur de Donnees de Sante), ou l'indisponibilite n'est pas une option. Trois control planes repartis sur trois zones de disponibilite, avec un etcd replique. Le temps de recovery est passe de 45 minutes a moins de 30 secondes, ce qui nous a permis de tenir nos SLA de 99.95%.
Les concepts fondamentaux expliques par la pratique
Pods : C'est l'unite atomique de K8s. Un pod encapsule un ou plusieurs conteneurs qui partagent le meme reseau et le meme espace de stockage. Chez TEKYN, on exploitait le pattern sidecar : un conteneur Nginx en reverse proxy devant chaque service applicatif Node.js. Ce pattern, que j'avais d'abord utilise sur ECS Fargate, se transpose naturellement sur Kubernetes avec l'avantage supplementaire du service discovery natif.
Deployments : Le controleur de reference pour les applications stateless. Il gere le nombre de replicas et les strategies de mise a jour. Chez Bloomflow, chaque microservice avait un minimum de 2 replicas avec un PodDisruptionBudget fixe a minAvailable: 1. Cela garantissait qu'au moins un pod restait disponible pendant les mises a jour, meme lors d'une maintenance de noeud planifiee.
Services : L'abstraction reseau qui rend vos pods accessibles. ClusterIP pour la communication interne, NodePort pour le debug, LoadBalancer pour l'exposition externe. Chez KNDS, dans un contexte Defense, la regle etait stricte : exclusivement des ClusterIP avec un Ingress NGINX controle par NetworkPolicies. Aucun pod n'etait directement expose a l'exterieur du cluster.
Namespaces : L'isolation logique a ne pas confondre avec l'isolation de securite. Chez Padam Mobility, chaque namespace (dev, staging, prod) avait ses ResourceQuotas : 4 CPU et 8 Go de RAM pour le dev, 8 CPU et 16 Go pour le staging. Un developpeur qui lancait un stress test en dev ne pouvait pas impacter le staging.
Le declaratif : penser en etat desire
Le coeur de Kubernetes, c'est le modele declaratif. Vous decrivez l'etat desire ("je veux 3 replicas de mon image, avec 256Mi de RAM et 100m de CPU") et le controleur reconcilie en permanence l'etat reel avec l'etat desire. Ce changement de mentalite est le plus difficile pour les debutants habitues aux scripts imperatifs.
Chez Bloomflow, on gerait plus de 200 manifestes YAML structures en Helm Charts. Sans Helm, cette masse de YAML aurait ete inmaintenable. Mon conseil pour demarrer : commencez avec des manifestes YAML bruts pour comprendre la mecanique, puis passez a Helm des que vous gerez plus de 5 ressources. Et surtout, bannissez les kubectl apply manuels en production. Tout doit passer par un pipeline.
Cinq pieges que j'ai vus (et parfois commis)
1. Pas de requests/limits sur les ressources. J'ai vu un cluster de 6 noeuds tomber chez un client parce qu'un pod Java consommait 32 Go de RAM sans limite. Le scheduler avait place d'autres pods sur ce noeud en se fiant aux requests (inexistantes), et tout le monde a coule ensemble.
2. Le tag latest en production. C'est la garantie de deploiements non reproductibles. Un kubectl rollout restart tire une image differente de celle testee en staging. Sur tous mes projets, j'impose le SHA du commit Git comme tag d'image.
3. Negliger les health checks. J'ai passe une nuit chez Cardiologs a debuguer des erreurs 502 intermittentes. La cause : pas de readiness probe. Le Service envoyait du trafic a des pods dont le processus Java mettait 30 secondes a demarrer. Quinze secondes d'initialDelaySeconds sur la readiness probe ont resolu le probleme.
4. Un seul namespace pour tout. Melanger dev et prod dans le meme namespace, c'est l'accident assure. Chez un client, un kubectl delete deployment cense nettoyer le dev a supprime le service de prod. Depuis, j'impose des contextes kubectl distincts avec des droits RBAC par namespace.
5. Ignorer les PodDisruptionBudgets. Sans PDB, une mise a jour de noeud peut supprimer tous les replicas d'un service simultanement. Chez Coopengo, le PDB minAvailable: 1 sur chaque Deployment etait une exigence non negociable.
Conclusion
Kubernetes n'est pas qu'un outil, c'est un ecosysteme et une maniere de penser l'infrastructure. En 15 ans de carriere, je n'ai vu aucune technologie s'imposer aussi rapidement. Commencez par un cluster de dev avec un seul noeud, deployez une application simple, observez comment K8s gere les pannes, puis montez progressivement en complexite. Les fondamentaux decrits ici vous eviteront les erreurs les plus courantes et vous donneront les bases pour aller plus loin.