De Docker Compose à Kubernetes : architecture complète, distributions (K8s, K3s, K0s, MicroK8s), objets fondamentaux, networking, Ingress, scaling automatique et déploiement en production.
Docker résout un problème réel : packager une application avec ses dépendances dans un conteneur reproductible. Kubernetes résout un problème différent : faire tourner des centaines de ces conteneurs de façon fiable, sur plusieurs machines, sans intervention humaine permanente.
Comprendre pourquoi K8s existe avant de toucher la moindre commande kubectl — c'est ce qui fait la différence entre "je suis la doc" et "je comprends ce que je fais".
Docker Compose est excellent pour un seul serveur. Vous définissez vos services dans un fichier YAML, vous tapez docker compose up, et tout tourne. Simple, lisible, efficace.
services:
web:
image: mon-app:latest
ports: ["3000:3000"]
depends_on: [db, redis]
db:
image: postgres:16
volumes: [db_data:/var/lib/postgresql/data]
redis:
image: redis:7-alpinePour un blog, une petite API, un projet perso — Docker Compose est suffisant. N'utilisez pas Kubernetes si Docker Compose fait le travail.
Votre application tourne sur un VPS. Le VPS tombe — disque défaillant, panne réseau, maintenance chez l'hébergeur. Votre app est down jusqu'à ce que vous interveniez.
Docker Compose n'a aucun mécanisme pour démarrer vos conteneurs sur une autre machine. C'est vous qui devez le faire, manuellement.
# Docker Compose peut scaler sur une même machine
docker compose up --scale web=3
# Mais les 3 instances sont sur la même machine
# Si la machine est à 100% CPU, les 3 instances souffrent ensembleKubernetes distribue les instances sur différentes machines (nodes). Si un node est saturé, K8s place les nouvelles instances ailleurs.
Avec Docker Compose, mettre à jour une image signifie arrêter le conteneur, le recréer, le redémarrer. Pendant ce temps — quelques secondes à quelques minutes — votre service est indisponible.
Kubernetes fait des rolling updates : il démarre la nouvelle version, vérifie qu'elle répond, puis coupe l'ancienne. Zéro interruption.
Docker Compose redémarre un conteneur qui crashe (avec restart: always). Mais si le nœud où tourne le conteneur tombe, Docker Compose ne peut rien faire. Kubernetes, lui, détecte que le nœud est mort et replanifie les pods sur les nœuds survivants — automatiquement, en quelques secondes.
En Docker Compose, les services se trouvent par nom de service (résolution DNS interne de Docker). Ça fonctionne bien sur une machine. Mais quand un service tourne sur 10 machines différentes, il faut un système pour savoir où chaque instance se trouve et distribuer le trafic.
Kubernetes a cela nativement avec les Services — une IP virtuelle stable qui distribue le trafic vers toutes les instances saines.
Problème → Solution K8s
──────────────────────────────────────────────────────
Serveur qui tombe → Multi-node, rescheduling automatique
Montée en charge soudaine → HPA (Horizontal Pod Autoscaler)
Déploiement sans downtime → Rolling update + readiness probes
Configuration sécurisée → Secrets chiffrés, ConfigMaps
Traffic distribution → Services + Ingress
Rollback rapide → kubectl rollout undo
Isolation des environnements → Namespaces (dev/staging/prod)| Critère | Docker Compose | Kubernetes |
|---|---|---|
| Complexité opérationnelle | Faible | Élevée |
| Scaling multi-machine | Non | Oui |
| Auto-healing multi-node | Non | Oui |
| Rolling updates | Manuel | Natif |
| Équipe < 5 devs, 1 serveur | ✅ Suffisant | ❌ Overkill |
| SLA > 99.9%, plusieurs régions | ❌ Insuffisant | ✅ Adapté |
| Service mesh, RBAC, audit | Non | Oui |
La règle simple : si une panne de 10 minutes est acceptable et que vous tenez sur un serveur, Docker Compose. Si vous avez besoin de haute disponibilité, de scaling automatique, ou de gérer plusieurs équipes sur une même infrastructure — Kubernetes.
Docker a son propre orchestrateur : Swarm. Il est intégré dans Docker Engine, plus simple que Kubernetes, et fait du multi-node.
docker swarm init
docker stack deploy -c docker-compose.yml myappSwarm vs K8s en 2026 : Swarm est maintenu mais n'évolue plus vraiment. L'écosystème K8s (Helm, Prometheus, Istio, ArgoCD, etc.) n'a pas d'équivalent pour Swarm. En production sérieuse, K8s a gagné.
Le problème est clair. Le chapitre suivant compare les distributions Kubernetes — K8s vanilla, K3s, K0s, MicroK8s, et les offres cloud managées — pour choisir celle qui correspond à votre contexte.