Docker Compose et Kubernetes ne sont pas des substituts directs
| Critère | Docker Compose | Kubernetes | Commentaire |
|---|---|---|---|
| Développement local | Excellent | Possible, généralement plus lourd | Compose a un coût d'entrée plus faible |
| Production mono-hôte | Excellent | Souvent excessif | Docker documente officiellement ce scénario Compose |
| HA multi-nœuds | Pas de scheduler cluster natif | Excellent | Kubernetes maintient les workloads sur les nœuds |
| Self-healing | Redémarrage sur l'hôte | Excellent | Kubernetes remplace aussi les Pods et réagit aux pannes de nœuds |
| Autoscaling | Manuel | HPA | Scaling basé sur les métriques |
| Rolling updates | Manuel | HPA | Deployment intègre RollingUpdate et rollback |
| Coût opérationnel | Plus faible | Plus élevé | Un cluster exige davantage de compétences et de plateforme |
Docker Compose décrit de façon déclarative services, réseaux, volumes, configurations et secrets d'une application conteneurisée. La Compose Specification est le format recommandé. [1]
Kubernetes gère des workloads et services conteneurisés dans un cluster avec service discovery, load balancing, orchestration du stockage, rollouts, rollbacks et scaling. [8]
La vraie question est donc de savoir si le projet a besoin d'une orchestration de cluster ou si un hôte unique bien géré suffit.
Ce que Docker Compose fait très bien
Compose réunit images, variables d'environnement, réseaux, volumes, healthchecks, dépendances, secrets et configurations. [1][3]
La même définition peut être réutilisée en développement, CI, staging et production avec des fichiers d'override. Docker documente ce modèle. [2]
Cela réduit fortement le coût d'entrée opérationnel.
Compose en production : le serveur unique est documenté
Docker documente explicitement Compose en production et présente le serveur unique comme le modèle de déploiement le plus simple. [2]
En production, il est courant d'utiliser un fichier `compose.production.yaml`, d'adapter ports et variables, de supprimer les bind mounts de code et de configurer les politiques de redémarrage. [2]
Si tout tourne sur une machine, celle-ci reste toutefois une zone de panne commune.
Healthchecks, dépendances et redémarrages
Avec `depends_on` et `condition: service_healthy`, Compose peut attendre qu'une dépendance passe son healthcheck. [3][4]
Le champ `restart` prend en charge `no`, `always`, `on-failure` et `unless-stopped`. [3][7]
Cette résilience concerne le processus sur le même hôte et ne remplace pas un rescheduling sur un autre nœud.
Scaling avec Compose : des répliques ne créent pas un cluster
`docker compose up --scale SERVICE=N` et `docker compose scale` lancent plusieurs instances d'un service. [6]
Dans le modèle standard documenté par Docker, Compose en production fonctionne sur un serveur unique. [2]
La Compose Deploy Specification définit `replicas`, `placement`, `resources`, `update_config` et `rollback_config`, mais la partie `deploy` est optionnelle et peut être ignorée par une implémentation qui ne la prend pas en charge. [5][3]
Ce que Kubernetes ajoute au-delà d'un seul hôte
Kubernetes maintient un état désiré grâce à des contrôleurs. Deployment est l'abstraction courante pour les applications stateless et gère les Pods via ReplicaSet. [10]
La plateforme peut placer des répliques sur des nœuds, maintenir leur nombre, fournir des endpoints stables avec Service et réagir aux pannes. [8][10][15]
La différence principale réside dans ce control plane, pas dans la syntaxe YAML.
Self-healing : panne de processus contre panne de nœud
| Fonction | Docker Compose | Kubernetes | Différence |
|---|---|---|---|
| Redémarrage de conteneur | Oui | Oui | Les deux peuvent relancer un processus |
| Reprise après panne de nœud | Non | Oui | Kubernetes peut placer le Pod ailleurs |
| Maintien des répliques | Manuel | Déclaratif | Les contrôleurs maintiennent l'état désiré |
| Autoscaling par métriques | Non | Oui | HPA ajuste périodiquement les répliques |
| Endpoint stable | Réseau Compose | Service | Service abstrait les Pods changeants |
| Placement CPU/RAM | Sur un hôte | Scheduler du cluster | Le scheduler tient compte des requests |
Compose peut redémarrer un conteneur selon sa restart policy tant que l'hôte Docker fonctionne. [7]
Kubernetes peut en plus remplacer des Pods, maintenir le nombre de répliques et replanifier un workload lorsqu'un nœud devient indisponible. [12]
Readiness retire un Pod non prêt des backends Service, tandis que liveness peut déclencher un redémarrage. Une mauvaise sonde liveness peut elle-même provoquer une panne. [16]
Réseau et découverte de services
Compose crée des réseaux d'application et permet la communication par nom de service, ce qui suffit à beaucoup d'applications mono-hôte. [1]
Kubernetes Service fournit une IP ou un nom d'hôte stable pour un ensemble de Pods qui change au fil du temps. [15]
Cette abstraction devient particulièrement importante dans un cluster multi-nœuds.
Autoscaling et gestion des ressources
Compose permet un scaling manuel, mais ne fournit pas un contrôleur équivalent à HPA piloté par les métriques du cluster. [6]
HorizontalPodAutoscaler peut adapter le nombre de répliques selon CPU, mémoire ou métriques personnalisées. [13]
Kubernetes prend également en charge les `requests` et `limits`; le scheduler utilise les requests pour choisir un nœud. [14]
Déploiements, rolling updates et rollback
Avec Compose, une mise à jour consiste souvent à construire ou tirer une nouvelle image puis recréer les conteneurs concernés. Docker documente par exemple `docker compose up --no-deps -d web`. [2]
Deployment fournit nativement RollingUpdate, l'historique des révisions et `kubectl rollout undo`. [11]
Pour des déploiements fréquents sur plusieurs répliques, Kubernetes offre donc un mécanisme d'orchestration intégré.
Bases de données et workloads stateful
Compose peut exécuter des bases avec des volumes si l'équipe accepte le modèle mono-hôte et gère elle-même sauvegarde, réplication et reprise.
StatefulSet conserve une identité stable des Pods et peut les associer à du stockage persistant. [17]
StatefulSet ne rend pas automatiquement une base hautement disponible. La réplication, la cohérence, les sauvegardes et le disaster recovery dépendent toujours du moteur et de l'architecture.
Le coût opérationnel de Kubernetes compte réellement
La documentation Kubernetes indique qu'un cluster de production demande planification et préparation pour la résilience, les accès, la disponibilité et les ressources. [9]
Kubernetes n'est pas un PaaS complet. Logging, monitoring, alerting et de nombreux composants restent optionnels et extensibles. [8]
Un service Kubernetes managé réduit le travail du control plane, mais l'équipe conserve la responsabilité des workloads, ressources, réseau applicatif, storage et diagnostic.
Les microservices ne justifient pas automatiquement Kubernetes
Kubernetes est adapté aux workloads distribués et dynamiques, mais quelques services ne créent pas à eux seuls un besoin de cluster. [8]
Frontend, API, worker, Redis et PostgreSQL peuvent rester sur Compose si un hôte suffit et si les objectifs de disponibilité le permettent.
Les meilleurs critères sont la tolérance aux pannes de nœud, les répliques, l'autoscaling, les SLO, les déploiements et le nombre d'équipes.
Quand migrer réellement vers Kubernetes
| Question | Compose est adapté lorsque | Kubernetes est pertinent lorsque |
|---|---|---|
| Panne d'hôte | Une reprise externe suffit | Le workload doit survivre automatiquement à une panne de nœud |
| Échelle | Tout tient sur un hôte | Plusieurs nœuds et autoscaling sont nécessaires |
| Déploiements | Un recreate simple ou un processus maison suffit | Des rollouts multi-répliques contrôlés sont nécessaires |
| Équipe | Une ou quelques équipes gèrent un stack simple | Plusieurs équipes ont besoin d'une plateforme commune |
| Nombre de services | Le nombre seul n'est pas un problème de cluster | Les opérations doivent être standardisées et automatisées |
| Plateforme | La simplicité opérationnelle prime | Il faut policies, scheduling et abstractions de cluster |
La migration devient pertinente quand le modèle mono-hôte est une limite opérationnelle, pas simplement parce que `compose.yaml` devient long.
Les signaux concrets sont la continuité après panne de nœud, le placement automatique de plusieurs répliques, l'autoscaling, les rollouts contrôlés, une plateforme partagée par plusieurs équipes ou des politiques communes de ressources et réseau. [8][9][12][13]
Sans ces besoins, Kubernetes peut ajouter plus de complexité que de valeur.
Une trajectoire pratique pour un projet
Une trajectoire courante est Dockerfile pour chaque application, Compose pour développement et intégration, puis Compose aussi en production tant qu'un serveur suffit.
Avant Kubernetes, rendez les composants stateless quand possible, externalisez sessions et fichiers, ajoutez des endpoints de santé corrects et définissez ressources, secrets et storage.
Compose peut rester l'outil local même si la production utilise Kubernetes.
- Commencer par les SLO et la disponibilité.
- Si un seul hôte suffit, évaluer Compose en premier.
- Si la panne d'un hôte ne doit pas arrêter l'application, prévoir une architecture multi-nœuds.
- Pour une charge dynamique, évaluer HPA.
- Pour des rollouts contrôlés de plusieurs répliques, Kubernetes apporte des contrôleurs intégrés.
- Ne pas déplacer une base dans Kubernetes uniquement parce que l'application y est.
- Compter le coût du cluster, de l'observabilité, du réseau et des upgrades.
- Choisir le modèle le plus simple qui répond aux besoins.
