Architecture

Vue d’ensemble de l’architecture Argo Events, décrivant EventSources, EventBus, Sensors et Triggers pour construire des workflows event-driven basés sur CloudEvents dans Kubernetes.

Argo Events est un framework d’automatisation de workflows event-driven pour Kubernetes. Argo Events permet de déclencher des actions tels que des Kubernetes Jobs, Argo Workflows, AWS Lambda, notifications ou requêtes HTTP personnalisées, ... en réponse à des événements provenant de nombreux systèmes externes. Ce guide explique les composants principaux, leurs responsabilités et le flux de bout en bout pour construire des workflows event-driven fiables sur Kubernetes.

Composants principaux¶

Argo Events s’articule autour de quatre composants principaux qui séparent la capture, le transport et la réaction aux événements :

Chaque composant a une responsabilité claire:

• EventSources: Gèrent l’ingestion et la normalisation des événements.
• EventBus: Fournit un transport découplé dans un modèle pub/sub entre publishers et subscribers.
• Sensors: Consomment les événements, évaluent les conditions et orchestrent l'activation des Triggers.
• Triggers: Exécutent des actions spécifiques en réponse aux événements (par exemple, lancer un Workflow, déployer un objet K8s, appeler une API externe).

EventSources¶

Les EventSources sont les points d’entrée du système — elles se connectent aux producteurs externes et convertissent leurs payloads natifs en un format interne cohérent.

Types courants d’EventSources :

• Webhooks (GitHub, GitLab, HTTP générique)
• Notifications de stockage cloud (par ex. AWS S3)
• Systèmes de messagerie (AWS SQS, SNS, Kafka, GCP Pub/Sub)
• Schedulers (événements cron basés sur le temps)
• Fournisseurs personnalisés ou services tiers

Responsabilités des EventSources :

• Écouter/consommer les événements des systèmes externes
• Normaliser les événements au format CloudEvents (id, source, type, time, data, etc.)

Standardiser les événements selon la spécification CloudEvents simplifie le traitement en aval. CloudEvents fournit une enveloppe prévisible permettant aux Sensors et autres consommateurs de traiter les événements sans logique de parsing spécifique à chaque source.

Exemple minimal d’EventSource (webhook) YAML :

apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: webhook-source
spec:
  webhook:
    example:
      endpoint: /payload
      port: "12000"
      method: POST
      url: /payload

EventBus¶

la couche de transport

Après qu’un EventSource convertisse un événement entrant en CloudEvents, il publie l’événement sur l’EventBus. L’EventBus découple producteurs et consommateurs en utilisant un modèle publish/subscribe et fournit durabilité et scalabilité pour la livraison des événements.

Implémentations populaires de l’EventBus :

Argo Events utilise ces systèmes de messaging pour router les CloudEvents des EventSources vers les Sensors, permettant aux EventSources de publier sans connaître les Sensors consommateurs.

NATS Streaming (STAN) est déprécié. Pour les nouvelles installations, privilégiez NATS JetStream ou Kafka, qui offrent une meilleure persistance et des sémantiques de streaming plus robustes.

Sensor¶

le consommateur et orchestrateur d’événements

Les Sensors s’abonnent à l’EventBus pour recevoir les CloudEvents. Un Sensor définit :

• Dépendances d’événements : quels événements (et conditions) doivent arriver
• Évaluation des dépendances : logique pour combiner ou matcher les événements (un, plusieurs ou groupés)
• Triggers : quelles actions exécuter lorsque les dépendances sont satisfaites

Responsabilités du Sensor :

• Surveiller en continu l’EventBus pour les CloudEvents correspondants
• Évaluer les expressions et conditions de dépendance
• Exécuter un ou plusieurs triggers avec transformation de payload optionnelle, retries et backoff

Types courants de triggers :

Exemple YAML de Sensor qui attend un événement et déclenche un Kubernetes Job :

apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: simple-sensor
spec:
  dependencies:
    - name: example-dep
      eventSourceName: webhook-source
      eventName: example
  triggers:
    - template:
        name: k8s-job-trigger
        k8s:
          group: batch
          version: v1
          resource: jobs
          operation: create
          source:
            resource:
              apiVersion: batch/v1
              kind: Job
              metadata:
                generateName: triggered-job-
              spec:
                template:
                  spec:
                    containers:
                      - name: hello
                        image: busybox
                        command: ["echo", "event triggered"]
                    restartPolicy: Never

Les Sensors supportent les transformations de payload (patch des triggers avec les données de l’événement), les politiques de retry/backoff, et les triggers conditionnels pour modéliser des workflows event-driven complexes.

Trigger¶

Flux de bout en bout (résumé)¶

1. Un système ou service externe génère un événement.
2. L’EventSource capture l’événement et le convertit au format CloudEvents.
3. L’EventSource publie le CloudEvent sur l’EventBus.
4. Le Sensor, abonné à l’EventBus, reçoit le CloudEvent et évalue ses dépendances.
5. Une fois les dépendances du Sensor satisfaites, il exécute le(s) trigger(s) configuré(s).

Cette séparation (capture → normalisation → transport → évaluation → trigger) forme une architecture fiable et découplée pour construire des automatisations event-driven sur Kubernetes.

Bonnes pratiques et recommandations¶

• Utiliser CloudEvents partout pour garder les payloads cohérents.
• Choisir un EventBus avec la durabilité et le débit nécessaires (JetStream ou Kafka pour la persistance).
• Configurer les politiques de retry et backoff des Sensors pour les échecs transitoires.
• Garder les EventSources légers ; déporter le traitement lourd vers les consommateurs ou workflows en aval.
• Surveiller la santé et la rétention de l’EventBus pour éviter la perte de données ou le backpressure.

Liens et références¶

• Argo Events sur GitHub
• Spécification CloudEvents
• Projet NATS
• Apache Kafka
• Documentation Kubernetes