Architecture
Vue d’ensemble de l’architecture d’Argo Workflows sur Kubernetes, détaillant les plans de contrôle et d’exécution, les composants, les intégrations avec des systèmes externes, ainsi que le cycle de vie des workflows pour des déploiements sécurisés et évolutifs.
Cet article explique l’architecture d’Argo Workflows : comment Argo fonctionne sur Kubernetes, comment les plans de contrôle et d’exécution sont séparés, et comment Argo s’intègre avec des systèmes externes (stockage d’artefacts, fournisseurs d’identité, monitoring, etc.). Comprendre ces composants et leurs interactions vous aide à concevoir des déploiements de workflows sécurisés et évolutifs sur Kubernetes.
À un niveau élevé, il existe deux plans logiques :
- Plan de contrôle (namespace Argo) — composants qui gèrent et orchestrent les workflows.
- Plan d’exécution (namespaces utilisateurs) — là où les tâches des workflows s’exécutent sous forme de pods Kubernetes.
Voici les principaux composants et leurs interactions.
Namespace Argo (plan de contrôle)¶
-
Argo Server : expose l’API REST Argo et l’interface web. Les utilisateurs et les CLI interagissent avec Argo Server ; il est généralement exposé via un LoadBalancer ou un Ingress pour un accès externe. Pour une haute disponibilité, Argo Server peut être déployé avec plusieurs réplicas.
-
Documentation : https://argoproj.github.io/argo-workflows/
-
Workflow Controller : moteur de réconciliation qui surveille les ressources personnalisées Workflow (CR), fait évoluer leur état et crée ou met à jour les ressources Kubernetes (Pods, ConfigMaps, Secrets, etc.) pour exécuter les étapes du workflow. Le contrôleur s’exécute dans le namespace Argo et nécessite des permissions RBAC via son ServiceAccount pour opérer sur les ressources du cluster.
Namespace utilisateur (plan d’exécution)¶
- Pods de workflow : lorsque le contrôleur planifie du travail, il crée des pods dans un namespace cible (souvent un namespace par workflow ou par locataire). Ces pods exécutent des conteneurs qui réalisent chaque étape du workflow. Les workflows volumineux ou parallèles génèrent généralement plusieurs pods (souvent un par étape). Le cycle de vie des pods est géré par le plan de contrôle Kubernetes (kube-scheduler, kubelet, etc.).
API Kubernetes (interactions avec le cluster)¶
- Les composants Argo (contrôleur, serveur, agents) interagissent avec le serveur API Kubernetes pour créer et gérer des ressources telles que Pods, Services, ConfigMaps, Secrets et PersistentVolumeClaims.
- L’accès est régi par RBAC Kubernetes et les ServiceAccounts attribués aux composants Argo.
Chemins d’interaction utilisateur¶
Les utilisateurs et les systèmes soumettent et gèrent les workflows via plusieurs interfaces :
| Interface | Cas d’usage | Lien |
|---|---|---|
| argo CLI | Soumettre, gérer et inspecter des workflows depuis le terminal | https://argoproj.github.io/argo-workflows/cli_installation/ |
| kubectl | Interagir directement avec les CR Workflow via les outils Kubernetes | https://kubernetes.io/docs/reference/kubectl/ |
| Interface Web | Visualiser et gérer les workflows dans un navigateur | https://argoproj.github.io/argo-workflows/ |
| Clients API / SDK | Automatiser la soumission et la récupération (ex : SDK Python) | https://github.com/argoproj/argo-workflows/tree/master/sdk/python |
| Webhooks / Événements | Déclenchement basé sur des événements via Argo Events ou intégrations | https://argoproj.github.io/argo-events/ |
Intégrations externes¶
Les workflows Argo s’appuient généralement sur des systèmes externes pour le stockage, l’authentification et l’observabilité. Exemples courants :
| Intégration | Objectif | Exemples |
|---|---|---|
| Stockage d’artefacts | Persister les entrées/sorties des workflows | Amazon S3, Google Cloud Storage, MinIO |
| Archivage des workflows | Conserver métadonnées, logs et historique | MySQL, PostgreSQL, backends compatibles S3 |
| Authentification / Autorisation | Gérer l’identité utilisateur et mapper vers RBAC | Fournisseurs OAuth/OIDC (OpenID Connect) |
| Monitoring / métriques | Exposer des métriques pour supervision et alertes | Prometheus + Grafana |
Liens et références :
- Documentation Kubernetes : https://kubernetes.io/docs/
- Argo Workflows : https://argoproj.github.io/argo-workflows/
- Argo Events : https://argoproj.github.io/argo-events/
- Prometheus : https://prometheus.io/
Résumé du cycle de vie¶
- Un utilisateur soumet un Workflow à Argo Server (via CLI, UI ou API).
- Le Workflow Controller détecte la nouvelle ressource et commence la réconciliation.
- Le contrôleur crée les pods Kubernetes nécessaires dans le namespace choisi pour exécuter chaque étape définie.
- Les pods lisent les entrées et écrivent les sorties dans les stockages d’artefacts ; le contrôleur surveille leur état et fait progresser le workflow.
- Une fois terminé, les métadonnées et logs peuvent être archivés, et des métriques sont émises pour le monitoring.
💡 Remarque : Le Workflow Controller réconcilie les ressources Workflow et doit disposer des permissions RBAC via son ServiceAccount pour créer et gérer les ressources nécessaires (pods, configmaps, secrets, PVC, etc.). Vérifiez les bindings Role/ClusterRole pour les workflows multi-namespace ou à l’échelle du cluster.