🏗️ Projet : Migration K8s "Orion"

Composants d'Infrastructure (AWS)

Le cluster a été provisionné via Terraform et l'EKS Blueprints module pour standardiser les environnements (dev, staging, prod).

L'application "E-Shop" a été découpée en objets K8s (gérés via Helm/ArgoCD).

La gestion des données persistantes (DBs) est critique.

1. StorageClass (Le "Template" de Disque)

Nous avons défini un StorageClass (SC) pour le "Provisioning Dynamique" (automatique) des disques AWS EBS (Elastic Block Store).

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-gp3-fast
provisioner: ebs.csi.aws.com # (Le "driver" CSI d'AWS)
volumeBindingMode: WaitForFirstConsumer # (Attend que le Pod soit schedulé)
parameters:
  type: gp3 # (Type de SSD)
  fsType: ext4
reclaimPolicy: Retain # (Garde le disque si le PVC est supprimé)

2. StatefulSet + volumeClaimTemplates (La "Demande")

Le StatefulSet (pour Postgres) utilise ce SC pour créer automatiquement un PVC (et donc un PV/Disque) unique pour *chaque* réplique (pod-0 -> pvc-0, pod-1 -> pvc-1).

# (Extrait de postgres-statefulset.yaml)
spec:
  serviceName: "postgres-svc"
  replicas: 1
  
  # (Template de PVC: K8s va créer "data-postgres-0")
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ] # (RWO)
      storageClassName: "ebs-gp3-fast" # (Nom du SC)
      resources:
        requests:
          storage: 50Gi # (Demande 50Go)

Mise en place d'une sécurité "Zero Trust" (zéro-confiance) à plusieurs niveaux.

Mise en place de la stack "Prometheus-Stack" (via Helm Chart) dans le namespace monitoring.

Diagramme (Stack Monitoring)

(K8s API) <--+
     |         |
(Kubelet)    | (kube-state-metrics)
     |         |
     ▼         ▼
+--------------------------+
| Prometheus (Server)      | (Modèle "Pull")
| (Scrape /metrics)        | (Stocke les métriques)
| (Gère les alertes)       |
+--------------------------+
     | (Data Source)
     ▼
+--------------------------+
| Grafana (UI)             | (Dashboards)
| (Interroge Prometheus)   | (PromQL)
+--------------------------+

• Prometheus : "Scrape" (pull) automatiquement les endpoints /metrics (cAdvisor, Kubelet, et nos Pods applicatifs (via ServiceMonitor CRD)).
• Grafana : UI pour visualiser les Dashboards (ex: "Node Exporter Full" (CPU/Mem Nœuds), "Kube-State-Metrics" (Déploiements)).
• Alertmanager : Gère les alertes (définies dans Prometheus) vers Slack/PagerDuty.
• DataDog : (Partiel) L'Agent DataDog (DaemonSet) est aussi déployé pour la centralisation des Logs et Traces APM (que Prometheus ne gère pas nativement).

Nous avons implémenté une CI/CD basée sur GitOps (Modèle "Pull") via ArgoCD.

Diagramme du Workflow de Déploiement

(Développeur)
     |
     | 1. "git push" (sur le code de l'API)
     ▼
+------------------+
| GitLab (Repo Code) |
+------------------+
     | (Webhook)
     ▼
+------------------+
| GitLab CI (Runner)| (Tourne dans K8s)
+------------------+
     | 2. Build, Test, Push Image
     ▼
+------------------+
| ECR (Registre AWS) | (ex: api-users:1.2.1)
+------------------+
     |
     | 3. "git push" (Met à jour le tag
     |    de l'image dans le *Repo Config*)
     ▼
+------------------+
| GitHub (Repo Config)| (Contient les YAMLs/Helm K8s)
| (Source de Vérité)  | (imageTag: 1.2.1)
+------------------+
     |
     | 4. "Pull" (ArgoCD détecte le changement)
     ▲
+------------------+
| Cluster EKS      |
| +--------------+ |
| | ArgoCD       | |
| +--------------+ |
| (5. `kubectl apply`)|
+------------------+

• CI (GitLab CI) : Rôle = Tester le code, builder l'image Docker, pusher l'image sur ECR.
• CD (ArgoCD) : Rôle = S'assurer que le cluster (État Actuel) correspond au dépôt Git de configuration (État Désiré).

La migration (réalisée sur 6 mois) a permis d'atteindre les objectifs fixés.