1. Introduction to Argo
Argo is an open source project that provides a set of tools on Kubernetes for building and running applications. The core components of Argo mainly include the following:
- Argo CD
Argo CD is a GitOps-based continuous delivery tool that allows users to declaratively manage the deployment of applications in a Kubernetes cluster. By syncing with a Git repository, Argo CD ensures that the cluster state stays consistent with the state defined in the Git repository.
- Argo Workflows
This is a container-based task orchestration tool that allows users to define, run, and monitor complex workflows. Argo Workflows supports many types of workflows, including sequential, parallel, conditional, and looping ones.
- Argo Events
This is an event-driven tool that provides a mechanism to handle events from external systems and trigger operations within a Kubernetes cluster. Argo Events includes components such as EventSources, EventBus, Sensors, and Triggers.
- Argo Rollouts
Argo Rollouts is a progressive delivery tool for applications. It supports strategies such as canary releases and blue-green releases, helping users safely update and roll back applications in a Kubernetes cluster.
2. argo-cd
2.1 Installation
| |
| |
2.2 List of Related CRDs
| |
- applications.argoproj.io
This CRD defines the Application resource in Argo CD. Application is one of the core concepts of Argo CD: it represents the desired state of a group of resources (such as Pods, Services, and so on) deployed in a Kubernetes cluster. The Application resource is usually associated with configuration files in a Git repository, allowing users to manage the deployment and update of applications in a GitOps way.
- applicationsets.argoproj.io
ApplicationSet is an extension of Argo CD that provides automated and more flexible management capabilities, especially when dealing with a large number of clusters and monorepos. ApplicationSet allows users to deploy Argo CD applications to multiple Kubernetes clusters using a single Kubernetes manifest. It also supports multi-tenant Kubernetes clusters, letting a single cluster tenant deploy applications with Argo CD without the cluster administrator being involved. ApplicationSet generates parameters by using different generators (such as the list generator, cluster generator, Git generator, and so on); these parameters are then used for template rendering, thereby creating or updating Argo CD applications.
- appprojects.argoproj.io
The AppProject resource is used in Argo CD to logically organize Application resources. It defines the set of Git repositories, target clusters, and namespaces that applications can be deployed to, along with the access control policies for those applications. AppProject allows users to define source repositories (sourceRepos), destination clusters (destinations), and roles (roles), where the roles define the access permissions that users or service accounts have to resources within the project. This lets administrators control more precisely who can deploy which applications to which clusters.
3. argo-workflows
3.1 Installation
| |
| |
3.2 Related CRDs
| |
- clusterworkflowtemplates.argoproj.io
ClusterWorkflowTemplate is a resource that allows users to define workflow templates that can be shared and reused cluster-wide. It is similar to WorkflowTemplate but has a higher privilege level and can be used in any namespace.
- cronworkflows.argoproj.io
The CronWorkflow resource is used to define workflows that run on a schedule. It is similar to the CronJob in Kubernetes, allowing users to set up scheduled tasks so that workflows start automatically at specified intervals.
- workflowartifactgctasks.argoproj.io
WorkflowArtifactGCTask is a task used to clean up resources left behind after a workflow execution. This helps keep the cluster tidy and avoids resource leaks.
- workfloweventbindings.argoproj.io
The WorkflowEventBinding resource is used to define bindings for workflow events. It allows users to trigger the execution of a workflow based on Kubernetes events (such as a Pod completing, a ConfigMap being updated, and so on).
- workflows.argoproj.io
Workflow is the core resource type in Argo Workflows. It defines a workflow made up of multiple steps (tasks). Each step can be a container, a script, or another type of operation, and they execute sequentially or in parallel.
- workflowtaskresults.argoproj.io
The WorkflowTaskResult resource is used to store the execution results of workflow tasks. This helps pass data within a workflow, or debug when a task fails.
- workflowtasksets.argoproj.io
WorkflowTasksSet is a resource that allows users to define a set of workflow tasks that can be reused as templates across multiple workflows.
- workflowtemplates.argoproj.io
WorkflowTemplate is a resource that defines a workflow template that can be shared and reused within a specific namespace. It is similar to ClusterWorkflowTemplate, but its scope is limited to a single namespace.
4. argo-events
4.1 Installation
| |
| |
Optionally install the validating webhook
| |
4.2 Related CRDs
| |
- eventbus.argoproj.io
EventBus is a core resource in Argo Events; it is responsible for transporting events between EventSources and Sensors. EventBus can be built on NATS Streaming or Kafka, and it provides a mechanism to ensure that events are reliably delivered within the cluster. The EventBus resource defines the configuration for event transport, including the backend messaging system used, the authentication policy, the persistence settings, and so on.
- eventsources.argoproj.io
The EventSource resource defines how to consume events from external services (such as Kafka, GitHub, Slack, and so on). It specifies the type of the event source, the connection information, the filter conditions, and so on. When it observes events matching the filter conditions, EventSource writes these events to the EventBus. EventSource can be native (such as an EventSource based on NATS Streaming) or heterogeneous (such as one connected to an existing Kafka cluster).
- sensors.argoproj.io
The Sensor resource defines the logic for listening to specific events on the EventBus and triggering the corresponding responses when an event matches. Sensor runs in a Pod managed by the sensor-controller, and it can define Triggers, which can be HTTP requests, Kubernetes object operations, Slack messages, and so on. When a Sensor observes a matching event, it performs the defined operations, such as creating or updating Kubernetes resources.
5. Argo rollouts
5.1 Installation
| |
| |
Optionally install the dashboard
| |
5.2 Related CRDs
| |
- analysisruns.argoproj.io
The AnalysisRun resource is used to define and manage the execution of analysis tasks. These analysis tasks can run during the deployment process to evaluate the performance of a new version, for example by comparing the metrics of the old and new versions. AnalysisRun can be associated with the Experiment resource to perform analysis during an experiment.
- analysistemplates.argoproj.io
AnalysisTemplate is a template resource that defines the configuration of an analysis task but does not execute it immediately. AnalysisTemplate can be referenced by AnalysisRun so that analysis tasks are created and executed when needed.
- clusteranalysistemplates.argoproj.io
ClusterAnalysisTemplate is similar to AnalysisTemplate, but it has a cluster-wide scope. This means it can be referenced and used in multiple namespaces, not just in the namespace where it is defined.
- experiments.argoproj.io
The Experiment resource is used to define and manage experiments, which are usually used to compare the application performance of the old and new versions. An Experiment can contain multiple AnalysisRuns so that multiple analysis tasks are performed during the experiment. The results of an experiment can be used to decide whether to promote the new version to production.
- rollouts.argoproj.io
Rollout is the core resource type in Argo Rollouts; it is used to define and manage the progressive deployment of applications. Rollout allows users to gradually push a new version of an application to production while monitoring metrics during the deployment process to ensure the stability of the new version. Rollout supports multiple strategies, such as canary releases and blue-green deployments.
