Migration K3s : retours d'expérience après 18 mois

Il y a dix-huit mois, on a tiré le rideau sur trois VMs Debian que l’on maintenait depuis sept ans, pour basculer notre socle de production sur K3s. La promesse : moins de yaml ad-hoc, plus de reproductibilité, et surtout la fin des apt upgrade qui réveillent à 2h du matin parce qu’un service systemd a décidé que ça suffisait. Aujourd’hui on opère plusieurs clusters K3s, dont un cluster OVH single-node qui héberge la prod de plusieurs clients, et un cluster local trois noeuds avec Velero, ArgoCD et Tdarr. Voici ce qu’on a appris, sans filtre marketing.

Pourquoi K3s et pas k8s vanilla

La question revient à chaque mission. La réponse tient en trois points :

1. Empreinte mémoire : un noeud K3s tourne sur 512 Mo de RAM utilisable. Pour un cluster de bord, sur une VM 2 vCPU / 4 Go, c’est jouable. Sur un k8s upstream avec etcd dédié, kube-apiserver, controller-manager, scheduler, kubelet et tout le reste, vous partez sur 8 Go minimum avant d’avoir lancé un seul pod utile.
2. Installation en une commande : curl ... | sh. Pas de kubeadm, pas de cri-o à configurer à la main, pas de CNI à choisir entre douze options qui ont toutes leurs pièges. K3s embarque flannel par défaut, et ça suffit pour 90% des cas.
3. Maintenu par Rancher / SUSE : pas un side-project, mais un produit industriel sur lequel des CNCF members s’appuient pour leur edge.

Le compromis assumé : l’API server est un binaire unique avec sqlite par défaut. Pour un cluster < 10 noeuds, ça ne pose aucun problème. Au-delà, on bascule etcd embarqué ou externe.

Les vrais gains après 18 mois

Reprovisioning d’un noeud : 12 minutes. C’est mesuré. On a perdu une VM XCP-ng en production en novembre dernier, hardware fail. La procédure : re-provisionner Debian 12 via ansible, lancer le script d’install K3s avec le token d’agent, attendre que les pods se replanifient. Douze minutes chrono. Avant K3s, sur la même infra avec Docker Compose et une couche nginx-proxy maison, on aurait passé la journée.

Déploiements applicatifs en deux minutes. Avec ArgoCD, un push sur master déclenche un sync automatique. Pas de SSH, pas de git pull sur le serveur, pas de manipulation manuelle de containers. Le développeur push, ArgoCD applique, Traefik route. Le pipeline est entièrement déclaratif.

Backups Velero qui marchent. On a un cas concret : un client a perdu sa base de données Drupal après une migration foireuse. Restauration depuis un backup Velero de la veille : 4 minutes de downtime, données intactes. Avant, c’était mysqldump cron + rsync vers un NAS, et on priait pour que personne n’ait chown -é le dossier entre deux runs.

Les pièges où on est tombés

La gestion des PV sur du stockage local

K3s embarque local-path-provisioner par défaut. C’est pratique en dev, catastrophique en prod multi-noeuds. Un pod qui dépend d’un PV local-path est cloué à son noeud. Si le noeud tombe, le pod ne peut pas être replanifié ailleurs. On a migré tous les PVs critiques vers du NFS backed par un Synology, avec la storage class nfs-csi. Replanification fluide, snapshots, et le NAS s’occupe du RAID.

Les CNI multi-clusters

On a eu un cluster où Cilium et Flannel cohabitaient suite à une migration incomplète. Résultat : moitié des pods en MTU 1500, moitié en 1450, et des erreurs connection reset by peer aléatoires sur les flux > 1KB. Règle absolue : un cluster, un CNI. Documentez-le, testez la MTU end-to-end avec iperf3, et ne laissez personne y toucher sans peer-review.

Les certificats kube-apiserver qui expirent

Personne n’en parle, mais les certs internes K3s ont une durée de vie d’un an. Ils se renouvellent automatiquement… si le cluster est UP au moment de l’expiration. Si vous éteignez un cluster six mois pendant un déménagement, au reboot vous trouvez des x509: certificate has expired dans tous les logs. La parade : k3s certificate rotate avant le shutdown, et un check Prometheus sur kubelet_certificate_manager_client_expiration_seconds.

Ce qu’on a construit autour

Un cluster nu n’a aucun intérêt. Le stack qui tourne au-dessus :

• Traefik comme ingress (embarqué dans K3s, c’est cohérent)
• cert-manager pour Let’s Encrypt — wildcard DNS-01 sur OVH API
• ArgoCD pour le GitOps, avec un repo Gitea privé par environnement
• Velero pour les backups, avec hooks SQL pour les bases
• Prometheus + Grafana + Alertmanager pour le monitoring
• Loki + Promtail pour les logs centralisés

Le tout déployé via Helm + Kustomize, avec un manifest racine app-of-apps ArgoCD. Quand on monte un nouveau cluster client, on clone le repo, on adapte deux variables, et trente minutes plus tard l’écosystème est en place.

Le coût réel

Beaucoup d’agences vendent du Kubernetes managed (EKS, GKE, AKS) à 70 € / mois minimum, hors VMs. K3s sur trois VMs OVH B2-15, c’est 45 € HT par mois pour un cluster qui tient 30+ services en production. La différence n’est pas juste financière : c’est aussi la souveraineté (data en France), la maîtrise du SLA (vous le négociez avec OVH directement), et la capacité de migrer vers un autre cloud en une journée.

Faut-il y aller ?

Si vous gérez plus de cinq services en prod, oui. Si vous êtes seul dev sur un blog WordPress, non — un VPS bête suffit. Le seuil où K3s commence à payer, c’est quand vous gérez plusieurs apps avec des cycles de release indépendants, et que les déploiements manuels deviennent un risque opérationnel.

L’autre signal : si vous redoutez les mises à jour OS sur vos serveurs parce que vous savez que ça va casser quelque chose, c’est qu’il est temps de découpler l’app de l’OS. K3s + containers = vous patchez l’hôte sans toucher au runtime applicatif.

Pour finir

Kubernetes a longtemps eu une réputation de complexité injustifiée pour 90% des cas d’usage. K3s règle ça. Ce n’est pas un k8s au rabais, c’est un k8s ajusté à la réalité d’une PME ou d’une agence. Dix-huit mois plus tard, on ne reviendrait pour rien au monde au bon vieux Docker Compose en production.