Kubernetes CI/CD : construire des pipelines DevOps modernes

GitOps, ArgoCD, Tekton et sécurité : le guide complet

Les pipelines CI/CD traditionnels , Jenkins sur VM, scripts de déploiement SSH, configurations manuelles , génèrent trois pathologies chroniques, configuration drift entre environnements (production diverge de staging sans traçabilité), absence de rollback fiable (revenir en arrière nécessite intervention manuelle et diagnostic d'état), et scaling limité (ajouter un runner Jenkins implique de provisionner une VM, de configurer le réseau et d'installer les dépendances). La modernisation du CI/CD figure parmi les motifs les plus souvent cités par les équipes plateforme pour migrer vers Kubernetes, au même titre que les économies d'infrastructure et la haute disponibilité.

L'adoption de Kubernetes pour CI/CD transforme radicalement l'approche : les pipelines deviennent des ressources Kubernetes déclaratives (CRDs), l'isolation s'opère au niveau pod plutôt que VM, et le scaling horizontal automatique remplace le provisionnement manuel. Les outils cloud-native , Tekton pour CI, ArgoCD pour CD, Kaniko pour builds sans privilèges , implémentent le pattern GitOps où Git constitue la source de vérité unique. Cet article détaille les trois piliers du CI/CD Kubernetes (outils natifs, GitOps, sécurité), expose les stratégies de migration progressive depuis des pipelines legacy, et propose un framework de déploiement validé en production multi-tenant.

 

Ce qui vient de Hikube, et ce qui vient de l’écosystème. Hikube fournit le cluster conforme CNCF, le registry d’images et le VPC ; Argo CD, Flux, Kyverno et les outils de pipeline nommés ici sont des composants de l’écosystème que vous installez et exploitez dans votre cluster. Le choix entre eux vous appartient, et aucun n’est une fonction du catalogue. Périmètre managé : Kubernetes managé, registry, Container Registry.

Les 3 avantages clés de Kubernetes pour CI/CD

La migration CI/CD vers Kubernetes apporte trois bénéfices structurels qui compensent largement la complexité initiale accrue.

1. Isolation et reproductibilité : de la VM au pod

Les pipelines Jenkins traditionnels s'exécutent sur des agents VM partagés où les dépendances (Java, Node.js, Python) s'accumulent au fil des projets. Un pipeline nécessitant Node 18 peut échouer car l'agent exécutait précédemment un build avec Node 16 ayant installé des packages globaux incompatibles. La résolution nécessite un accès SSH sur l'agent, un nettoyage manuel et un redémarrage , temps d'interruption de 15-30 minutes par incident.

Kubernetes isole chaque build dans un pod dédié avec une image conteneur spécifique. Le pipeline Java s'exécute dans maven:3.8-openjdk-17, le pipeline Node dans node:18-alpine, sans risque de contamination croisée. Le pod se termine après build, ramenant l'environnement à état propre pour le build suivant. Cette isolation supprime par construction la classe d'échecs « works on my machine » : un build ne peut plus hériter d'un état laissé par le précédent.

Comparaison CI/CD : VM vs pod Kubernetes

Jenkins Agent VM :

• Temps de setup, 2-5 minutes (boot + connexion de l’agent)
• Isolation, Faible (dépendances partagées entre builds)
• Scaling, Manuel (provisionner de nouvelles VM)
• Cleanup, Nécessite une maintenance périodique
• coût idle, 24/7 si agents permanents

Kubernetes Pod CI :

• Temps de setup, 10-30 secondes (pull de l’image + scheduling du pod)
• Isolation, Forte (pod dédié par build, cleanup auto)
• Scaling, Automatique
• Cleanup, Pod terminé = ressources libérées immédiatement
• Coût idle, zéro

La reproductibilité découle directement de l'isolation, un build générant l'image app:v1.2.3 aujourd'hui génèrera exactement la même image demain car il s'exécute dans le même conteneur avec les mêmes dépendances figées. Les pipelines VM legacy souffrent de drift temporel : les mises à jour système, les patches de sécurité et les installations d'outils altèrent progressivement l'environnement, rendant les builds non-reproductibles.

