Argo

Argo is a family of open source tools that extends Kubernetes with workflows, GitOps delivery, progressive delivery, and event-driven automation.

The central mental model is four focused controllers sharing one Kubernetes foundation.

event arrives      code or config changes       release begins
      |                       |                        |
 Argo Events           Argo CD or Workflows       Argo Rollouts
      |                       |                        |
      +------------ Kubernetes API and resources ----+

Argo is not one product with four required modules. Each project solves a distinct control-plane problem. You can adopt one project, combine several, or use another tool at any boundary.

Why Argo exists

Kubernetes gives you an API for declaring and operating containerized workloads. It also lets projects add custom resource definitions and controllers.

A custom resource definition, or CRD, adds a new resource kind to the Kubernetes API. A controller watches resources and acts to move actual state toward the declared state.

The Argo projects use this extension model. You describe intent with Kubernetes resources. An Argo controller observes that intent, creates or changes other resources, and records status through the Kubernetes API.

This approach gives Argo several useful properties:

desired configuration can live in version control;
standard Kubernetes identity, namespaces, service accounts, and role-based access control remain relevant;
status is visible through Kubernetes APIs and Argo interfaces;
controllers can keep reconciling after the person or pipeline that submitted the change exits.

It also gives Argo Kubernetes-shaped costs. You must operate controllers, CRDs, permissions, upgrades, logs, metrics, and the workloads they create. Argo does not remove the need to understand the underlying cluster.

The four projects

Project	Question it answers	Primary object or model
Argo Workflows	How should containerized tasks run in dependency order?	`Workflow`, templates, Steps, or DAG
Argo CD	How should live application state converge on version-controlled desired state?	`Application` and reconciliation
Argo Rollouts	How should a new application version receive traffic and prove it is safe?	`Rollout`, strategy, and analysis
Argo Events	Which events should trigger which Kubernetes actions?	`EventSource`, `EventBus`, `Sensor`, and trigger

These responsibilities can form one delivery system, but the boundaries matter. Workflows execute task graphs. CD reconciles application state. Rollouts controls a release. Events connects external signals to actions.

Argo Workflows orchestrates containerized jobs

Argo Workflows is a container-native workflow engine for Kubernetes. It represents a workflow as a Kubernetes custom resource. Each task commonly runs in a container.

A Workflow has two roles. Its specification defines the work, and its status records one running or completed workflow instance. Reusable definitions can live in WorkflowTemplate or ClusterWorkflowTemplate resources. Scheduled execution uses CronWorkflow.

Every workflow specification has an entry point and templates. A template can define work, such as a container or script. It can also invoke other templates with one of two control structures:

Steps groups tasks into ordered stages. Tasks inside one stage can run in parallel.
A directed acyclic graph, or DAG, states dependencies among tasks. Tasks become eligible when their dependencies allow them to run.

Steps:  prepare -> [test-a, test-b] -> publish

DAG:              prepare
                  /     \
              test-a   test-b
                  \     /
                  publish

Parameters carry small values. Artifacts carry files or directories through a configured artifact repository. A workflow can also create or modify Kubernetes resources.

Common uses include machine-learning pipelines, data and batch processing, infrastructure automation, and continuous integration or delivery tasks. Kubernetes schedules the pods and supplies their runtime isolation. Argo Workflows supplies dependency control, retries, timeouts, status, and workflow-level visibility.

Use Workflows when the graph and execution history are first-class operational concerns. A plain Kubernetes Job or CronJob is usually clearer for one independent task with no meaningful dependency graph.

Argo CD reconciles Git with clusters

Argo CD is a declarative GitOps continuous delivery tool for Kubernetes. Git holds the desired application state. Argo CD compares that desired state with live cluster resources.

An Argo CD Application connects four ideas:

a source repository and revision;
a path, chart, or other manifest source;
a destination cluster and namespace;
a synchronization policy.

Argo CD can render plain YAML, Kustomize, Helm, Jsonnet, and configured plugins. It marks an application OutOfSync when live state differs from the target state. A manual or automated sync applies the target state.

Git revision -> manifest generation -> desired resources
                                         |
                                      compare
                                         |
cluster API -> live resources -----------+
                                         |
                                  sync and report health

This is reconciliation, not a one-time deployment command. The application controller keeps comparing desired and live state. That makes drift visible and can correct it when automated synchronization is enabled.

Argo CD focuses on delivery. A continuous integration system can build, test, scan, and publish an image. A separate change then updates the desired image reference in Git. Argo CD deploys the declared result.

The separation creates an audit trail, but Git alone does not make a deployment safe. Repository permissions, branch protection, manifest review, target-cluster permissions, secret handling, and synchronization policy all affect the real control boundary.

Argo Rollouts controls progressive delivery

A Kubernetes Deployment supports rolling updates. Argo Rollouts adds finer release control through a Rollout resource and controller.

The two central strategies are:

blue-green, which prepares a preview version and switches active service traffic after promotion;
canary, which advances a new version through defined steps, pauses, traffic weights, and optional analyses.

The Rollouts controller manages ReplicaSets in a way similar to a Deployment. A change to the pod template introduces a new ReplicaSet. The selected strategy determines how the new and stable ReplicaSets progress.

Traffic routing is optional. Without a traffic provider, replica ratios approximate canary exposure. With a supported ingress controller or service mesh, Rollouts can request finer traffic weights.

