# K3s contre Docker Swarm pour héberger un petit parc de sites WordPress d’agence

> Pour une dizaine de sites WordPress d'agence, K3s et Docker Swarm promettent tous deux une orchestration légère : leur coût d'exploitation réel diverge nettement.

- Auteur : Clément Hadrot
- Publié le : 2024-10-15
- Mis à jour le : 2024-10-15
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/k3s-docker-swarm-parc-wordpress-agence/

## L’essentiel

- Swarm démarre en quelques commandes déjà connues de Docker
- K3s apporte l'écosystème Kubernetes en version allégée
- Le bon choix dépend surtout des compétences déjà présentes dans l'équipe

Faut-il un Kubernetes complet pour faire tourner une dizaine de sites WordPress d'agence ? La réponse, pour la grande majorité de ces parcs, est non : la complexité d'un cluster Kubernetes classique dépasse largement le besoin réel. Deux alternatives plus légères se disputent alors la place, Docker Swarm et K3s, chacune avec une philosophie et un coût d'exploitation très différents une fois le confort du démarrage passé.

Ce comparatif ne traite pas de Kubernetes dans sa forme complète, déjà couvert par ailleurs, mais des deux options pensées spécifiquement pour rester légères, dans un contexte où l'équipe qui gère le parc n'a pas forcément une personne dédiée à l'infrastructure à temps plein.

## Docker Swarm : la continuité naturelle pour une équipe déjà sous Docker

Docker Swarm s'active directement depuis l'installation existante de Docker, sans logiciel supplémentaire à déployer, via une commande unique :

```
docker swarm init --advertise-addr 10.0.0.5
```

Pour une agence qui utilise déjà Docker Compose pour ses environnements de développement, la bascule vers Swarm reprend en grande partie le même vocabulaire, avec un fichier de service proche du `docker-compose.yml` habituel :

```
docker stack deploy -c docker-stack.yml sites-wordpress
```

Cette proximité réduit fortement la courbe d'apprentissage initiale : une personne à l'aise avec Docker Compose retrouve ses repères en quelques heures plutôt qu'en plusieurs semaines.

## K3s : Kubernetes allégé, mais Kubernetes tout de même

> L'essentiel à retenir : Swarm démarre en quelques commandes déjà connues de Docker ; K3s apporte l'écosystème Kubernetes en version allégée ; Le bon choix dépend surtout des compétences déjà présentes dans l'équipe

K3s, distribution légère de Kubernetes maintenue par Rancher, s'installe elle aussi via une seule commande, mais le binaire installé reste un Kubernetes complet dans ses concepts : pods, services, ingress, et toute la terminologie associée restent présents, simplement packagés de façon plus compacte et moins gourmande en ressources.

```
curl -sfL https://get.k3s.io | sh -
```

Cette légèreté d'installation ne dispense pas d'apprendre les mêmes concepts qu'un Kubernetes classique : définitions de déploiements en YAML, gestion des volumes persistants, configuration des ingress pour router chaque site WordPress vers le bon pod. Pour une équipe qui n'a jamais manipulé Kubernetes, ce vocabulaire représente un investissement d'apprentissage réel, même si l'infrastructure sous-jacente reste modeste.

## Comparatif direct sur les critères qui comptent pour un parc d'agence

| Critère | Docker Swarm | K3s |
| --- | --- | --- |
| Courbe d'apprentissage si l'équipe connaît Docker Compose | Faible | Moyenne à élevée |
| Écosystème d'outils compatibles (monitoring, ingress avancé) | Restreint | Large, hérité de Kubernetes |
| Empreinte mémoire minimale par nœud | Très faible | Faible mais supérieure à Swarm |
| Pérennité et rythme de maintien du projet | Ralenti depuis plusieurs années | Activement maintenu |
| Portabilité vers un Kubernetes managé plus tard | Nulle, migration à refaire | Directe, mêmes manifestes |

## Le critère qui tranche souvent : la trajectoire du parc

Pour un parc d'une dizaine de sites appelé à rester stable dans sa taille, Docker Swarm limite la complexité opérationnelle quotidienne et convainc par sa proximité avec des outils déjà maîtrisés. Pour un parc appelé à croître, ou pour une agence qui envisage à terme de confier certains projets à un Kubernetes managé chez un fournisseur cloud, K3s offre une voie de migration directe : les manifestes rédigés pour K3s fonctionnent, avec des ajustements mineurs, sur un cluster Kubernetes managé classique, ce qui n'est pas le cas des définitions de service Swarm.

## Ce que ni l'un ni l'autre ne résout automatiquement

- Ni Swarm ni K3s ne gèrent nativement les sauvegardes de bases de données MySQL : cette tâche reste à automatiser séparément, quel que soit l'orchestrateur retenu.
- La gestion des certificats TLS demande, dans les deux cas, l'ajout d'un composant supplémentaire (Traefik pour Swarm, cert-manager pour K3s), non fourni nativement.
- Le monitoring fin des pools PHP-FPM à l'intérieur des conteneurs reste à instrumenter manuellement, indépendamment de l'orchestrateur choisi.

> Le bon orchestrateur n'est pas celui qui a le plus de fonctionnalités : c'est celui que l'équipe saura dépanner un vendredi soir sans documentation supplémentaire.

## Notre verdict

Pour une agence qui gère une dizaine de sites WordPress avec une équipe déjà à l'aise sous Docker, et sans ambition immédiate de grandir vers un Kubernetes managé, Docker Swarm reste le choix le plus pragmatique : sa simplicité opérationnelle compense largement son écosystème plus restreint. Pour une agence qui anticipe une croissance du parc ou une bascule future vers un Kubernetes managé, l'investissement d'apprentissage de K3s se justifie dès aujourd'hui, plutôt que de devoir tout réécrire au moment de la migration.