ADR-0009 : K3s comme distribution Kubernetes de production
| Statut | Accepté |
| Date | 2025-10 |
| Décideurs | Équipe Edukit (dev + ops) |
| Périmètre | Infrastructure de déploiement, tous les services Edukit |
Contexte
Les services Edukit (OrgService, VmService, le front, RabbitMQ, les bases de données) tournent dans des conteneurs Docker. En production, il faut un outil pour les orchestrer, c’est-à-dire gérer leur démarrage, leur redémarrage automatique, leur mise à jour sans interruption de service et leur passage à l’échelle.
Kubernetes est la solution standard pour ça. Mais il existe plusieurs façons d’installer Kubernetes, et le projet tourne sur des serveurs physiques en établissement - pas sur un cloud avec des ressources illimitées. Il faut donc une distribution légère.
L’équipe connaît déjà Kubernetes et a travaillé avec K3s.
Décision
Utiliser K3s (version allégée de Kubernetes, maintenue par Rancher/SUSE) comme orchestrateur de conteneurs en production.
- K3s est installé sur des VMs Proxmox dédiées (une ou plusieurs pour le plan de contrôle, d’autres pour exécuter les conteneurs).
- L’installation se fait avec un seul script, sans dépendances complexes.
- Les déploiements sont gérés par ArgoCD (voir ADR-0010) : on décrit ce qu’on veut déployer dans Git, K3s l’applique.
- La variable d’environnement
ASPNETCORE_ENVIRONMENT=Productionest définie dans tous les manifestes de pods en production.
Conséquences
Bénéfices
- Léger : K3s utilise beaucoup moins de mémoire et de CPU qu’une installation Kubernetes standard. C’est important quand les serveurs ne sont pas des machines cloud surpuissantes.
- Simple à installer : un script, un binaire, et c’est prêt. Ajouter un nouveau nœud prend quelques minutes.
- 100 % compatible Kubernetes : K3s respecte toutes les spécifications Kubernetes. Les outils, les fichiers de configuration et les charts Helm standards fonctionnent sans modification.
- Expérience d’équipe : l’équipe a déjà utilisé K3s, ce qui évite une phase d’apprentissage et réduit les risques de mauvaise configuration.
- S’intègre avec Proxmox : on crée une nouvelle VM Proxmox et on y installe K3s pour augmenter la capacité du cluster - pas besoin de refaire l’architecture.
Coûts et limites
- Quelques différences avec Kubernetes standard : K3s inclut par défaut Traefik (gestion du trafic entrant) et SQLite (base de données interne). Pour un cluster avec plusieurs nœuds maîtres, il faut basculer sur etcd et revoir ces paramètres par défaut.
- Mises à jour manuelles : mettre à jour K3s se fait nœud par nœud, en vidant chaque nœud de ses conteneurs avant de le mettre à jour. Des outils existent pour automatiser ça, mais ils sont à déployer séparément.
- Monitoring à installer soi-même : K3s ne fournit pas de solution de supervision. La stack Prometheus/Loki/Grafana est déployée à part (voir ADR-0012).
Alternatives écartées
- Kubernetes standard (kubeadm) : plus de contrôle sur chaque composant, mais installation et maintenance bien plus complexes. Pas justifié à l’échelle d’Edukit.
- RKE2 : autre distribution Rancher, orientée conformité gouvernementale (FIPS, durcissement CIS). Plus lourde que K3s et conçue pour des contextes très contraints réglementairement - pas le cas ici.
- MicroK8s : alternative légère de Canonical, mais moins connue de l’équipe et liée à l’écosystème snap/Ubuntu.
- Docker Compose seul : utilisé en développement, mais ne gère pas les redémarrages automatiques, le passage à l’échelle, ni les mises à jour sans interruption. Insuffisant pour la production.
- Kubernetes managé cloud (AKS, EKS, GKE) : le service cloud s’occupe de tout, mais avec un coût mensuel élevé et une dépendance à un hébergeur externe. Incompatible avec le budget et les exigences de souveraineté.