Introduction à Kubernetes : Orchestrateur de Conteneurs Moderne
Kubernetes pour les débutants : ce que j'aurais aimé savoir en commençant
Quand j'ai abordé Kubernetes pour la première fois en 2017 chez SFR Business Team, j'avais déjà plusieurs années d'expérience Docker et Docker Swarm. Malgré cela, Kubernetes m'a dérouté. Les concepts sont nombreux, la documentation est dense, et la courbe d'apprentissage est raide. Voici l'introduction que j'aurais aimé lire à l'époque, enrichie de 8 ans de pratique en production.
Les concepts essentiels : Pod, Deployment, Service
Le Pod est la brique de base de Kubernetes. C'est un ou plusieurs containers qui partagent le même réseau et le même stockage. En pratique, 99% de vos pods ne contiendront qu'un seul container. Le cas multi-containers (sidecar pattern) est utilisé pour des cas spécifiques comme les proxies Envoy chez Bloomflow avec la stack OpenTelemetry, ou les Nginx sidecars chez TEKYN pour servir les fichiers statiques à côté de l'application.
Le Deployment gère le cycle de vie des pods : combien de répliques tourner, comment les mettre à jour (Rolling Update), et quand les redémarrer (si un health check échoue). C'est la ressource que vous utiliserez le plus.
Le Service expose les pods sur le réseau interne du cluster (ClusterIP) ou vers l'extérieur (LoadBalancer, NodePort). Chez Okeiro sur GKE, un Service de type LoadBalancer provisionnait automatiquement un Google Cloud Load Balancer. Sur OVH Cloud chez KNDS, c'était un Ingress NGINX avec cert-manager pour le TLS.
Les composants du cluster : comprendre l'architecture
Un cluster Kubernetes est composé d'un control plane (qui prend les décisions) et de nodes workers (qui exécutent les pods). En mode managé (EKS, GKE, AKS, OVH Managed K8s), le control plane est géré par le provider. Vous ne vous occupez que des workers.
Chez F2R2 sur EKS Fargate, même les workers sont abstraits : chaque pod tourne dans sa propre micro-VM gérée par AWS. C'est le niveau d'abstraction maximal, idéal pour les environnements où l'isolation de sécurité est prioritaire.
Chez Metronome sur OVH Cloud avec Rancher, nous gérions les workers nous-mêmes : choix du type d'instance, dimensionnement du pool de nodes, mise à jour du système. Plus de travail opérationnel, mais aussi plus de contrôle sur les coûts et les performances.
Les erreurs de débutant que je vois encore
La première erreur : ne pas mettre de resource requests et limits. Sans requests, le scheduler Kubernetes ne sait pas comment placer les pods de manière optimale. Sans limits, un pod peut consommer toute la mémoire d'un node et faire tomber les autres pods. Chez Coopengo, cette erreur a causé des crashs en cascade sur un node de production un samedi à 3h du matin.
La deuxième erreur : ne pas configurer de health checks (readiness et liveness probes). Sans readiness probe, Kubernetes envoie du trafic à un pod qui n'est pas encore prêt (la base de données n'est pas connectée, le cache n'est pas chargé). Chez Metronome, des erreurs 502 intermittentes étaient causées par exactement ce problème.
La troisième erreur : utiliser kubectl apply manuellement en production. Cette pratique est impossible à auditer, difficile à rollbacker, et source d'erreurs. ArgoCD (que j'ai déployé chez KNDS, F2R2, Bloomflow, Padam Mobility, Earny SA) résout ce problème en faisant de Git la seule source de vérité.
Par où commencer concrètement
Mon conseil pour quelqu'un qui débute avec Kubernetes : commencez par un cluster managé sur le provider que vous connaissez le mieux. GKE Autopilot est le plus simple pour démarrer (zéro gestion de nodes). Déployez une application simple avec un Deployment, un Service et un Ingress. Ajoutez des health checks, des resource requests, et familiarisez-vous avec kubectl logs et kubectl describe.
Une fois à l'aise, apprenez Helm pour packager vos applications, puis ArgoCD pour automatiser les déploiements. C'est le parcours que j'ai fait suivre aux équipes chez Coopengo, Bloomflow et Padam Mobility, et il fonctionne pour des profils allant du développeur junior au sysadmin senior.