From an Event to a Workflow, from a Chart to Manifests
In one line
Argo Events runs on four parts: an EventSource converts an outside event to a CloudEvent and puts it on the EventBus, and a Sensor receives it as a dependency and runs a Trigger. Argo CD uses Helm only to inflate manifests with helm template and manages the lifecycle itself, and if there is a kustomization.yaml in path, it renders with Kustomize.
Why this was needed
Requirements such as "run the pipeline when something is pushed to the repository" or "start a processing workflow when a file arrives in S3" have an event first and execution after. The workflow engine itself does not listen for events. Argo Events handles this front end: it receives events from more than 20 event sources (webhooks, S3, schedules, message queues, GCP PubSub, SNS, SQS, and so on) and runs Kubernetes objects, Argo Workflows, and serverless workloads. CAPA's Events domain (12%) asks what each of these four components is responsible for and in what order events flow.
The problem on the Argo CD side is different. Teams manage deployables with Helm charts or Kustomize overlays, and if you do not know how Argo CD turns them into manifests, you cannot find the cause of problems such as "I changed values but it was not reflected" or "the app is always OutOfSync." The Helm & Kustomize item of the Argo CD domain (34%) covers this part.
How it works
The four parts of Argo Events
| Component | Role | Definition in the documentation |
|---|---|---|
| EventSource | Receives outside events, converts them to CloudEvents, and sends them to the EventBus | Configuration that consumes events from external sources such as AWS SNS, SQS, PubSub, and Webhook |
| EventBus | The transport layer connecting EventSources and Sensors | Three implementations: NATS (deprecated), Jetstream, and Kafka |
| Sensor | A set of event dependencies (inputs) and triggers (outputs) | A dependency manager that listens to the EventBus and runs triggers when dependencies are resolved |
| Trigger | The resource or workload that runs when dependencies are resolved | Argo Workflow, K8s objects, HTTP, Lambda, Kafka/NATS messages, Slack, Argo Rollouts, Log, and so on |
The flow goes like this. When you create a webhook EventSource, an event-source Pod and a Service appear (port 12000 in the example), and if you POST to it, the event is converted to a CloudEvent and put on the EventBus. The Sensor writes in dependencies "which event from which EventSource" it is waiting for, and in triggers what to run. The log of a triggered workflow prints the event's context (type, source, eventID, time, subject) together with data encoded in base64. With parameterization you can take a particular key of the event and pass it as a workflow argument, and with a trigger policy you look at the status of the executed object and decide whether to continue or stop.
The EventBus is a namespace resource, and for an EventSource and a Sensor to work, there must be an EventBus in that namespace. By convention you put one named default, and to use another name or to have several, you write eventBusName in the spec of the EventSource and the Sensor to match them up. If the workflow logic is already in a WorkflowTemplate, the Sensor does not need to write the steps again and instead submits a Workflow that references it with workflowTemplateRef.
triggers:
- template:
name: argo-workflow-trigger
argoWorkflow:
operation: submit
source:
resource:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata: {generateName: from-template-}
spec:
workflowTemplateRef: {name: workflow-template-print-message}
Argo CD and Helm — it only inflates
One sentence of the documentation is the key. "Helm is used only to inflate charts with helm template, and the application's lifecycle is managed by Argo CD, not Helm." A chart in a Helm repository is specified with source.chart, repoURL, and targetRevision (for OCI, without the oci:// prefix), and a chart in Git is specified with path. There are several ways to supply values, and the precedence is fixed.
낮음 valueFiles → values → valuesObject → parameters 높음
(여러 파일이면 뒤에 적은 파일이 이김) (차트의 values.yaml 은 그보다 아래)
The Korean text in this code block says, in order, that precedence runs from low on the left to high on the right, that when there are several files the file written later wins, and that the chart's own values.yaml ranks below all of these.
You can list several valueFiles, and a file written later overrides the earlier ones. If a file is missing, Helm raises an error, but you can ignore that with ignoreMissingValueFiles: true, which is used for the "defaults plus override if present" pattern. A glob (envs/*.yaml) expands in lexicographic order, so it is recommended to show the order with number prefixes such as 00-defaults.yaml and 10-region.yaml. Values from a repository different from the chart's are fetched with multiple sources (sources[].ref and $ref/path). parameters corresponds to --set and can force string treatment with forceString, and fileParameters is --set-file.
I am carrying over three traps from the documentation. First, the release name is by default the same as the Application name, and if you change it with releaseName, it can diverge from the app.kubernetes.io/instance label that Argo CD attaches for tracking and break selectors. Second, Argo CD cannot tell whether it is a first install or an upgrade and every operation is a sync, so pre-install and pre-upgrade hooks run at the same time. If you define even one Argo CD hook, all Helm hooks are ignored. Third, a chart that generates values with randAlphaNum gets a different value on every comparison, so it is always OutOfSync, and you must pin the value. To keep a chart from installing CRDs, use skipCrds: true.
Argo CD and Kustomize
If there is a kustomization.yaml where repoURL and path point, Argo CD renders with Kustomize. To use an overlay, set path to the overlay directory. In the Application's source.kustomize you can write namePrefix, nameSuffix, images (image overrides), replicas, commonLabels, commonAnnotations, namespace, patches, components (from 2.10), and so on. patches works by the same logic as the patches of a Kustomization file and is merged into the existing patches. The documentation gives an example of using it with an ApplicationSet, showing how, instead of making an overlay for each cluster, you can put generator attributes ({{.name}}) into the template's kustomize.patches and solve it in one go. If the remote base is private, it inherits the credentials of the app's repository, but it cannot access repositories that need different credentials.
source:
path: kustomize-guestbook
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: master
kustomize:
patches:
- target: {kind: Deployment, name: guestbook-ui}
patch: |-
- op: replace
path: /spec/template/spec/containers/0/ports/0/containerPort
value: 443
What it looks like in the field
The most common first failure in Argo Events is "I created the EventSource and Sensor but the Pods do not come up." The documentation's troubleshooting procedure is to first look at the Status of the EventSource and Sensor objects, then check the service account's Role/RoleBinding, and then look at the logs of the two controllers. If there is no EventBus in the namespace, nothing works, so check that first.
In Argo CD, you get the question "I can't see all the values in the UI." The documentation lists it as a known bug: the UI shows only parameters and does not display values supplied through values/valuesObject. The rendering is exactly right, so no value is actually missing, and the documentation offers the workaround of using parameters if you want it visible at a glance.
What to check in the next quiz
It asks about the roles of the four components, the three EventBus implementations, the fact that the EventBus is a namespace resource and eventBusName, the precedence of Helm values and ignoreMissingValueFiles, the label problem when you change releaseName, the traps of hooks and randAlphaNum, and the Kustomize detection condition and kustomize.patches. References: Argo Events Architecture, EventBus, Sensor, Argo CD Helm, Argo CD Kustomize.