Kubernetes en production : GitOps, observabilité, GKE

Trois mois après la mise en service de l'assistant interne de Ferrand Médical sur Kubernetes, l'équipe plateforme fait le bilan des incidents. Une version qui répondait 200 mais renvoyait des réponses vides est passée en production : les sondes étaient vertes, le rolling update l'a déployée sur tous les pods en 40 secondes. Un collègue a corrigé une variable « en urgence » avec kubectl edit ; personne ne s'en souvenait au déploiement suivant, qui l'a écrasée. Et la clé d'API Gemini, copiée dans trois Secrets de trois namespaces, n'a jamais été changée depuis sa création.

Ce projet traite ces trois causes avec les outils que les équipes plateforme utilisent réellement : Git comme seule source de ce qui tourne, une livraison progressive qui s'arrête seule quand les métriques se dégradent, et une identité de pod qui rend la clé inutile.

Ce que vous livrez

• Une plateforme GitOps locale sur kind : Argo CD 3.5, Argo Rollouts 1.10, kube-prometheus-stack 92.9, un serveur Git dans le cluster.
• Un dépôt de déploiement : le chart et les valeurs par environnement, versionnés dans gitops-source/ et transformés en dépôt git local (gitops-repo/) par make gitops-init. Déployer, revenir en arrière et corriger se font par commit.
• Une livraison canary avec analyse Prometheus : 34 % puis 67 % du trafic, taux de succès mesuré sur les seuls pods canary, annulation automatique sous 95 %.
• Un tableau de bord Grafana, deux alertes d'astreinte (PrometheusRule) et les requêtes PromQL qui servent au diagnostic.
• Un module Terraform GKE Autopilot (réseau privé, Artifact Registry, compte de nœuds dédié, Workload Identity vers Vertex AI) validé et planifié, et la preuve que l'application fonctionne en mode Vertex AI sans clé.

Architecture

flowchart LR
  DEV["Équipe (commit)"] -->|"git push"| GIT["Serveur Git (dans le cluster)"]
  subgraph KIND["Cluster kind lab-k8s-gitops"]
    GIT -->|"lecture toutes les 3 min ou sur refresh"| ACD["Argo CD"]
    ACD -->|"helm template + apply, prune, selfHeal"| RO["Rollout inference (canary)"]
    ARO["Argo Rollouts"] --> RO
    ARO -->|"AnalysisRun : taux de succès du canary"| PROM["Prometheus"]
    PROM -->|"ServiceMonitor, toutes les 15 s"| RO
    GRAF["Grafana"] --> PROM
    ING["Ingress NGINX"] --> RO
  end
  RO -.->|"mode simulé par défaut ; clé d'API en option"| GEM["API Gemini"]
  subgraph GKE["GKE Autopilot (Terraform, plan seulement)"]
    POD["Pod inference (KSA assistant/inference)"] -->|"Workload Identity, aucun secret"| VX["Vertex AI europe-west1"]
  end

Stack

Coût et durée

Durée : 8 heures.

Prérequis

• Le projet Déployer un service IA sur Kubernetes avec Helm, ou une pratique équivalente des charts, sondes et HPA.
• Docker avec 6 Go de RAM libres, kind, kubectl, helm 3.8+, git, Terraform 1.9+, Python 3.10+.
• Pour la partie GKE et l'appel réel : gcloud et des identifiants ADC sur un projet avec Vertex AI activé. Une clé Gemini est facultative (sans elle, le cluster répond en mode simulé).

Programme

Le dépôt complet est dans files/.