Livraison continue Kubernetes : pipelines GitOps avec ArgoCD et Flux

La livraison continue sur Kubernetes a évolué bien au-delà de la simple kubectl apply commandes. Les équipes modernes adoptent GitOps, un paradigme qui utilise Git comme source unique de vérité pour l'infrastructure déclarative et la configuration des applications. En combinant les principes GitOps avec des outils tels qu'ArgoCD et Flux CD, les organisations peuvent obtenir des pipelines de déploiement fiables, vérifiables et automatisés qui s'adaptent à tous les clusters et environnements.

Ce guide couvre l'architecture, la configuration et les meilleures pratiques pour créer des pipelines de livraison continue de niveau production sur Kubernetes à l'aide de l'approche GitOps.

Principes GitOps

GitOps repose sur quatre principes fondamentaux qui changent fondamentalement la façon dont les équipes gèrent les déploiements :

• Configuration déclarative - L'ensemble de l'état souhaité de votre système est décrit de manière déclarative. Pour Kubernetes, cela signifie les manifestes YAML, les graphiques Helm ou les superpositions Kustomize stockées dans Git.
• Version contrôlée - Git sert de source unique de vérité. Chaque modification passe par une pull request, fournissant une piste d'audit complète et permettant des restaurations faciles en annulant les validations.
• Réconciliation automatisée - Un agent exécuté dans le cluster compare en permanence l'état souhaité dans Git avec l'état réel dans le cluster et réconcilie automatiquement toute dérive.
• Observation continue - Le système surveille en permanence à la fois le référentiel Git et l'état du cluster, alertant en cas de divergence et garantissant que le cluster correspond toujours à la configuration déclarée.

Ces principes éliminent les étapes de déploiement manuel, réduisent les erreurs humaines et fournissent un flux de travail cohérent quelle que soit la complexité du cluster.

Architecture et configuration d'ArgoCD

ArgoCD est l'outil GitOps le plus largement adopté pour Kubernetes. Il fournit une interface utilisateur Web puissante, une CLI et API pour gérer les déploiements d'applications sur les clusters.

Composants de base

ArgoCD se compose de plusieurs composants clés qui fonctionnent ensemble :

• Serveur API - Expose un gRPC/REST API et sert l'interface utilisateur Web. Gère l'authentification, le RBAC et les intégrations externes.
• Serveur de référentiel - Clone les référentiels Git et génère des manifestes Kubernetes à partir de graphiques Helm, Kustomize ou YAML simple.
• Contrôleur d'applications - Surveille en permanence les applications en cours d'exécution et compare l'état actif à l'état souhaité dans Git.
• Rédis - Fournit une mise en cache pour le serveur de référentiel et le contrôleur d'application.

Installation

Déployez ArgoCD sur votre cluster à l'aide des manifestes officiels ou de la charte Helm :

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

# Or via Helm
helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd \
  --namespace argocd \
  --create-namespace \
  --set server.service.type=LoadBalancer

Définir des applications

ArgoCD utilise un Application ressource personnalisée pour définir quoi déployer et où. Voici une définition d’application typique :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/k8s-manifests.git
    targetRevision: main
    path: apps/my-web-app/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

Le syncPolicy.automated La section permet la synchronisation automatique. Le prune L'option supprime les ressources qui ne sont plus définies dans Git, tandis que selfHeal annule les modifications manuelles apportées directement au cluster.

Flux CD : une approche alternative

Flux CD adopte une approche architecturale différente de GitOps. Plutôt qu'un serveur centralisé avec une interface utilisateur, Flux fonctionne comme un ensemble de contrôleurs Kubernetes qui gèrent chacun un problème spécifique.

Composants de flux

• Contrôleur source - Gère les référentiels Git, les référentiels Helm et les sources d'artefacts OCI.
• Personnaliser le contrôleur - Applique les superpositions Kustomize et les manifestes YAML simples.
• Contrôleur de barre - Gère les versions des graphiques Helm via HelmRelease ressources personnalisées.
• Contrôleur de notifications - Gère les événements entrants et sortants, en s'intégrant à Slack, Teams et aux fournisseurs de webhooks.
• Contrôleurs d'automatisation d'image - Analysez les registres de conteneurs et mettez à jour les manifestes lorsque de nouvelles images sont disponibles.