An analysis measures a release through a configured metrics provider or job. An AnalysisTemplate defines measurements and success or failure conditions. An AnalysisRun performs that analysis. The result can promote, pause, or abort a rollout according to its configuration.

Rollouts does not create meaningful service-level indicators for you. It queries the metrics and conditions you define. Weak signals can approve a bad release. Noisy signals can reject a good one. Progressive delivery is only as sound as the traffic path, measurements, thresholds, and rollback behavior you test.

Argo Events connects signals to actions

Argo Events is an event-driven automation framework for Kubernetes. It accepts events from sources such as webhooks, object storage, schedules, and messaging systems. It can trigger Argo Workflows, Kubernetes objects, HTTP requests, and other supported actions.

The event path has four parts:

external system -> EventSource -> EventBus -> Sensor -> trigger

An EventSource contains the configuration needed to consume an external event. It transforms the event into a CloudEvents representation and publishes it to the EventBus.

The EventBus is the transport between event sources and sensors. A Sensor subscribes to events, evaluates declared dependencies, and executes triggers when the dependency expression resolves.

This separation lets one event source feed several sensors. It also lets a sensor require more than one event before acting.

Argo Events decides when to request an action. The triggered system owns the action's execution semantics. If a sensor submits an Argo Workflow, Workflows then owns task execution and status. If it creates another Kubernetes resource, that resource's controller owns reconciliation.

How the projects combine

Consider a service release triggered by a source-code change:

Argo Events receives a repository webhook.
A sensor submits an Argo Workflow.
The workflow tests the change and publishes an image.
The delivery process updates a manifest repository.
Argo CD detects the new desired revision and synchronizes it.
Argo Rollouts moves traffic to the new version and evaluates metrics.

This is one possible composition, not a required architecture. A hosted CI system can replace Events and Workflows. Argo CD can deploy a normal Deployment without Rollouts. Rollouts can be updated by another delivery controller.

Choose each project because you need its control loop. Avoid adopting the full family only because the projects share a name.

Shared operating model

The projects use separate controllers and custom resources, but several operating questions repeat.

Identity and authorization

Controllers and workflow pods use Kubernetes service accounts. Their permissions determine which resources they can read or change.

Apply least privilege at each boundary:

separate controller permissions from workload permissions;
give each workflow the service account its tasks require;
restrict which repositories and clusters an Argo CD project may use;
restrict event sensors to the trigger resources they create;
treat access to submit arbitrary pods or resource templates as code-execution authority.

An Argo user interface role and Kubernetes role-based access control solve different authorization problems. Review both.

Reconciliation and status

Controllers act asynchronously. Creating a custom resource usually means you requested work, not that the work has finished.

Observe status and conditions on the custom resource. Then inspect the generated resources and controller logs. A successful API write proves only that the API accepted the object.

Namespaces and scope

Namespaced resources help divide ownership, but a controller can have wider cluster permissions. Decide whether controllers watch one namespace, managed namespaces, or the whole cluster. Match that scope to tenancy and operational ownership.

Capacity and failure

Argo controllers add control-plane load. Workflows create pods. CD reads repositories and cluster state. Rollouts queries metrics and manipulates traffic providers. Events operates event transport and trigger consumers.

Set resource requests and limits. Define concurrency and retention policies. Monitor controller queues, reconciliation errors, API pressure, generated workload state, and external dependencies.

Upgrades

CRDs and controllers evolve. Read each project's upgrade guide. Upgrade CRDs and controller versions in the documented order. Test stored resources, admission policies, integrations, and rollback procedures before production rollout.

The four projects have independent releases. A shared Argo name does not imply one synchronized version number.

Good fits and poor fits

Argo fits when Kubernetes is already the operating substrate and the desired automation maps naturally to Kubernetes resources and controllers.

Good fits include:

containerized batch or machine-learning task graphs;
Git-driven delivery to one or more Kubernetes clusters;
canary or blue-green releases that use measurable promotion criteria;
event-driven creation of workflows or Kubernetes resources;
teams that want automation state visible through Kubernetes APIs.

Argo is a weaker fit when:

the workload does not run on or control Kubernetes;
one small command has no graph, reconciliation, or release-control need;
a team cannot operate the added controllers and their dependencies;
the required orchestration centers on non-container runtime semantics;
a managed platform already supplies the needed control plane with less operational cost.

Argo does not replace Kubernetes security, observability, storage, networking, or capacity planning. It composes with those systems.

A practical learning path

Learn Kubernetes objects, custom resources, controllers, namespaces, service accounts, and role-based access control.
Read the Argo project overview and classify the four project responsibilities.
Run one small Argo Workflow. Compare its specification, status, pods, logs, parameters, and artifacts.
Create one Argo CD Application. Change Git, observe OutOfSync, inspect the diff, and synchronize manually.
Replace a test Deployment with a Rollout. Pause and promote a basic canary before adding traffic routing or analysis.
Connect one webhook EventSource to one Sensor and a harmless trigger. Trace the event through the EventBus.
Combine only two projects. Make the handoff and failure boundary explicit.
Add service accounts, quotas, network policy, retention, metrics, alerts, and backup procedures.
Test controller failure, external dependency failure, duplicate requests, rollback, and upgrade behavior.
Continue into the dedicated courses and official operator manuals for the projects you will run.