Migrer vers une architecture GitOps pour Kubernetes

GitOps est une approche opérationnelle où l'état désiré de l'infrastructure est décrit dans Git, et un opérateur automatise la réconciliation avec l'état réel du cluster. Pour tout administrateur système Kubernetes certification CKA, cette migration GitOps Kubernetes représente un changement fondamental dans la gestion des déploiements.

TL;DR

La migration vers GitOps se déroule en quatre phases : structuration des repositories, déploiement de l'opérateur (ArgoCD ou Flux), migration progressive des applications, et retrait de l'ancien pipeline. Prévoyez 2 à 4 mois pour une migration complète.

Les professionnels qui veulent aller plus loin suivent la formation LFS458 Administration Kubernetes.

Selon le rapport CNCF GitOps Survey 2025, 91% des organisations cloud-native ont adopté GitOps. Cette transition CI/CD vers GitOps est devenue un standard industriel.

Qu'est-ce que GitOps et pourquoi migrer ? Perspective administrateur système Kubernetes certification CKA

GitOps est un paradigme opérationnel où Git devient la source de vérité unique pour l'état déclaratif de l'infrastructure. Un agent dans le cluster compare en continu l'état désiré (Git) avec l'état actuel et applique les corrections nécessaires.

Différences clés avec CI/CD traditionnel :

Comme le souligne Chris Aniszczyk, CTO de la CNCF : « Kubernetes is no longer experimental but foundational. Soon, it will be essential to AI as well. » GitOps renforce cette fondation.

À retenir : GitOps inverse le flux de contrôle. Le cluster devient actif (pull) au lieu de passif (push).

Le guide déploiement et mise en production Kubernetes présente les fondamentaux de cette approche.

Comment structurer vos repositories Git pour GitOps ?

Avant de migrer, définissez votre structure de repositories. Deux approches dominent :

Monorepo (un seul dépôt) :

├── apps/
│   ├── frontend/
│   │   ├── base/
│   │   └── overlays/
│   │       ├── dev/
│   │       ├── staging/
│   │       └── prod/
│   └── backend/
├── infrastructure/
│   ├── namespaces/
│   ├── rbac/
│   └── monitoring/
└── clusters/
    ├── dev-cluster/
    └── prod-cluster/

Multi-repo (séparation application/config) :

# Repo 1: application-code
# Repo 2: application-config (manifestes Kubernetes)
# Repo 3: cluster-config (infrastructure partagée)

À retenir : Commencez par un monorepo si votre équipe est petite (<10 personnes). Passez au multi-repo quand les besoins d'isolation augmentent.

La gestion multi-environnements Kubernetes détaille ces patterns.

Quelle plateforme GitOps choisir : ArgoCD ou Flux ?

Selon le rapport CNCF End User Survey 2025, ArgoCD détient 60% du marché GitOps contre 11% pour Flux.

Comparez les deux solutions :

Installez ArgoCD :

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Récupérez le mot de passe initial
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Ou installez Flux :

flux bootstrap github \
  --owner=my-org \
  --repository=fleet-infra \
  --branch=main \
  --path=clusters/prod-cluster \
  --personal

Le monitoring et dépannage Kubernetes couvre l'observabilité de ces outils.

Comment migrer progressivement vos applications vers GitOps ?

Phase 1 : Préparez l'infrastructure (semaines 1-2)

1. Déployez l'opérateur GitOps choisi
2. Configurez l'accès aux repositories Git
3. Définissez les namespaces et RBAC

# argocd-project.yaml
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: production
  namespace: argocd
spec:
  description: Production applications
  sourceRepos:
    - 'https://github.com/my-org/*'
  destinations:
    - namespace: '*'
      server: https://kubernetes.default.svc
  clusterResourceWhitelist:
    - group: '*'
      kind: '*'

Phase 2 : Migrez une application pilote (semaines 3-4)

Choisissez une application non critique pour valider le workflow.

# Application ArgoCD
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: pilot-app
  namespace: argocd
spec:
  project: production
  source:
    repoURL: https://github.com/my-org/k8s-config
    targetRevision: main
    path: apps/pilot-app/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: pilot-app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

À retenir : Activez selfHeal: true pour que l'opérateur corrige automatiquement les drifts manuels.

La formation administrateur système Kubernetes fondamentaux couvre ces concepts.

Comment gérer la transition CI/CD vers GitOps pour l'administrateur système Kubernetes certification CKA ?