2. Scaling élastique : absorber les pics sans surcoût

Prenons un pipeline Jenkins avec 10 agents VM fixes, occupés, disons, 30 % du temps à exécuter réellement des builds : les dix sont payés vingt-quatre heures sur vingt-quatre. Les pics (merge de feature branches en fin de sprint générant 50 builds simultanés) dépassent la capacité, les builds s'accumulent pendant 15-45 minutes. La solution traditionnelle : provisionner 20 agents permanents, doublant les coûts pour absorber des pics ponctuels.

Les pods Kubernetes apparaissent et disparaissent de manière élastique selon la charge. Un cluster avec Horizontal Pod Autoscaler (HPA) maintient 3 pods CI baseline (charge normale), scale à 25 pods durant les pics en 90 secondes, puis descale à 3 pods après 10 minutes d'inactivité. Le coût reflète la consommation réelle. Exemple de calcul, sur des hypothèses à remplacer par les vôtres : 3 pods × 22 heures/jour + 25 pods × 2 heures/jour ≈ 116 pod-heures/jour, contre 240 VM-heures/jour pour 10 VM en permanence, soit 52 % de moins. C'est une arithmétique, pas une mesure.

Tekton, framework CI cloud-native, exploite nativement ces capacités. Chaque PipelineRun génère des pods éphémères pour ses tasks, terminés automatiquement après exécution. Le gain vient de la suppression des ressources inactives permanentes : une flotte d'agents dimensionnée pour le pic est payée au pic vingt-quatre heures sur vingt-quatre, un pool de pods est payé au travail réellement exécuté. L'ampleur dépend de votre rapport pic sur moyenne, calculez-la sur vos propres relevés.

3. GitOps : Git comme source de vérité unique

Les pipelines traditionnels opèrent de manière impérative, un script exécute kubectl apply -f deployment.yaml pour déployer, sans garantie que l'état du cluster correspond au manifest Git après déploiement. Les modifications manuelles (kubectl edit deployment pour hotfix urgents) créent du drift invisible : le cluster diverge de Git, personne ne sait exactement quelle version tourne en production.

GitOps inverse le modèle, Git stocke l'état désiré (manifests Kubernetes), un agent (ArgoCD, Flux) synchronise continuellement le cluster vers cet état. Toute modification manuelle du cluster est détectée et annulée automatiquement (self-healing). Selon l'enquête CNCF sur Argo CD publiée le 24 juillet 2025, près de 60 % des clusters Kubernetes gérés par les répondants s'appuient sur Argo CD, pour un Net Promoter Score de 79 et 97 % de répondants l'utilisant en production, contre 93 % en 2023. L'enquête porte sur des utilisateurs en production et ne publie pas sa taille d'échantillon : c'est une part de clusters chez les répondants, pas une part de marché.

Les avantages mesurables : traçabilité complète (chaque changement production = commit Git avec auteur, timestamp, review), rollback trivial (revert commit Git, ArgoCD synchronise automatiquement), disaster recovery simplifiée (recréer cluster entier depuis le Git repo). Le MTTR baisse mécaniquement lorsque le retour arrière est un git revert sur un état déjà décrit, plutôt qu'une reconstruction manuelle : l'ampleur dépend de votre point de départ.

Architecture de référence : Tekton + ArgoCD

L'architecture moderne Kubernetes CI/CD sépare strictement les responsabilités, Tekton gère CI (build, test, publish d'images), ArgoCD gère le CD (déploiement, sync des manifests). Cette séparation respecte le principe GitOps : CI ne déploie jamais directement, il commit seulement les changements dans Git repo.

Tekton, CI cloud-native

