À quoi sert Kubernetes ?

Kubernetes orchestre des conteneurs sur un ensemble de machines : il décide où les placer, les redémarre en cas de panne, les expose au réseau, les met à l'échelle selon la charge et gère les mises à jour progressives. Il automatise l'exploitation d'applications conteneurisées à grande échelle.

Qu'est-ce qu'un pod dans Kubernetes ?

Un pod est la plus petite unité déployable de Kubernetes : un ou plusieurs conteneurs qui partagent le même réseau et le même stockage, et qui sont toujours placés ensemble sur le même nœud. En pratique, on gère rarement un pod directement, on passe par un Deployment.

Kubernetes est-il trop complexe pour un petit projet ?

Souvent oui. Kubernetes n'a de sens que lorsqu'on a plusieurs services, plusieurs machines et de vrais besoins de résilience ou de scaling. Pour un seul serveur, Docker Compose ou un PaaS suffisent. Pour apprendre sans coût, une distribution légère comme k3s est le bon point d'entrée.

☸️ Kubernetes : comprendre l'orchestration de conteneurs sans se noyer

📚 Introduction

Docker règle le problème d’empaqueter une application. Mais dès qu’on passe de « un conteneur sur un serveur » à « cinquante conteneurs sur dix serveurs », de nouvelles questions surgissent. Sur quelle machine placer chaque conteneur ? Que faire quand l’une tombe ? Comment router le trafic vers les bonnes instances ? Comment déployer une nouvelle version sans coupure ?

Répondre à la main à ces questions n’est pas tenable. Kubernetes est né chez Google pour les automatiser. C’est un orchestrateur de conteneurs : il place, surveille, redémarre, expose et met à l’échelle des conteneurs sur un parc de machines. Il a la réputation d’être intimidant — à juste titre — mais l’essentiel repose sur une poignée de concepts et une idée directrice. Cet article pose cette base.

🔑 L’idée maîtresse : le modèle déclaratif

Si vous ne deviez retenir qu’une chose de Kubernetes, ce serait celle-ci. Avec Kubernetes, on ne donne pas des ordres impératifs (« démarre ce conteneur », « redémarre celui-là »). On décrit l’état souhaité du système dans des fichiers YAML : « je veux trois instances de cette application, exposées sur ce port ».

Kubernetes compare en permanence cet état désiré à l’état réel du cluster, et travaille sans relâche pour les faire coïncider. Un pod meurt ? Kubernetes en recrée un pour revenir aux trois demandés. Un nœud tombe ? Il replace ailleurs les charges qui y tournaient. C’est la boucle de réconciliation, et c’est ce qui rend le système auto-réparateur. Tout le reste — pods, deployments, services — n’est qu’une déclinaison de ce principe.

🧱 Les objets fondamentaux

Quelques objets suffisent à comprendre 90 % des déploiements.

Pod — la plus petite unité déployable : un ou plusieurs conteneurs qui partagent réseau et stockage, toujours placés ensemble. On en gère rarement un directement.
Deployment — la façon normale de faire tourner une application. On déclare une image et un nombre de répliques, et le Deployment maintient ce nombre de pods, gère les mises à jour progressives et les retours arrière.
Service — une adresse réseau stable devant un ensemble de pods. Comme les pods vont et viennent (et changent d’IP), le Service offre un point d’entrée fixe et répartit le trafic entre eux.
Ingress — la porte d’entrée HTTP/HTTPS depuis l’extérieur, avec routage par nom de domaine et par chemin, et gestion des certificats TLS.
ConfigMap et Secret — la configuration et les données sensibles, injectées dans les pods sans les coder en dur dans l’image.

Un Deployment minimal ressemble à ceci :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: mon-app:1.0
          ports:
            - containerPort: 3000

On l’applique avec kubectl apply -f deployment.yaml, et Kubernetes se charge de maintenir trois pods en vie.

🧩 Comment tient un cluster

Un cluster Kubernetes se divise en deux plans. Le control plane (plan de contrôle) est le cerveau : l’API server reçoit toutes les demandes, etcd stocke l’état désiré, le scheduler décide où placer les pods, et le controller-manager fait tourner les boucles de réconciliation. Les nœuds worker exécutent les charges : sur chacun, le kubelet pilote les conteneurs et le kube-proxy gère le réseau des services.

On dialogue avec tout ça via un seul outil, kubectl, qui parle à l’API server :

kubectl get pods
kubectl get nodes
kubectl logs deployment/web
kubectl scale deployment/web --replicas=5

La bonne nouvelle : sur un cluster managé (GKE, EKS) ou une distribution légère, le control plane est fourni clé en main. On interagit avec les objets, pas avec la plomberie.

🎯 Ai-je vraiment besoin de Kubernetes ?

Question honnête, réponse honnête : souvent, non. Kubernetes apporte de la résilience, du scaling automatique et des déploiements sans coupure, mais il facture cela en complexité d’exploitation. Pour un seul serveur avec quelques services, Docker Compose ou un PaaS auto-hébergé comme Coolify font mieux le travail, avec bien moins de charge mentale.

Kubernetes devient pertinent quand on coche plusieurs cases : plusieurs machines, beaucoup de services, des pics de charge à absorber, un besoin de haute disponibilité, ou une équipe qui veut standardiser ses déploiements. Le bon moment pour l’adopter, c’est quand l’absence d’orchestration commence à faire mal — pas avant.

🧪 S’entraîner sans facture cloud

La meilleure façon d’apprendre Kubernetes, c’est de casser un cluster et de le reconstruire, encore et encore. Inutile pour cela de louer un cluster managé. Une distribution légère comme k3s, avec k3d, monte un vrai Kubernetes multi-nœuds sur son poste en quelques secondes, conforme à l’API officielle. Idéal pour manipuler pods, deployments et services sans risque et sans coût.

⚠️ Quelques précautions

Ne codez rien en dur. Les secrets vont dans des Secret, la config dans des ConfigMap. Un mot de passe dans une image, c’est un mot de passe fuité.
Fixez des requests et limits. Sans limites de CPU et de mémoire, un pod qui dérape peut asphyxier ses voisins sur le même nœud.
Le YAML devient vite ingérable. Multiplier les fichiers par environnement mène au copier-coller et aux erreurs. C’est exactement le problème que Helm vient résoudre.
Kubernetes n’est pas une sauvegarde. Il maintient l’état désiré, pas vos données. La persistance et les backups restent votre responsabilité.

🎉 Conclusion

Kubernetes fait peur par sa surface, mais son cœur tient en une idée : décrire l’état souhaité et laisser le système converger vers lui. Pods, deployments, services, ingress — ce sont autant de façons de déclarer ce qu’on veut, et la boucle de réconciliation fait le reste.

Reste un irritant bien réel : le volume de YAML à écrire et à maintenir dès que les environnements se multiplient. C’est précisément ce que résout Helm, le gestionnaire de paquets qui transforme ces montagnes de manifests en déploiements paramétrables et réutilisables.