blog.6admin.io
guest@6admin.io:~$
devops, docker, foreman, kubernetes, migration, swarm

Docker Swarm to Kubernetes : pourquoi j'ai abandonné Swarm

Docker Swarm fonctionne bien comme orchestrateur léger pour des déploiements petits à moyens. Il est simple, mature et la barrière d’entrée est faible. Mais il frappe des murs structurels sur la sécurité et la gestion avancée des containers. Voici les quatre.

Pas de mode rootless

Le mode rootless de Docker (dockerd-rootless-setuptool.sh avec slirp4netns/RootlessKit) est incompatible avec Docker Swarm. La documentation officielle liste explicitement:

  • Overlay networks: Swarm repose entièrement sur l’overlay (VXLAN) pour la communication inter-nœuds. Sans overlay, les services sur des nœuds différents ne se voient plus. Swarm devient un outil mono-nœud.
  • AppArmor: pas de MAC (Mandatory Access Control) sur les containers.
  • Checkpoint/Restore: pas de snapshot CRIU, pas de migration à chaud, pas de récupération d’état.

C’est une contrainte architecturale fondamentale: Swarm requiert des primitives réseau kernel-level (netns, veth, VXLAN) que le mode rootless ne peut pas fournir. slirp4netns et RootlessKit opèrent dans des namespaces utilisateurs incompatibles avec le réseau overlay kernel.

Référence: Docker Rootless - Known Limitations

Le modèle de sécurité limité

  • Pas de Pod Security Admission / Pod Security Standards (l’équivalent K8s).
  • Pas de network policies natifs (pas de filtrage L3/L4 ingress/egress entre services).
  • Pas de rotation de secrets native.
  • Pas d’admission controllers pour appliquer des politiques au déploiement.
  • userns-remap est la meilleure mitigation disponible, mais ce n’est pas du rootless.

Pas d’autoscaling natif

Swarm n’a pas d’horizontal pod autoscaler. Le scaling est manuel (docker service scale) ou nécessite de l’outillage externe sans API standard.

MACVLAN cloué à un seul nœud

Dans le projet, les services DHCP et TFTP nécessitent un accès direct au réseau physique pour le PXE boot. Docker Swarm ne peut pas combiner MACVLAN avec les réseaux overlay: un service MACVLAN est lié à une interface réseau spécifique d’un hôte et ne peut pas être schedulé sur plusieurs nœuds. Ça force un déploiement mono-nœud pour tous les services de boot réseau, ce qui est un point de défaillance unique sans scaling horizontal possible.

Les limitations de storage

  • Pas de CSI (Container Storage Interface).
  • Pas de dynamic volume provisioning.
  • Pas de storage classes ni de persistent volume claims.
  • La gestion des volumes est locale ou nécessite un setup NFS/Ceph manuel.

Le comparatif Swarm / MicroK8s / K8s

                    Swarm                  MicroK8s                  K8s
Complexité          Faible                 Moyenne                   Élevée
Installation        Intégré à Docker       Snap, facile              Complexe
Cluster             ~50 nœuds max          1-100 nœuds               1000+ nœuds
HA                  Basique                Par clustering            Avancée
Réseau              Overlay intégré        Calico, Flannel, etc.     Multi-CNI
Storage             Basique                CSI drivers               Full CSI
Sécurité            TLS basique            Features K8s              RBAC, PSS, NetworkPolicies
Écosystème          Limité                 Croissant                 Très large

L’argument qui n’est pas le scaling

L’argument qu’on entend toujours contre Kubernetes, c’est “on n’est pas Netflix”. Mais le scaling n’est pas le premier intérêt de Kubernetes. Le premier intérêt, c’est le remplacement.

Avant Kubernetes, ce que vous gérez à la main: le load balancing (HAProxy + Keepalived + IP flottante), le service discovery (inventaire Ansible ou Consul), les rollouts (script serial:1 qui draine, update, reconfigure), le stockage (montage manuel par machine), les certificats (statiques, intégrés au cycle de vie), les secrets (Ansible Vault), les cronjobs (crontab + lockfile), le firewall (iptables par machine, mis à jour à chaque changement de topologie), les logs (logrotate par application), le packaging (rpm, deb, tar.gz dans /opt, systemd ou script init degueu).

Kelsey Hightower l’a résumé: “Kubernetes is the sum of all the shell scripts, and practices, system administrators have cobbled together over time, presented as a single system behind a declarative set of APIs.”

Kubernetes remplace tout ça par quelques YAML: Deployment, Service, Ingress, ConfigMap, Secret. kubectl apply et c’est déployé. Service discovery, load balancing, scaling, secrets, cronjobs, firewalling, logging, tolérance aux pannes: built-in. Le format est déclaratif, standard et transférable entre cloud et entreprises.

La question n’est pas “êtes-vous assez gros pour Kubernetes”. La question est: combien de temps avez-vous passé à reconstruire à la main ce que Kubernetes fournit d’origine?

La décision

k0s single-node pour démarrer, puis multi-node multi-site quand le parc grandit.

L’effort de migration

Quatre stacks actives à migrer: edge (Traefik), net (PowerDNS, DHCP, TFTP, Squid), obs (VictoriaMetrics, Grafana , OTEL), foreman (Foreman, Smart Proxy, PostgreSQL). Chaque stack a sa complexité propre et le réseau MACVLAN (DHCP/TFTP) reste le point critique: Kubernetes ne gère pas le MACVLAN nativement, il faut Multus CNI.

L’effort est estimé en semaines, pas en jours et le chemin est progressif: k0s single-node d’abord, multi-node ensuite, multi-site en dernier.

[edit: 2026] L’implémentation Ansible de tout ceci: les rôles k0s et microk8s .