Tekton, projet CNCF Continuous Delivery Foundation, implémente le CI via des Custom Resource Definitions (CRDs) Kubernetes. Les concepts clés : Task (étape atomique réutilisable, git clone, maven build, docker push), Pipeline (séquence de tasks chaînées), PipelineRun (instance d'exécution concrète d'un pipeline), Workspace (stockage partagé entre les tasks d'un pipeline).

Exemple Pipeline Tekton minimal :

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-push
spec:
  params:
    - name: git-url
      type: string
    - name: image-name
      type: string
  workspaces:
    - name: source-code
  tasks:
    - name: clone
      taskRef:
        name: git-clone          # Tâche du catalogue Tekton, version 0.9
      params:
        - name: url
          value: "$(params.git-url)"
      workspaces:
        - name: output
          workspace: source-code
    - name: build-image
      taskRef:
        name: kaniko             # Build sans privilèges, catalogue 0.6
      runAfter:
        - clone
      params:
        - name: IMAGE
          value: "$(params.image-name)"
      workspaces:
        - name: source
          workspace: source-code

Versions et prérequis. Le manifeste utilise l'API tekton.dev/v1, disponible depuis Tekton Pipelines v0.44 et portée par la série 1.x, en v1.15 LTS depuis août 2026. Les deux taskRef pointent vers des tâches du catalogue, à installer dans le cluster avant tout lancement : git-clone 0.9 (paramètre requis url, workspace output) et kaniko 0.6 (paramètre requis IMAGE, workspace source). Installation : tkn hub install task git-clone et tkn hub install task kaniko. Il faut aussi un PipelineRun qui fournisse le workspace source-code, par exemple un volumeClaimTemplate, et un secret de registre pour le push. Résultat attendu : le PipelineRun passe en Succeeded et l'image est poussée sous $(params.image-name). Ce manifeste a été validé syntaxiquement et structurellement (paramètres déclarés, références de tâches, liaisons de workspaces) ; il n'a pas été exécuté sur un cluster.

Tekton Hub fournit 300+ tasks réutilisables, git operations, language-specific builds (Maven, Gradle, npm), container builds (Kaniko, Buildah), security scans (Trivy, SonarQube), notifications (Slack, email). Les organisations créent des tasks custom pour des workflows spécifiques et les partagent via un Tekton Hub interne.

Kaniko mérite une attention particulière : outil de build d'images Docker sans un daemon Docker ni privilèges root. Traditionnellement, builder une image nécessite Docker daemon avec accès socket (/var/run/docker.sock), introduisant des risques sécurité. Kaniko construit des images directement depuis Dockerfile dans un conteneur non privilégié, idéal pour des pipelines Kubernetes sécurisés.

 

ArgoCD : GitOps CD automation

ArgoCD, projet CNCF graduated, implémente GitOps pour Kubernetes. Il opère comme un contrôleur dans le cluster, interrogeant périodiquement (par défaut toutes les 3 minutes) les Git repos configurés, comparant l'état souhaité (manifests Git) avec l'état réel (des ressources du cluster), et synchronisant les différences.

L'architecture ArgoCD comprend : Application (CRD définissant le repo Git source, le path, le cluster de destination, la sync policy), AppProject (regroupement logique d'applications avec RBAC et quotas), ApplicationSet (génération automatique de multiples applications depuis des templates). L'interface Web expose un dashboard en temps réel visualisant : status de sync par application (Synced, OutOfSync, Unknown), health status (Healthy, Progressing, Degraded, Suspended), historique des synchronisations avec les commits Git associés.

1. Workflow GitOps complet Tekton + ArgoCD :
   
   
   1. Le développeur pousse du code → GitHub
   2. Webhook GitHub → déclenche Tekton EventListener
   3. Tekton Pipeline,
      • Clone du dépôt de code source
      • Exécution des tests (JUnit, pytest)
      • Build de l’image (Kaniko)
      • Push image → registry de conteneurs (tag, git-sha)
      • Update image tag dans le dépôt de manifests Git
      • Commit + Push du dépôt de manifests
   4. ArgoCD détecte le nouveau commit dans le dépôt de manifests
   5. ArgoCD sync,
      • Compare manifests Git vs cluster state
      • Applique les changements (rolling update deployment)
      • Surveille l’état des replicas (replicas ready)
   6. Application déployée, ArgoCD status, Synced + Healthy

