Argo
Argo is a suite of open-source Kubernetes-native tools for running workflows, managing deployments, handling events, and delivering applications through GitOps. Its components share a declarative, container-first design built on custom resource definitions.
itCloud native tools and technologies | OpenSkills.info
Intro
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.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://argoproj.github.io/
Supports
- Argo as open source tools for Kubernetes
- The four-project map of Workflows, CD, Rollouts, and Events
- High-level responsibility of each project
- https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
Supports
- CRDs as extensions that add resource kinds to the Kubernetes API
- Custom resources as declarative API objects used with custom controllers
- Kubernetes API, authentication, authorization, and tooling behavior for custom resources
- https://kubernetes.io/docs/concepts/architecture/controller/
Supports
- Controllers as control loops that move current state toward desired state
- Asynchronous reconciliation and status-oriented observation
- Separation between submitting desired state and observing completed work
- https://argo-workflows.readthedocs.io/en/latest/
Supports
- Argo Workflows as a container-native workflow engine for parallel jobs on Kubernetes
- Workflow implementation through Kubernetes custom resources
- Machine learning, data processing, infrastructure automation, and CI or CD use cases
- Workflow feature scope including artifacts, templates, retries, scheduling, APIs, and metrics
- https://argo-workflows.readthedocs.io/en/latest/workflow-concepts/
Supports
- Workflow as both executable definition and execution state
- Entrypoint and template structure
- Container, script, resource, and suspend template behavior
- Steps as sequential outer groups with parallel inner tasks
- DAG templates as explicit task dependency graphs
- https://argo-workflows.readthedocs.io/en/latest/walk-through/parameters/
Supports
- Workflow input and output parameter behavior
- Parameters as small values passed into templates and tasks
- https://argo-workflows.readthedocs.io/en/latest/walk-through/artifacts/
Supports
- Input and output artifacts as files or directories
- Artifact passing between tasks through configured artifact repositories
- Separation between parameters, artifacts, volumes, and external storage
- https://argo-workflows.readthedocs.io/en/latest/workflow-rbac/
Supports
- Workflow execution through Kubernetes service accounts
- Separation between workflow controller and workflow permissions
- Least-privilege access for workflow-created pods and resource operations
- https://argo-workflows.readthedocs.io/en/latest/security/
Supports
- Security boundaries for workflow execution, images, secrets, pod privileges, and multi-tenancy
- Risks from untrusted workflow specifications and generated workloads
- Need to combine Argo access controls with Kubernetes security controls
- https://argo-cd.readthedocs.io/en/stable/
Supports
- Argo CD as declarative GitOps continuous delivery for Kubernetes
- Git repositories as desired application state
- Application comparison, OutOfSync status, health, and manual or automated synchronization
- Manifest support for Kustomize, Helm, Jsonnet, plain YAML, and plugins
- Multiple-cluster delivery, drift detection, audit trails, and user interfaces
- https://argo-cd.readthedocs.io/en/stable/operator-manual/architecture/
Supports
- Application controller reconciliation responsibilities
- Repository server manifest generation responsibilities
- API server, repository, and destination-cluster component boundaries
- Argo CD as a controller that compares live and target application state
- https://argo-cd.readthedocs.io/en/stable/user-guide/best_practices/
Supports
- Separation of application configuration repositories from application source where appropriate
- Declarative repository and cluster configuration practices
- Version pinning and manifest-management considerations
- https://argo-cd.readthedocs.io/en/stable/operator-manual/security/
Supports
- Argo CD security architecture, threat model, and hardening controls
- Repository, cluster, credential, project, and user-interface authorization boundaries
- Security responsibilities around manifest generation and managed clusters
- https://argo-rollouts.readthedocs.io/en/stable/
Supports
- Argo Rollouts as a Kubernetes controller and set of CRDs for progressive delivery
- Blue-green, canary, analysis, experimentation, promotion, and rollback features
- Optional ingress-controller, service-mesh, and metrics-provider integrations
- Rollout management of ReplicaSets and progression from stable to new versions
- Limits of native rolling updates that motivate added release controls
- https://argo-rollouts.readthedocs.io/en/stable/concepts/
Supports
- Rollout as a Deployment replacement for advanced release behavior
- Blue-green and canary strategy concepts
- Stable and canary ReplicaSets, services, experiments, and analysis resources
- Traffic weights with and without traffic-routing integration
- https://argo-rollouts.readthedocs.io/en/stable/features/analysis/
Supports
- AnalysisTemplate, ClusterAnalysisTemplate, and AnalysisRun roles
- Background, inline, pre-promotion, and post-promotion analyses
- Metric queries, success conditions, failure limits, and inconclusive or error outcomes
- Analysis-driven continuation, pause, abort, and rollback behavior
- https://argoproj.github.io/argo-events/
Supports
- Argo Events as event-driven workflow automation for Kubernetes
- Event sources including webhooks, object storage, schedules, and messaging systems
- Triggers including Argo Workflows, Kubernetes objects, HTTP requests, and other integrations
- CloudEvents compliance and dependency logic
- https://argoproj.github.io/argo-events/concepts/architecture/
Supports
- EventSource, EventBus, Sensor, and trigger as the main architecture components
- Separation of event receipt, transport, dependency resolution, and action
- https://argoproj.github.io/argo-events/concepts/event_source/
Supports
- EventSource configuration for consuming external events
- Conversion to CloudEvents and publication to an EventBus
- Breadth of supported event-source categories
- https://argoproj.github.io/argo-events/concepts/eventbus/
Supports
- EventBus as the transport layer connecting EventSources and Sensors
- EventSources as publishers and Sensors as subscribers
- Current EventBus implementation choices and lifecycle concerns
- https://argoproj.github.io/argo-events/concepts/sensor/
Supports
- Sensor as a definition of event dependencies and triggers
- Dependency resolution from EventBus events
- Trigger execution after declared dependencies resolve
- https://argoproj.github.io/argo-events/sensors/triggers/argo-workflow/
Supports
- Sensor submission of Argo Workflow resources
- Boundary between event dependency resolution and downstream workflow execution
- https://argoproj.github.io/argo-events/service-accounts/
Supports
- Service-account requirements for EventSource and Sensor operations
- Trigger permissions for creating Kubernetes and Argo resources
- Least-privilege separation for event-driven actions
- https://argoproj.github.io/trainings/
Supports
- Official Argo training and certification route for continued ecosystem study