Amorçage de flux

# Bootstrap Flux on a cluster with a GitHub repository
flux bootstrap github \
  --owner=myorg \
  --repository=fleet-infra \
  --branch=main \
  --path=clusters/production \
  --personal

# Define a HelmRelease
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx-ingress
  namespace: ingress-system
spec:
  interval: 5m
  chart:
    spec:
      chart: ingress-nginx
      version: "4.x"
      sourceRef:
        kind: HelmRepository
        name: ingress-nginx
        namespace: flux-system
  values:
    controller:
      replicaCount: 3
      metrics:
        enabled: true

ArgoCD vs Flux : quand choisir lequel

ArgoCD est idéal lorsque vous avez besoin d'une interface utilisateur Web riche pour la visibilité, d'une architecture mutualisée avec RBAC à granularité fine et d'un plan de gestion centralisé. Flux brille dans les environnements qui préfèrent une architecture légère basée sur un contrôleur, ont besoin de capacités d'automatisation d'image ou souhaitent une intégration plus approfondie avec l'écosystème Kubernetes API.

Gestion des graphiques de barre dans GitOps

Les graphiques Helm sont le format de packaging de facto pour les applications Kubernetes. Dans un workflow GitOps, la gestion des valeurs Helm dans tous les environnements nécessite une organisation minutieuse.

# Repository structure for multi-environment Helm management
k8s-manifests/
  base/
    my-app/
      Chart.yaml
      values.yaml          # Default values
      templates/
        deployment.yaml
        service.yaml
        ingress.yaml
  environments/
    dev/
      my-app/
        values.yaml        # Dev overrides
    staging/
      my-app/
        values.yaml        # Staging overrides
    production/
      my-app/
        values.yaml        # Production overrides

ArgoCD et Flux prennent en charge Helm de manière native. ArgoCD restitue les graphiques côté serveur via son serveur de référentiel, tandis que Flux utilise le SDK Helm directement dans son contrôleur Helm.

Stratégies de déploiement

Choisir la bonne stratégie de déploiement minimise les risques et garantit des versions sans temps d'arrêt.

Mises à jour progressives

La stratégie Kubernetes par défaut. Les pods sont progressivement remplacés par de nouvelles versions. Configurer maxSurge et maxUnavailable pour contrôler la vitesse de déploiement.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: app
          image: myapp:v2.1.0
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

Déploiements bleu-vert

Exécutez deux environnements identiques (bleu et vert). Déployez la nouvelle version sur l'environnement inactif, vérifiez-la, puis changez de trafic. Cela permet une restauration instantanée en revenant à l'environnement précédent. Implémentez-le avec des sélecteurs d'étiquettes de service ou la gestion du trafic Istio.

Déploiements Canary

Acheminez progressivement un petit pourcentage du trafic vers la nouvelle version, en augmentant ce pourcentage à mesure que la confiance augmente. Des outils tels que Flagger et Argo Rollouts automatisent l'analyse Canary avec une promotion basée sur des métriques.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 30
        - pause: { duration: 5m }
        - setWeight: 60
        - pause: { duration: 5m }
      canaryService: my-app-canary
      stableService: my-app-stable
      trafficRouting:
        istio:
          virtualService:
            name: my-app-vsvc
            routes:
              - primary

Restaurations automatisées

GitOps simplifie les restaurations : annulez simplement le commit Git. Cependant, les restaurations automatisées basées sur des contrôles de santé fournissent un filet de sécurité supplémentaire.

ArgoCD prend en charge les restaurations automatisées via son système de synchronisation et d'évaluation de l'état de santé. Si une application entre dans un état dégradé après une synchronisation, ArgoCD peut automatiquement revenir au dernier bon état connu.