La séparation entre le repository de code source et le repository de manifests constitue une bonne pratique essentielle. Le repo manifests contient uniquement le YAML Kubernetes (deployments, services, configmaps) avec des références d'images précises (app:sha-abc123 plutôt que app:latest). Cette séparation permet un rollback indépendant, un contrôle d'accès plus granulaire et une meilleure auditabilité.

Intégration avec GitLab CI / GitHub Actions

Les organisations disposant déjà de pipelines GitLab CI ou GitHub Actions peuvent adopter progressivement Kubernetes pour leur CI/CD, sans réécrire entièrement les workflows. La stratégie hybride : GitLab/GitHub gère l'orchestration (triggers, conditionals, approvals), Tekton s'exécute comme backend pour des tasks Kubernetes-native.

GitLab CI peut déclencher le PipelineRun Tekton via kubectl create -f pipelinerun.yaml, attendre la complétion avec tkn pipelinerun logs --follow, récupérer le status exit. GitHub Actions propose une action officielle tektoncd/actions simplifiant l'intégration. Exemple : workflow GitHub Actions déclenchant Tekton pour build, puis ArgoCD pour déploiement sans quitter l'interface GitHub.

Sécurité CI/CD dans Kubernetes, 5 piliers

La sécurité CI/CD Kubernetes nécessite une approche multi-couches couvrant les images, les secrets, le RBAC, les network policies et l'admission control.

1. Images sécurisées et scan de vulnérabilités

Chaque image conteneur utilisée dans les pipelines (base images, application images) doit passer un scan vulnérabilités avant déploiement. Trivy, scanner open-source CNCF, détecte les CVE (Common Vulnerabilities and Exposures) dans images, filesystems et Git repos. Intégrer Trivy comme task Tekton bloque pipeline si des CVE critiques sont détectées.

Les base images officielles (alpine, debian-slim) reçoivent des patches de sécurité réguliers mais nécessitent de rebuild les applications pour en bénéficier. La stratégie d'automated rebuilds : Renovate Bot ou Dependabot créent automatiquement des pull requests quand nouvelles versions base images publiées, déclenchant pipelines CI validant compatibilité avant merge.

2. Gestion secrets : Vault, Sealed Secrets, External Secrets

Stocker les secrets (passwords, API keys, certificates) en clair dans des manifests Git viole les principes GitOps et les bonnes pratiques de sécurité. Trois approches émergent : HashiCorp Vault (un coffre-fort externe qui injecte les secrets au runtime dans les pods), Bitnami Sealed Secrets (des secrets chiffrés pouvant être commités dans Git, déchiffrés côté cluster), External Secrets Operator (synchronisation des secrets depuis AWS Secrets Manager, Azure Key Vault, etc.).

External Secrets Operator (ESO), projet CNCF incubating, unifie intégration avec 20+ backends de secrets. ESO synchronise secrets externes vers Kubernetes Secrets natifs, permettant aux applications de consommer les secrets via des volumes ou des variables d'environnement, sans modification du code. Le workflow est le suivant : les secrets sont stockés dans AWS Secrets Manager, le SecretStore d'ESO pointe vers AWS, ExternalSecret définit le mapping secret AWS → K8s Secret, ESO sync automatiquement avec refresh period configurable (par défaut 1h).

3. RBAC strict : limiter l'accès selon les rôles

Les ServiceAccounts Tekton et ArgoCD doivent disposer de permissions minimales (principle du moindre privilège). Une task Tekton buildant images requiert : get/list pods (pour monitorer les pods de build), create secrets (pour les credentials registry), mais PAS delete deployments ou create clusterroles.

ArgoCD RBAC distingue, Project Admin (créer/supprimer des applications dans project), Project Developer (sync les applications mais sans suppression), Read-Only (visualiser status). Les organisations multi-tenant créent des AppProjects par équipe avec un RBAC isolant les équipes : team-A ne peut sync les applications que dans le namespace team-a-*, team-B est limitée à team-b-*.

