Argo Events: The basics and a quick tutorial

What is Argo Events?

Argo Events is a framework for automating workflows in Kubernetes. It can consume events from over 20 event sources, including Amazon Simple Storage Service (S3), Amazon Simple Queue Service (SQS), Google Cloud Platform Pub/Sub, webhooks, schedules, and messaging queues. Based on these events, you can trigger tasks such as:

• Kubernetes Objects
• Argo Workflows
• AWS Lambda
• Serverless workloads

In addition, Argo Events can:

• Support customization of business-level constraint logic to automate workflows.
• Manage all event types, ranging from linear and simple to multi-source and complex.
• Help maintain compliance with the CloudEvents specification.

This is part of an extensive series of guides about Kubernetes.

Argo Events components

Event source

Event sources define the required configurations for consuming events from sources such as AWS SQS, SNS, GCP Pub/Sub, and webhooks. An event source can transform events into a cloud event (per the CloudEvents spec) and forward them to the event bus.

Sensor

Sensors define the dependencies and triggers of events corresponding to inputs and outputs. Sensors listen to events on the event bus and manage event dependencies independently to resolve and execute triggers.

Eventbus

The eventbus is a custom resource in Kubernetes that acts as a transport layer and transmits events between event sources and sensors.

An event source publishes events, and a sensor subscribes to them to execute event triggers. Event-Sources publish the events while the sensors subscribe to the events to execute triggers. NATS streaming powers the current event bus implementation.

Triggers

Triggers are resources or workloads that sensors execute after resolving the event dependencies. Various types of triggers include:

• Argo Rollouts and Argo Workflows
• Kafka, NATS, and Azure Event Hubs messages
• Slack notifications
• AWS Lambda
• Apache OpenWhisk
• Kubernetes objects
• HTTP requests
• Custom triggers

How Argo Events Integrates with Argo Workflows

Argo Events is not so useful on its own. To provide value, it must be integrated with a system that can run workflow steps. Therefore, you can set up Argo Events together with Argo Workflows, which helps you orchestrate parallel Kubernetes jobs.

A workflow in Argo is a set of steps, which Kubernetes may execute sequentially or simultaneously. Each step in a workflow is a separate container. Whatever you can place in a container image, you can incorporate it into your workflow.

Argo Workflows lets you model a complex, multi-task workflow as a step sequence. You can use directed acyclic graphs (DAGs) to capture inter-task dependencies, allowing you to specify which tasks depend on other tasks and the order of execution.

A major advantage of Argo is the ability to run Kubernetes-native CI/CD pipelines, which allows you to set up your workflows in Kubernetes directly.

For more information about how Events work, you can reference the Argo Events project GitHub repository.

Quick tutorial: Getting started with Argo Events

Prerequisites

• Existing Kubernetes cluster running Kubernetes version 1.11 or higher
• kubectl command-line version 1.11.0 or higher

Step 1: Installation

Here is how to install Argo Events using several methods: kubectl, Helm Charts, and Kustomize, an open source tool for customizing Kubernetes configuration.

Installing Argo Events using kubectl

First, create a namespace called argo-events:

kubectl create namespace argo-events

Deploy Argo Events and dependencies like ClusterRoles, Sensor Controller and EventSource Controller using this command:

kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-events/stable/manifests/install.yaml

Note: You can install Argo Events with a validating admission webhook. This notifies you of errors when you apply a faulty spec, so you don’t need to check the CRD object status for errors later on. Here is how to install with validating admission controller:

kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-events/stable/manifests/install-validating-webhook.yaml

Using Helm chart

First install the Helm client—see instructions.

Create a namespace called argo-events, and create a Helm repository called argoproj as follows:

helm repo add argo https://argoproj.github.io/argo-helm

Note: Be sure to update the image version in values.yaml to v1.0.0. The Helm chart for Argo Events is maintained by the community and the image version could be out of sync.

Install the Argo Events Helm chart using the following command:

helm install argo-events argo/argo-events

Using Kustomize

First install Kustomize—see instructions.

If you use the cluster-install or cluster-install-with-extension folder as your base for Kustomize, add the following to kustomization.yaml:

bases:
  - github.com/argoproj/argo-events/manifests/cluster-install

If you use the namespace-install folder as your base for Kustomize, add the following to kustomization.yaml:

bases:
  - github.com/argoproj/argo-events/manifests/namespace-install

Step 2: Set up a sensor and Event Source

Now that Argo Events is installed, let’s set up a sensor and event source for the webhook. This will allow us to trigger Argo workflows via an HTTP Post request.

First, deploy the eventbus:

kubectl -n argo-events apply -f https://raw.githubusercontent.com/argoproj/argo-events/stable/examples/eventbus/native.yaml

Use this command to create an event source for the webhook:

kubectl -n argo-events apply -f https://raw.githubusercontent.com/argoproj/argo-events/stable/examples/event-sources/webhook.yaml

Finally, create the webhook sensor:

kubectl -n argo-events apply -f https://raw.githubusercontent.com/argoproj/argo-events/stable/examples/sensors/webhook.yaml

A Kubernetes service should now be created for the event source. You can see the new service by running kubectl get services.

Finally, expose the event source pod for HTTP access. For example, the following command exposes the event source pod on port 12000 using port forward.

kubectl -n argo-events port-forward <event-source-pod-name> 12000:12000

Step 3: Submit post request and see that a workflow runs

Let’s send a post request to http://localhost:12000/example—here is how to do it with curl – curl \-d '{"message":"this is my first webhook"}' \-H "Content-Type: application/json" \-X POST http://localhost:12000/example

Run this command to see if an Argo workflow is created, triggered by our POST request:

kubectl -n argo-events get wf

You should see a context message indicating your webhook is running. Finally, ensure the pod defined in the workflow is running in your cluster.

That’s it! You set up an event system that accepts POST requests and creates pods as part of an Argo workflow.

Help us continuously improve

Please let us know if you have any feedback about this page.

Send feedback