Pour des scénarios de restauration plus sophistiqués, Argo Rollouts et Flagger peuvent analyser les métriques Prometheus, exécuter des tests automatisés et abandonner les déploiements qui montrent des performances dégradées.

Gestion des secrets avec des secrets scellés

Stocker des secrets dans Git est un défi crucial pour GitOps. Sealed Secrets résout ce problème en chiffrant les secrets qui ne peuvent être déchiffrés que par le contrôleur exécuté dans le cluster cible.

# Install Sealed Secrets controller
helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm install sealed-secrets sealed-secrets/sealed-secrets \
  --namespace kube-system

# Encrypt a secret
kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password=s3cure-p@ss \
  --dry-run=client -o yaml | \
  kubeseal --format yaml > db-credentials-sealed.yaml

Le résultat SealedSecret la ressource peut être validée en toute sécurité dans Git. Seul le contrôleur Sealed Secrets du cluster cible détient la clé privée nécessaire pour le déchiffrer. Les approches alternatives incluent External Secrets Operator (pour extraire depuis AWS Secrets Manager, HashiCorp Vault, etc.) et SOPS pour le chiffrement au niveau des fichiers.

Surveillance des déploiements

La visibilité sur l'état du déploiement est essentielle pour les pipelines GitOps de production. Mettre en œuvre une surveillance à plusieurs niveaux :

• Métriques ArgoCD - ArgoCD expose les métriques Prometheus pour l'état de synchronisation, la santé et la durée de l'opération. Créez des tableaux de bord Grafana pour suivre la fréquence de déploiement et les taux d'échec.
• Événements Kubernetes - Surveillez la planification des pods, l'extraction d'images et les événements de sonde de préparation pour détecter les problèmes le plus tôt possible.
• Vérifications de l'état des applications - Configurez des vérifications de santé personnalisées dans ArgoCD à l'aide de scripts Lua pour définir ce que « sain » signifie pour vos ressources spécifiques.
• Alerte - Intégrez les notifications ArgoCD avec Slack, PagerDuty ou par courrier électronique pour alerter en cas d'échec de synchronisation, de dégradation de la santé ou de détection de dérive.

# ArgoCD Notification ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  trigger.on-sync-failed: |
    - when: app.status.operationState.phase in ['Error', 'Failed']
      send: [slack-notification]
  template.slack-notification: |
    message: |
      Application {{.app.metadata.name}} sync {{.app.status.operationState.phase}}.
      Revision: {{.app.status.sync.revision}}
  service.slack: |
    token: $slack-token
    channel: deployments

Livraison multicluster

À mesure que les organisations évoluent, le déploiement sur plusieurs clusters devient nécessaire. ArgoCD prend en charge la gestion multi-cluster de manière native en enregistrant des clusters externes. Flux y parvient grâce à un cluster de gestion qui amorce les clusters de charge de travail.

Le contrôleur ApplicationSet d'ArgoCD est particulièrement puissant pour les scénarios multi-clusters. Il peut générer des ressources d'application de manière dynamique en fonction de listes de clusters, de répertoires Git ou d'événements de demande d'extraction.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-app-set
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'my-app-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/k8s-manifests.git
        targetRevision: main
        path: 'apps/my-app/overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: my-app

Conclusion

GitOps avec ArgoCD ou Flux CD fournit une base solide pour la livraison continue Kubernetes. En traitant Git comme la source de vérité, en automatisant le rapprochement et en tirant parti de stratégies de livraison progressives, les équipes peuvent déployer en toute confiance et se remettre rapidement des échecs. Commencez par une configuration simple à cluster unique, établissez la structure de votre référentiel Git et adoptez progressivement des modèles avancés tels que les déploiements Canary, la gestion multicluster et les politiques de restauration automatisées à mesure que votre plate-forme évolue.

L'investissement dans l'infrastructure GitOps porte ses fruits grâce à une fiabilité améliorée, une réponse plus rapide aux incidents, des pistes d'audit complètes et une expérience de développement qui rend les déploiements aussi simples que la fusion d'une pull request.