Phase 1 — MVP opérationnel

GitOps Config
Drift Detector

Détection automatique des écarts entre les manifests GitHub et l'état réel des clusters Kubernetes. Avant qu'un écart ne devienne un incident.

30
types de dérives détectés
30min
intervalle de scan
30
dérives détectées
0
dérive active actuellement
01
Contexte
Pourquoi ce projet ?
Self-Healing Platform v2 répare les incidents. Ce projet cherche à les empêcher avant qu'ils n'arrivent.

Après avoir déployé Self-Healing Platform v2 sur mon homelab — 244 incidents traités, 85% de confiance IA, MTTR réel de 12 secondes — une question s'est posée naturellement : et si on pouvait éviter ces incidents en amont ?

En production, les dérives de configuration sont fréquentes et souvent invisibles. Un kubectl scale pour tester une montée en charge. Un kubectl edit pour débugger en urgence. Une image taguée latest poussée sans commit Git.

Au début, ce n'est qu'un écart. Quelques jours plus tard, c'est souvent un incident. GitOps Config Drift Detector détecte ces écarts avant qu'ils n'évoluent.

Philosophie
Observer
→
Mesurer
→
Comprendre
→
Automatiser
Self-Healing Platform v2 répare les incidents.
GitOps Config Drift Detector cherche à les empêcher avant qu'ils n'arrivent.
02
Architecture
Comment ça fonctionne
Un scanner Python compare en permanence GitHub avec l'état réel du cluster K3s.

Le scanner tourne toutes les 5 minutes via APScheduler sur le cluster K3s. À chaque cycle, il lit les manifests YAML depuis les dépôts GitHub via l'API, interroge kubectl pour l'état live, et compare champ par champ.

Toute dérive détectée est immédiatement enregistrée dans PostgreSQL avec son type, sa sévérité, la valeur Git attendue et la valeur réelle du cluster. Un mécanisme d'upsert anti-duplication évite les doublons : si la dérive persiste, seuls last_seen et occurrences sont mis à jour.

GitHub
Scanner Flask
kubectl live
Comparaison
PostgreSQL
API REST
Grafana

L'API REST expose /health, /scan, /drifts et /stats. Un scan manuel peut être déclenché à tout moment via POST /scan. Le dashboard Grafana se connecte directement à PostgreSQL et affiche les métriques en temps réel.

03
Détection
5 types de dérives
Chaque type a une sévérité fixe, indépendante du contexte. Lisible, exploitable, sans ambiguïté.
service_port_drift
CRITICAL
Port de service différent entre Git et le cluster. Impact direct sur la connectivité.
image_tag_drift
HIGH
Image Docker non conforme à Git. Risque de comportement imprévisible en production.
resource_limit_drift
HIGH
Limites mémoire/CPU modifiées manuellement. Risque d'OOM ou de saturation ressources.
resource_request_drift
MEDIUM
Requests CPU/mémoire différentes de Git. Impact sur le scheduling Kubernetes.
replicas_drift
LOW
Nombre de replicas différent de Git. Souvent lié à un scale manuel temporaire.
configmap_drift — V2
À VENIR
Détection des dérives sur ConfigMaps et Secrets.
04
Données
Schéma PostgreSQL
Chaque dérive est historisée avec toutes les métadonnées nécessaires à l'analyse et à la classification future.
CREATE TABLE drifts (
  id SERIAL PRIMARY KEY,
  detected_at TIMESTAMP -- première détection
  last_seen TIMESTAMP -- dernière occurrence
  occurrences INT DEFAULT 1 -- nb de scans consécutifs
  repository VARCHAR(100) -- repo GitHub source
  namespace VARCHAR(100) -- namespace K8s
  resource_kind VARCHAR(50) -- Deployment, Service...
  resource_name VARCHAR(200) -- nom de la ressource
  drift_type VARCHAR(50) -- image_tag_drift...
  severity VARCHAR(20) -- LOW/MEDIUM/HIGH/CRITICAL
  git_value TEXT -- valeur attendue (Git)
  cluster_value TEXT -- valeur réelle (K8s)
  status VARCHAR(20) -- open / resolved
  resolved_at TIMESTAMP -- retour à la conformité
  decision_source VARCHAR(50) -- scanner / human / ai
  recommended_action VARCHAR(50) -- observe / suggest_revert / create_pr
);

Le champ decision_source et recommended_action ont été inclus dès le départ — même sans être utilisés en Phase 1 — pour éviter une migration de schéma lors du passage en Phase 3 (PR automatique) et Phase 4 (classification IA). Même approche que Self-Healing v2 avec confidence_score et action_taken.

05
Résultats Phase 1
MVP opérationnel
Déployé sur homelab K3s réel, pas un environnement de démonstration.
30
types de dérives
30min
intervalle de scan
30
dérives résolues
0
dérive active actuellement

Les trois types de dérives critiques ont été validés sur infrastructure réelle : replicas_drift (LOW), image_tag_drift (HIGH) et resource_limit_drift (HIGH). Chaque dérive a été détectée au scan suivant, enregistrée dans PostgreSQL et visible dans Grafana en temps réel.

L'upsert anti-duplication garantit qu'une dérive persistante ne génère pas de lignes en double — seules last_seen et occurrences sont incrémentées. Cela permet de mesurer la durée réelle d'une dérive et le nombre de cycles pendant lesquels elle est restée non corrigée.

Grafana — GitOps Config Drift Detector Dashboard
Dashboard Grafana GitOps Config Drift Detector
Dashboard Grafana — 12 panneaux : Total Drifts, Open, CRITICAL, HIGH, par repo, par namespace, par type, timeseries, table.
06
Roadmap
4 phases prévues
La même progression que Self-Healing v2 : observer d'abord, automatiser ensuite.
1
Phase 1 — En cours
MVP Observe
Scanner opérationnel · PostgreSQL · API REST · Grafana · 5 types de dérives · Scheduler 5 min
2
Phase 2 — Prochaine
Alertes Brevo
Email automatique sur dérive CRITICAL · Historique résolution · Dashboard tendance 7 jours
3
Phase 3 — Planifiée
PR Automatique GitHub
Création automatique de Pull Requests · Validation humaine · Audit trail complet
4
Phase 4 — Vision
Classification IA
Dérive volontaire vs accidentelle · Whitelist intelligente · Mode Auto · Confidence score
07
Infrastructure
Homelab réel, pas une démo cloud
Comme Self-Healing v2, ce projet tourne sur mes serveurs physiques personnels.

Le scanner tourne sur srv-kubernetes (192.168.0.37) — cluster K3s hébergeant également n8n, ArgoCD, Traefik et une douzaine de SaaS exposés via Cloudflare Tunnel. PostgreSQL dédié sur NodePort 30301, API REST sur NodePort 30300. Le dashboard Grafana est servi depuis srv-monitor (192.168.0.29) avec datasource PostgreSQL directe.

C'est en cassant volontairement mes propres déploiements — les mêmes qui hébergent mes SaaS en production — que j'ai validé chaque type de dérive. Pas un cluster temporaire. Pas un environnement isolé. Infrastructure réelle.

Vous voulez détecter les
dérives de configuration ?

Contactez-moi pour discuter de la mise en place de GitOps Config Drift Detector sur votre infrastructure Kubernetes.

Me contacter →