Faire tenir k3s et trois applications dans 1,8 Go de RAM
la contrainte
Un VPS, 1,8 Go de RAM utilisable, et l'envie d'un vrai pipeline GitOps : déploiement automatique, environnement de staging, rollback en une commande. La plupart des guides Kubernetes commencent par « prévoyez 4 Go minimum ». J'ai voulu vérifier si c'était une nécessité ou une habitude.
ce qui consomme, et ce qu'on peut retirer
La distribution compte : k3s embarque le plan de contrôle dans un seul binaire et remplace etcd par SQLite. C'est le point de départ. Le reste tient en quatre arbitrages.
1. Flux réduit à deux contrôleurs. L'installation par défaut en
déploie cinq. Je n'utilise ni les alertes, ni les images automatiques :
source-controller et kustomize-controller suffisent. Les
trois autres sont désinstallés, pas seulement mis à zéro réplique.
2. Helm via le contrôleur intégré de k3s. k3s sait installer un chart
déclarativement avec sa CRD HelmChart, exécutée par un pod éphémère qui
disparaît ensuite. Zéro mémoire résidente, là où un opérateur Helm classique tourne
en permanence.
3. Pas de stack de supervision lourde. Prometheus + Grafana, c'est facilement 400 Mo — soit un quart du budget pour observer trois applications qui tiennent dans 300 Mo à elles trois. Je m'appuie sur les sondes natives de Kubernetes et les logs. C'est un renoncement assumé, pas un oubli : je sais ce que je perds.
4. Staging à zéro réplique hors usage. L'environnement existe en permanence dans Git — ingress, secrets, manifestes — mais ne consomme rien tant que je ne le monte pas à une réplique. Le coût d'un staging devient celui de son usage réel.
le resultat
plan de contrôle k3s ~500 Mo
Traefik + cert-manager ~120 Mo
Flux (2 contrôleurs) ~100 Mo
site statique (nginx) ~8 Mo
coach-app + MariaDB ~450 Mo
fridge-app (Go+SQLite) ~40 Mo
─────────
~1,2 Go, marge confortable
Les applications en Go y sont pour beaucoup : un mono-binaire compilé statiquement, dans une image distroless, tourne en quelques dizaines de mégaoctets. Le poste le plus lourd après le plan de contrôle est MariaDB — c'est d'ailleurs pour ça que le projet suivant a été écrit sur SQLite.
ce que je retiens
- Les prérequis annoncés supposent un usage par défaut. Ils ne sont pas faux, ils décrivent une installation qu'on n'a pas forcément besoin de faire.
- La contrainte force les bons choix. Sans budget mémoire serré, j'aurais installé la stack complète par réflexe, et je ne saurais pas ce que chaque composant coûte réellement.
- Ce qu'on retire, il faut savoir le nommer. Je n'ai pas de métriques historisées. C'est une dette identifiée, avec une porte de sortie connue : ajouter un nœud agent le jour où ce sera nécessaire.