4. Network Policies : isoler les pipelines

Les pods Tekton s'exécutant dans le namespace tekton-pipelines n'ont pas besoin d'accéder à l'ensemble des namespaces du cluster. les Network Policies restreignent le trafic : les pipelines peuvent accéder au container registry (egress port 443 vers registry.company.com), Git server (port 22 SSH), mais restent bloquées vers les namespaces de production.

Politique "deny all" par défaut, tout trafic est bloqué, sauf les flux explicitement autorisés. Cette approche zero-trustempêche la compromission d’un pipeline (par exemple via une dépendance malveillante dans un build) de pivoter vers les services de production.

5. Policy Enforcement : OPA Gatekeeper, Kyverno

Admission controllers Kubernetes valident ressources avant création. Open Policy Agent (OPA) Gatekeeper et Kyverno implémentent des policies-as-code bloquant les configurations dangereuses : pods demandant privileged, true, containers running as root (runAsUser, 0), images sans tags précis (image, app:latest au lieu de app:v1.2.3).

Exemple de policy Kyverno bloquant des images non-signées, vérifier la signature des images via cosign/sigstore, rejeter PipelineRun référençant des images non-vérifiables. Cette policy force les équipes à signer leurs images après le build (via cosign sign), garantissant la provenance et l'intégrité.

Les 5 erreurs qui compromettent les pipelines Kubernetes

1. Réutiliser Docker-in-Docker (DinD) sans sécurisation

Symptôme : Utiliser pattern Docker-in-Docker (container avec Docker daemon) pour builder images dans pipelines Kubernetes, via volume mount du socket Docker /var/run/docker.sock depuis nœud host.

Impact : Accès socket Docker = accès root effectif sur nœud host. Un attaquant compromettant pipeline peut échapper container via Docker socket, exécuter conteneurs privilégiés, et contrôler nœud complet. CVE-2019-5736 (runc escape) démontre sévérité risque. Le mécanisme est direct : un build qui atteint le socket Docker dispose des droits du démon sur le nœud, ce qui ouvre un chemin de mouvement latéral dans le cluster. Les audits de sécurité Kubernetes recommandent de ne jamais exposer le socket Docker à des workloads non fiables.

Solution : Adopter Kaniko ou Buildah pour builds sans Docker daemon. Kaniko construit images dans conteneur unprivileged standard, sans accès host. Buildah similaire, maintenu Red Hat. Pour migration : remplacer task docker build par task Kaniko Tekton Hub (gcr.io/kaniko-project/executor), aucune modification Dockerfile requise. Tester builds staging avant production. Alternative avancée : Google Cloud Build, AWS CodeBuild (services managés éliminant la gestion de l’infrastructure de build).

2. Stocker secrets directement dans manifests Git

Symptôme : commiter des secrets (database passwords, API keys) en clair dans des manifests Kubernetes Git, en comptant sur un repo privé pour la sécurité.

Impact, l’historique Git expose les secrets indéfiniment, même après suppression (sauf réécriture destructrice). Les développeurs avec accès au repo peuvent exfiltrer les secrets de production. Les fuites accidentelles (repo rendu public, laptop volé avec clone local, partage d’écran lors d’une démo) exposent des credentials critiques. Une fuite peut rester longtemps invisible, et la rotation des secrets qui suit demande une coordination entre plusieurs équipes. Nous ne publions pas de délai moyen ni de coût d'incident : les chiffres qui circulent sur le sujet ne sont pas comparables entre eux, et le vôtre dépend de votre surface de secrets.

Solution : ne jamais commiter de secrets en clair. Adopter External Secrets Operator (ESO) : secrets stockés dans AWS Secrets Manager, Azure Key Vault ou HashiCorp Vault, synchronisés vers Kubernetes. Workflow : créer le secret dans le backend, définir un ExternalSecret, ESO crée automatiquement le Kubernetes Secret. Alternative : Sealed Secrets (chiffrement côté client, déchiffrement côté cluster). Pour la migration : auditer l’historique Git (outil, truffleHog), faire tourner tous les secrets exposés, implémenter ESO progressivement.

