Infra k3s GitOps

La plateforme qui sert la page que vous lisez — Kubernetes en production sur un VPS de 1,8 Go de RAM.

le probleme

Un seul VPS, plusieurs applications à héberger (ce site, Coach Adaptatif, d'autres à venir), et l'envie d'un vrai pipeline : déploiement automatique, staging, rollback en une commande. Contrainte assumée : 1,8 Go de RAM — là où la plupart des guides Kubernetes en recommandent 4 au minimum.

architecture

Internet → Traefik (ingress) + cert-manager (Let's Encrypt)
  ├── jjoly.eu          → site statique (nginx, ce site)
  ├── coach.jjoly.eu    → coach-app + MariaDB dédiée
  ├── fridge.jjoly.eu   → fridge-app + SQLite (une base par foyer)
  └── staging.*         → namespace staging (0 réplique hors usage)

Flux CD observe le repo Git d'infra → applique tout changement
CI (GitHub Actions) : tests → build → scan Trivy → GHCR → commit du tag

les choix qui comptent

• GitOps pull, pas push : le cluster tire son état depuis Git. Aucun accès SSH dans le pipeline, rollback = git revert.
• Budget RAM militaire : Flux réduit à 2 contrôleurs, charts Helm via le contrôleur intégré de k3s (0 Mo résident), pas de stack monitoring lourde, staging éphémère. Total : ~1,5 Go, ça tient.
• Secrets chiffrés dans Git (SOPS + age) : auditables, versionnés, déchiffrés uniquement dans le cluster.
• NetworkPolicies partout : chaque base de données n'est joignable que par son application — par défaut, Kubernetes laisse tout passer.
• API k8s jamais exposée : port 6443 fermé au public, administration par tunnel SSH uniquement.
• Sécurité des workloads : conteneurs read-only, non-root, capabilities droppées, images épinglées par digest, scan de vulnérabilités bloquant en CI.

resilience

• Backups MariaDB quotidiens (CronJob), rétention 7 j + 4 semaines, checksums.
• Migration depuis l'ancien stack docker-compose réalisée avec double filet (dump chiffré + copie hors serveur) et rollback possible à tout moment.
• Extensible en multi-nœuds sans réécriture : k3s agent + labels, les apps stateless se répartissent, les données restent pilotées.

resultat

Un push sur main met à jour le staging en ~1 minute ; un tag vX.Y.Z déploie en production. Ajouter une application = dupliquer un dossier de manifests. Ce site en est la démonstration vivante.

l'etat du cluster

• 1430 Mo de RAM utilisés sur 1870 (76 %)
• 15 pods en fonctionnement sur 1 nœud

Mesuré le 29/07/2026 avec outils/mesurer-infra.sh. Ces valeurs ne sont pas collectées par la CI : donner un accès au cluster au runner créerait un chemin vers la production depuis un tiers.

ce qui tourne dessus

← retour aux projets