CI/CD et GitOps de bout en bout pour un SaaS Kubernetes multi-locataire

Architecture en bref — Un push développeur déclenche GitHub Actions ; le CI exécute ruff/pytest, build l’image FastAPI et la pousse sur GHCR. Une PR GitOps met à jour les valeurs par locataire ; Argo CD réconcilie l’état désiré dans le cluster. Les métriques/logs remontent vers Prometheus/Loki et sont visualisées dans Grafana.

Cette étude de cas se concentre sur la chaîne de livraison et les contrôles opérationnels ; l’application est volontairement minimale pour valider le pipeline et le comportement plateforme.

Note d’implémentation : le système tourne sur un cluster k3d local ; étapes cloud-ready : migration EKS, HPA/VPA pour l’autoscaling, et options d’observabilité managée (CloudWatch ou Amazon Managed Prometheus/Grafana).

• Les secrets ne vivent jamais dans Git ; le CI utilise le GITHUB_TOKEN éphémère et scoped au repo.
• L’auth registry passe par docker/login-action et ce token — pas de credentials longue durée.
• Les credentials runtime vivent dans Kubernetes Secrets (Argo CD, Grafana, app env) et sont montés au déploiement.
• Le secret admin Argo CD est généré à l’installation, stocké en Secret K8s, et peut être rotaté.
• Le RBAC applique le moindre privilège entre namespaces et service accounts.

Scaling (HPA/VPA) & fiabilité — HPA ajoute des réplicas via CPU/mémoire/métriques custom ; VPA ajuste requests/limits. Ces mécanismes ne sont volontairement pas activés dans cette démo pour garder la pression ressources visible ; en production j’ajouterais Metrics Server + Prometheus Adapter et un Cluster Autoscaler cloud.

Design de déploiement cloud (AWS) — Control plane → EKS, workers → managed node groups (ou Fargate), ingress → contrôleur ALB/NLB, registry → GHCR ou ECR, secrets → AWS Secrets Manager + External Secrets Operator, observabilité → CloudWatch ou Amazon Managed Prometheus/Grafana. Coûts principaux : fee EKS, nœuds EC2, EBS, NAT gateway, egress, rétention Loki ; leviers : right-sizing, autoscaling, spot, sampling et rétention des logs.

Compromis & limites — Les PR GitOps ralentissent mais apportent l’auditabilité ; l’isolation par namespace réduit le blast radius sans offrir une isolation hard ; le stack observabilité OSS demande du tuning ; plus de composants = plus d’ops.

Extensions que je peux implémenter ensuite — merge automatique des PR avec policy gates, secrets externes (Vault/ASM), admission control (OPA/Gatekeeper) et isolation multi-cluster pour les locataires à risque.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: demo-api
  namespace: tenant-a
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: demo-api
  minReplicas: 2
  maxReplicas: 6
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: demo-api
  namespace: tenant-a
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: demo-api
  updatePolicy:
    updateMode: "Auto"

Ce projet démontre une boucle de livraison de type production avec auditabilité, isolation par locataire et signaux runtime observables. Il valide la préparation cloud et les fondamentaux de platform engineering : CI, réconciliation GitOps, déploiement multi-locataire et télémétrie utilisable en incident.