3. Ignorer les resource requests/limits sur les pods CI

Symptôme : déployer des PipelineRuns Tekton sans définir de resources.requests ni resources.limits CPU/memory, laissant les pods consommer les ressources cluster sans contrainte.

Impact, un build Maven consommant 8 Go de RAM sans limite peut provoquer un OOM (Out Of Memory) sur le nœud, impactant d’autres workloads. À l’inverse, des builds CPU intensifs peuvent monopoliser le CPU et dégrader les performances des applications. L’absence de requests empêche le scheduler de placer correctement les pods. Résultat : incidents de production causés par les pipelines CI (effet "noisy neighbors").

Solution : définir systematiquement des requests et des limits sur les tasks Tekton. Règle empirique : requests = besoins typiques (CPU 500m, memory 1Gi pour builds standard), limits = cap sécurité (CPU 2, memory 4Gi maximum). Utiliser des LimitRanges pour imposer des valeurs par défaut. Monitorer les métriques réelles (Prometheus metrics container_cpu_usage_seconds_total, container_memory_working_set_bytes), ajuster requests/limits basé sur P95 observé. Pour builds très variables (Maven avec gros projets), créer tasks avec resource tiers : small (1 CPU/2Gi), medium (2 CPU/4Gi), large (4 CPU/8Gi).

4. Synchronisation ArgoCD manuelle uniquement

Symptôme : configurer ArgoCD avec syncPolicy.automated, null (désactivé), requérant sync manuel UI ou CLI pour chaque changement manifests.

Impact : la promesse GitOps (Git = source de vérité, synchronisation automatique) n’est plus respectée. Les commits Git restent non déployés jusqu’à intervention humaine, créant un drift entre Git et le cluster. Des correctifs urgents nécessitent alors une intervention manuelle (par exemple en dehors des heures ouvrées), ce qui ralentit fortement les déploiements. Les rollbacks sont également impactés : un revert Git est effectué, mais le déploiement ne sera appliqué qu’au prochain déclenchement manuel. Sans synchronisation automatique, le délai de déploiement devient celui de la prochaine intervention humaine, pas celui du pipeline.

Solution : Activer auto-sync avec self-heal pour applications non-production, syncPolicy, automated, prune, true selfHeal, true. Le mode prune supprime les ressources supprimées du dépôt Git, et self-heal corrige automatiquement toute dérive côté cluster. Pour la production : activer d’abord l’auto-sync sans prune (phase de validation), puis activer prune après quelques semaines. Ajouter des fenêtres de déploiement (sync windows) et des notifications (Slack, email) pour encadrer les changements. Monitorer les métriques ArgoCD argocd_app_sync_total et alerter si une application reste OutOfSync plus de 15 minutes.

5. Négliger  le disaster recovery et les backup manifests

Symptôme : dépendre uniquement du dépôt Git des manifests pour le disaster recovery, sans sauvegarder les métadonnées ArgoCD (Applications, AppProjects, RBAC, configuration), ni tester les procédures de restauration.

Impact, en cas de perte du cluster (incident majeur, ransomware, perte etcd), les applications doivent être recréées manuellement dans ArgoCD. Le processus peut prendre plusieurs heures pour des dizaines d’applications, avec un risque élevé d’erreurs (mauvais namespace, credentials manquants, erreurs de configuration). La perte des configurations d’accès (RBAC, SSO) ralentit encore la reprise. Les organisations non préparées constatent des RTO réels de 12 à 24 heures, contre un objectif de 2 à 4 heures.

