GitOps

DevOps 🟡 Mid

Définition

Méthode d'exploitation où l'état désiré de l'infrastructure et des déploiements est décrit de façon déclarative dans Git, seule source de vérité ; un agent (Argo CD, Flux) réconcilie en continu l'état réel du cluster avec le dépôt. Un déploiement devient une pull request, un retour arrière un « gît revert », et toute dérive manuelle est détectée et corrigée.

Analogie

Le thermostat de la maison : vous écrivez la température voulue, l'appareil compare en boucle avec la réalité et corrige, sans que personne n'aille toucher la chaudière à la main.

Exemple de code

# Le dépôt décrit l'état désiré ; l'agent (ex. Argo CD) l'applique.
# apps/prod/api/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base/api
images:
  - name: ghcr.io/acme/api
    newTag: "1.4.0"   # déployer = changer ce tag via une PR
# Retour arrière : git revert <sha> ; l'agent resynchronise.

Cas d'usage

Plusieurs clusters ou environnements à garder cohérents, audit des changements exigé, et fin des « kubectl apply » lancés depuis un poste.

Anti-pattern

Laisser le pipeline CI faire « kubectl apply » avec des identifiants cluster : c'est du push, pas du GitOps, et la dérive manuelle n'est jamais détectée.

Termes liés

#devops#kubernetes#interview

En entretien

Explique-moi GitOps.
L'état désiré de l'infrastructure et des déploiements est décrit de façon déclarative dans Git, seule source de vérité, et un agent comme Argo CD ou Flux réconcilie en continu l'état réel du cluster avec le dépôt. Un déploiement devient une pull request, un retour arrière un git revert.
Pourquoi un pipeline CI qui fait kubectl apply n'est pas du GitOps ?
Parce que c'est du push avec des identifiants cluster dans la CI, et toute dérive manuelle sur le cluster n'est jamais détectée ni corrigée automatiquement. Le vrai GitOps repose sur un agent qui compare en boucle l'état réel avec le dépôt, comme un thermostat.

Sources

Fiche mise à jour le 2026-09-27