On me demande souvent pourquoi ma plateforme perso ne tourne pas sur Kubernetes. Voici la réponse complète, chiffres à l'appui.
TL;DR : ma plateforme DevSecOps complète tourne sur Docker Swarm, au-dessus d'un maillage WireGuard, pour environ 30 euros par mois, facture réelle. La fiabilité n'est pas le problème. Le vrai prix, c'est la rigidité : ajouter ou retirer un nœud reste une opération manuelle. Et le VPN devient une dépendance dure de l'orchestrateur. Je signe quand même.
Cet article est pour les petites équipes, les indés et les plateformes internes. Ceux qui hésitent entre Kubernetes et plus simple.
Le contexte
Je fais tourner une plateforme DevSecOps auto-hébergée pour mes projets. Dessus : un reverse proxy Traefik, un PostgreSQL partagé, un Keycloak pour l'identité, et la supervision avec Prometheus, Grafana et Loki. Un SIEM Wazuh s'active en option. Un SIEM est l'outil qui centralise et analyse les événements de sécurité.
Terraform crée les machines. Ansible les configure. Docker Swarm orchestre les conteneurs.
Le tout vit sur une poignée de petites VM chez un hébergeur européen. Elles se parlent à travers un maillage VPN WireGuard (NetBird). Un maillage VPN, c'est simple : chaque machine parle aux autres dans un tunnel chiffré direct.
La facture, la vraie
Les prix catalogue sont trompeurs. Mes VM coûtent quelques euros pièce hors taxes. La facture qui tombe chaque mois, elle, dit 30 euros.
# La plateforme complète, par mois
1 manager cx32 (4 vCPU, 8 Go)
des workers cx22 (2 vCPU, 4 Go)
1 petite VM dédiée au VPN
1 VM cx32 pour le SIEM, en option
Facture réelle : ~30 € par mois, tout comprisL'écart entre le catalogue et la facture a des noms : la TVA, les adresses IPv4, les sauvegardes, les volumes.
En dev, je fusionne la supervision dans le manager et je coupe le SIEM. La même plateforme tient alors sur une ou deux petites VM.
Un Kubernetes managé ajoute le prix du plan de contrôle avant même les nœuds. Et un Kubernetes que tu gères toi-même te coûte en temps ce qu'il ne coûte pas en euros.
La facture Kubernetes cache aussi un gâchis documenté. D'après le rapport Cast AI 2026, sur plus de 23 000 clusters de production, l'utilisation CPU réelle est de 8 %. Et 69 % des clusters sont surprovisionnés en CPU.
Ce que Swarm donne sans effort
Swarm est intégré à Docker. Il n'y a pas de plan de contrôle à installer, ni de composant de plus à surveiller.
Mon playbook d'initialisation est court et rejouable. Il initialise le manager, fait joindre les workers un par un, pose les labels, crée les réseaux et les secrets.
Les réseaux overlay sont chiffrés. Les secrets sont gérés nativement. Le placement des services se règle avec des labels de nœuds.
Swarm est ennuyeux. Pour une infra, c'est un compliment.
Piège n°1 : docker stack deploy ignore ton .env
Premier piège, et il surprend tout le monde. docker compose up lit ton fichier .env et remplace les variables. docker stack deploy l'ignore complètement.
Le symptôme est vicieux. Tes règles Traefik contiennent un littéral app.${DOMAIN} au lieu de ton domaine. Rien ne crashe. Le routage ne marche juste pas.
C'est une limite connue et assumée depuis des années (issue moby n°29133).
Mon contournement : je ne donne jamais un compose brut à Swarm. Ansible génère chaque fichier depuis un template Jinja2, variables déjà remplacées. Les valeurs sensibles viennent du vault Ansible, pas d'un fichier d'environnement.
Piège n°2 : le MTU de la double encapsulation
Le deuxième piège est réseau. Mes conteneurs se parlent en VXLAN, le réseau overlay de Swarm. Et ce VXLAN passe dans WireGuard. Deux encapsulations, donc deux en-têtes à caser dans chaque paquet.
Le MTU est la taille maximale d'un paquet sur un lien. Chaque encapsulation en consomme un morceau.
WireGuard refuse de fragmenter les paquets trop gros. C'est un choix de design assumé. Un paquet trop gros est rejeté, pas découpé.
La règle tient en une ligne :
# VXLAN ajoute ~50 octets d'en-têtes
mtu_docker = mtu_vpn - 50
# chez moi : 1280 - 50 = 1230
# /etc/docker/daemon.json
{ "mtu": 1230 }Et le test est reproductible avec un simple ping :
# 1202 octets + 28 d'en-tête ICMP = 1230 : passe
ping -M do -s 1202 100.64.0.2
# 1252 + 28 = 1280 : rejeté, paquet trop gros
ping -M do -s 1252 100.64.0.2Si tu oublies ce réglage, le TCP survit à peu près, car il négocie la taille de ses segments. L'UDP, non. Chez moi, c'étaient les métriques qui partaient en timeout, sans une ligne d'erreur utile.
Le vrai prix : la rigidité
Mon audit interne du setup le résume en une phrase : « bien conçu mais architecturalement statique ». Je confirme.
Ajouter un nœud demande trois étapes. Une définition de VM dans Terraform. Une entrée dans le template d'inventaire. Un re-run du playbook d'initialisation.
Retirer un nœud est pire, car tout est manuel. Drainer les services, sortir le nœud du Swarm, détruire la VM. Dans cet ordre, sans se tromper. C'est mon plus gros point de douleur documenté.
Le risque qui va avec : un nœud tombe du Swarm et Terraform ne le sait pas. Personne ne le ramène. Il n'y a pas d'auto-réparation.
La dépendance que Kubernetes n'a pas : le VPN
Tout le plan de contrôle du Swarm passe par le maillage. Le manager annonce son adresse VPN. Les workers le joignent par cette adresse.
La conséquence est directe : si le VPN tombe, l'orchestrateur devient injoignable. Le VPN n'est plus un confort. C'est une fondation.
J'ai accepté cet échange en connaissance de cause. En retour, j'ai du chiffrement partout et une plateforme portable chez n'importe quel hébergeur.
Quand je prendrais Kubernetes quand même
Ce montage a un domaine de validité. Le mien : une plateforme stable, un seul opérateur, des nœuds qui ne bougent presque jamais.
Je prendrais Kubernetes le jour où les nœuds doivent bouger tout seuls. Autoscaling, remplacement automatique des machines, environnements éphémères.
Je le prendrais aussi avec plusieurs équipes qui déploient. Namespaces, RBAC, opérateurs : cette machinerie existe pour ça.
Gartner annonçait 80 % des grandes organisations d'ingénierie avec une équipe platform engineering en 2026. Si c'est toi, prends Kubernetes. Si vous êtes trois, ce chiffre ne parle pas de toi.
Ce n'est pas « Kubernetes est mort ». C'est « Kubernetes est un coût ». Achète-le quand il te rapporte.
La checklist avant de choisir
Passe cette liste avant de créer ton cluster, dans un sens comme dans l'autre.
- Compte tes nœuds : en dessous de cinq, Swarm ou même docker compose suffit souvent
- Chiffre les deux factures, celle de l'hébergeur et celle de ton temps
- Overlay sur VPN :
mtu_docker = mtu_vpn - 50, et vérifie auping -M do - Ne compte jamais sur le
.envavecdocker stack deploy: génère tes compose - Écris les playbooks de drain et de retrait de nœud avant d'en avoir besoin
- Liste ce qui dépend du VPN, et ce qui reste debout s'il tombe
- Note dès aujourd'hui ce qui te ferait migrer vers Kubernetes
Ce qu'il faut retenir
Une plateforme complète tient sur Swarm pour une trentaine d'euros par mois. La fiabilité n'a pas été mon problème.
Le prix se paie ailleurs. Chaque changement de topologie est un chantier manuel. Et le VPN porte tout.
Fais le calcul pour ton cas, pas pour le CV. L'orchestrateur le plus simple qui couvre ton besoin est le bon.
Tu hésites entre Swarm, Kubernetes ou un entre-deux pour ta plateforme ? Parlons-en.