Solution : mettre en place des sauvegardes automatisées ArgoCD via un CronJob argocd-backup exportant les ressources vers un stockage externe (S3, Azure Blob, etc.). Utiliser la commande argocd admin export pour générer un backup complet. Tester la restauration régulièrement (par exemple trimestriellement) sur un cluster de test. Documenter un runbook de disaster recovery détaillant les étapes, les commandes et les accès nécessaires. Alternative avancée : utiliser ApplicationSet avec un Git generator, permettant de recréer les Applications automatiquement depuis Git.

Migration progressive, de Jenkins à Tekton + ArgoCD

La migration en mode big bang (réécrire tous les pipelines simultanément) échoue généralement en raison de la surcharge des équipes et du risque business. Une approche incrémentale sur 12 à 16 semaines permet de réduire les risques et de démontrer rapidement de la valeur.

Phase 1 (semaines 1-3) : Infrastructure et pilote

• Installer Tekton (Tekton Pipelines + Triggers) via Helm
• Installer ArgoCD via les manifests officiels
• Configurer un registre d’images (Harbor interne ou registry cloud)
• Sélectionner une application pilote (microservice simple, faible criticité)
• Créer un pipeline Tekton, clone → build → test → push image
• Créer une Application ArgoCD pour déployer depuis Git
• Valider le flux complet, commit → build → déploiement automatique

Phase 2 (semaines 4-8), Expansion progressive

• Migrer 5 à 10 applications par semaine
• Créer une bibliothèque de tasks Tekton réutilisables
• Standardiser la structure des dépôts Git
• Former les équipes (workshops + documentation)
• Implémenter le monitoring (Grafana, métriques pipelines)

Phase 3 (semaines 9-12), Sécurité et governance

• Déployer External Secrets Operator
• Migrer les secrets existants
• Implémenter les policies (Kyverno, OPA)
• Configurer le RBAC ArgoCD par équipe
• Activer auto-sync + self-heal
• Mettre en place les sauvegardes ArgoCD

Phase 4 (semaines 13-16), Optimisation et décommission Jenkins

• Analyser les métriques (lead time, MTTR, fréquence de déploiement)
• Optimiser les pipelines
• Migrer les applications critiques restantes
• Désactiver progressivement Jenkins
• Documenter les bonnes pratiques

Scénario de migration, SaaS B2B de 35 microservices

Ce que vous lisez. Ce n'est pas un client, ni un test que nous aurions instrumenté : c'est un scénario construit pour montrer un déroulé de migration réaliste et ses ordres de grandeur. Les durées, les effectifs et les coûts sont des hypothèses posées, cohérentes entre elles, pas des mesures. Les gains en fin de section en découlent par calcul. Si vous devez présenter des chiffres à un comité, reprenez la démarche avec vos relevés : votre lead time actuel, votre facture CI/CD, votre taux d'échec de rollback.

Scénario illustratif, et non un client : SaaS B2B suisse, 35 microservices (Java, Node.js, Python), 25 développeurs, Jenkins sur EC2 avec 12 agents permanents, coût infra CI/CD 8'500 CHF/mois, lead time, 4 à 6 heures.

Problèmes identifiés :

• Configuration drift production vs staging (hotfixes manuels non versionnés)
• Rollbacks complexes (scripts custom par service, échecs dans 20 % des cas)
• Agents Jenkins surchargés lors des pics (merges de feature branches le vendredi après-midi)
• Secrets dispersés (Jenkins credentials, AWS Secrets Manager, configurations hardcodées)

Déroulé du scénario (14 semaines, 1 Platform Engineer + 0,5 DevOps) :

Semaines 1-3 : Installation d'un cluster EKS dédié au CI/CD, Tekton Pipelines 1.15 LTS, Argo CD 3.5. Pilote : service "notification-service" (Node.js, faible criticité). Pipeline Tekton : clone → npm test → Kaniko build → trivy scan → push ECR. ArgoCD Application sync les manifests depuis dépôtk8s-manifests. Validation : 8 deploys test réussis, lead time 12 min (vs 45 min avec Jenkins).