Phase 3 : Modifiez vos pipelines CI (semaines 5-8)

Transformez vos pipelines push en pipelines image-tag :

Pipeline ancien (push) :

# ❌ CI pousse directement vers le cluster
deploy:
  script:
    - kubectl apply -f manifests/
    - kubectl set image deployment/app app=my-registry/app:$CI_COMMIT_SHA

Pipeline nouveau (GitOps) :

# ✅ CI met à jour le repo de config
update-manifests:
  script:
    - git clone https://github.com/my-org/k8s-config
    - cd k8s-config
    - kustomize edit set image my-registry/app:$CI_COMMIT_SHA
    - git commit -am "Update app to $CI_COMMIT_SHA"
    - git push

Le pipeline CI/CD pour Kubernetes détaille cette transformation.

Phase 4 : Migrez les applications restantes (semaines 9-12)

Procédez par vagues de criticité décroissante :

1. Applications internes non critiques
2. Services backend
3. APIs externes
4. Applications critiques (avec rollback plan)

Pour chaque application :

# 1. Créer l'Application ArgoCD
kubectl apply -f apps/my-app/argocd-application.yaml

# 2. Vérifier la synchronisation
argocd app sync my-app
argocd app wait my-app --health

# 3. Désactiver l'ancien déploiement CI
# Supprimer les étapes kubectl du pipeline

Comment gérer les secrets dans une architecture GitOps ?

Les secrets ne doivent jamais être commités en clair dans Git. Plusieurs solutions existent :

Exemple avec Sealed Secrets :

# Installer le contrôleur
helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm install sealed-secrets sealed-secrets/sealed-secrets -n kube-system

# Chiffrer un secret
kubectl create secret generic my-secret --dry-run=client --from-literal=password=s3cr3t -o yaml | \
  kubeseal --format=yaml > sealed-secret.yaml

Le sealed-secret peut être commité en toute sécurité :

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: my-secret
spec:
  encryptedData:
    password: AgBy3i4OJSWK+PiTySYZZA...

À retenir : Le chiffrement asymétrique de Sealed Secrets garantit que seul le cluster peut déchiffrer les secrets.

La checklist de mise en production Kubernetes inclut la sécurisation des secrets.

Comment valider et surveiller votre migration GitOps ?

Métriques de succès :

# Requête Prometheus pour le drift
sum(argocd_app_info{sync_status="OutOfSync"})

# Temps de synchronisation
histogram_quantile(0.95, sum(rate(argocd_app_sync_total[5m])) by (le))

Dashboards recommandés :

1. État de synchronisation par application
2. Fréquence des déploiements
3. Temps moyen de réconciliation
4. Alertes sur OutOfSync prolongé

# Alerte Prometheus
groups:
  - name: gitops
    rules:
      - alert: ApplicationOutOfSync
        expr: argocd_app_info{sync_status="OutOfSync"} == 1
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Application {{ $labels.name }} out of sync for 15min"

Le guide résoudre les erreurs de déploiement Kubernetes couvre le dépannage post-migration.

Checklist de migration GitOps

Avant de commencer :

• [ ] Inventaire des applications actuelles
• [ ] Choix ArgoCD vs Flux
• [ ] Structure de repositories définie
• [ ] Stratégie de gestion des secrets

Pendant la migration :

• [ ] Opérateur GitOps déployé et configuré
• [ ] Application pilote migrée et validée
• [ ] Pipelines CI modifiés (image-tag only)
• [ ] Équipes formées au nouveau workflow

Après la migration :

• [ ] Monitoring GitOps en place
• [ ] Alertes configurées
• [ ] Documentation mise à jour
• [ ] Anciens pipelines désactivés

Consultez la FAQ déploiement Kubernetes pour les questions courantes.

Passez à l'action : adoptez GitOps pour votre entreprise Kubernetes

La migration vers GitOps transforme la gestion des déploiements en un processus auditable, reproductible et automatisé. Avec 91% des organisations cloud-native ayant adopté cette approche, c'est devenu un standard de l'industrie.

Pour réussir cette transition :

• La formation LFS458 Administration Kubernetes couvre GitOps et les stratégies de déploiement sur 4 jours
• La formation LFD459 pour développeurs aborde l'intégration CI/CD
• Pour une introduction, découvrez Kubernetes, les fondamentaux

Contactez nos conseillers pour planifier votre parcours de formation.