Semaines 4-8 : Migration de 20 services (4-5/semaine). Création d'une bibliothèque de tasks : maven-build-test, node-build-test, python-build-test, trivy-scan, slack-notify. Formation des équipes : 3 workshops 2h, documentation Confluence (40 pages). Incidents de migration : 3 (configs env manquantes, résolues en <2h chacune).

Semaines 9-12 : External Secrets Operator + AWS Secrets Manager (rotation de 180 secrets en 3 semaines). Policies Kyverno  : blocage des pods privilegiés, exigence d’images signées (cosign), enforcement des resource limits. RBAC ArgoCD : 5 AppProjects (backend, frontend, data, infra, shared) avec permissions par équipe.

Semaines 13-14 : Migration des 15 services restants (dont 3 critiques). Auto-sync ArgoCD activé sur tous les environnements non-prod, puis en production après 2 semaines d'observation. Décommissionnement de 10/12 agents Jenkins (2 conservés pour des pipelines legacy complexes).

Résultats du scénario à six mois :

ROI, calculé et non observé. Les montants ci-dessous sont un exemple de calcul sur les hypothèses de ce scénario, pas un résultat mesuré chez un client, refaites-le avec vos propres chiffres avant de le présenter à un comité. Économie infra 4'300 CHF/mois × 12 = 51'600 CHF/an. Réduction des incidents (MTTR -82%, drift -100%) = gain productivité estimé 2 FTE/an ≈ 180'000 CHF. Investissement migration : 14 semaines × 1.5 FTE ≈ 45'000 CHF. ROI atteint en moins de 3 mois.

 

 

En résumé : 3 points clés

Kubernetes transforme le CI/CD de stateful à éphémère, d'impératif à déclaratif

Les pipelines Jenkins sur VM génèrent trois pathologies, configuration drift (les environnements divergent sans traçabilité), scaling manuel (provisionnement des agents pour absorber les pics), absence de reproductibilité (builds non déterministes dus au drift temporel du système). Kubernetes inverse ce modèle : pods éphémères (isolation garantie, nettoyage automatique), scaling élastique (création et suppression dynamique des pods selon la charge), GitOps déclaratif (Git = source de vérité, synchronisation continue via ArgoCD). La modernisation du CI/CD revient parmi les premiers motifs de migration vers Kubernetes. Les ordres de grandeur du scénario détaillé plus haut : lead time -95 %, fréquence de déploiement ×20, coût d'infrastructure CI/CD divisé par deux. Ce sont les chiffres d'un scénario, pas d'une mesure chez un client.

GitOps avec ArgoCD élimine la configuration drift et simplifie le disaster recovery

L'enquête CNCF de juillet 2025 relève Argo CD sur près de 60 % des clusters gérés par ses répondants, un NPS de 79 et 97 % d'utilisation en production. GitOps inverse le flux de déploiement : traditionnellement, le CI pousse vers le cluster (kubectl apply), générant du drift lorsque des modifications manuelles sont appliquées. GitOps repose sur un modèle pull : Git contient l’état désiré, et ArgoCD synchronise automatiquement le cluster. Bénéfices : traçabilité complète, rollback simplifié, disaster recovery facilité. GitOps raccourcit le retour arrière, qui devient un git revert, et supprime la dérive de configuration en la corrigeant automatiquement.

La sécurité CI/CD Kubernetes nécessite approche multi-couches non-négociable

Les pipelines Kubernetes introduisent une surface d’attaque spécifique : accès au socket Docker (escalade root sur le nœud hôte), secrets hardcodés dans Git (exposition des credentials), pods CI sans limites (risque de déni de service involontaire). L’approche sécuritaire repose sur plusieurs couches : images sécurisées (Kaniko, Trivy), gestion des secrets (External Secrets Operator, Vault), RBAC strict, Network Policies, admission control (OPA, Kyverno). Ces mesures sont essentielles : des incidents réels montrent des compromissions de pipelines CI impactant la production. Le coût d’un incident de sécurité critique est estimé entre 15'000 et 50'000 CHF, contre quelques semaines d’effort pour sécuriser correctement les pipelines.