The operator-argo module deploys Argo CD Operator in a Deckhouse Kubernetes Platform (DKP) cluster. The module enables to install Argo CD in a DKP cluster using the ArgoCD resource.

The module works with the following custom resources:

  • Application: Describes application deployment and its management.
  • ApplicationSet: Provides templating and mass application creation according to defined rules.
  • AppProject: Defines a set of applications and application access policies.
  • ArgoCD: Main resource for deploying and configuring an Argo CD instance.
  • ArgoCDExport: Exports Argo CD configuration and state for backup or migration.
  • ImageUpdater: Automatically updates application container images.
  • NamespaceManagement: Defines namespace management rules for an Argo CD instance.
  • NotificationsConfiguration: Defines notification settings for events in Argo CD and applications.

For more details on module settings and usage examples, refer to the module documentation.

Module architecture

The following simplifications are made in the diagram:

  • The diagram shows containers in different pods interacting directly with each other. In reality, they communicate via the corresponding Kubernetes Services (internal load balancers). Service names are omitted if they are obvious from the diagram context. Otherwise, the Service name is shown above the arrow.
  • Pods may run multiple replicas. However, each pod is shown as a single replica in the diagram.
  • Only the main containers of each component are shown in the diagram.

The Level 2 C4 architecture of the operator-argo module and its interactions with other DKP components are shown in the following diagrams:

  • Main module operator:

    Operator-argo module operator architecture

  • Argo CD instance deployment scenario with Redis in a non-HA configuration:

    Operator-argo module architecture with Redis non-HA

  • Argo CD instance deployment scenario with Redis in an HA configuration (the diagram shows only differences from the primary deployment scenario):

    Operator-argo module architecture with Redis HA

  • Argo CD instance deployment scenario in a principal cluster for a multicluster setup (the diagram shows only differences from the primary deployment scenario):

    Operator-argo module architecture with Principal

Module components

The module consists of the following components:

  1. Argocd-operator-controller-manager (Deployment): Implementation of Argo CD Operator that allows deploying Argo CD instances in a DKP cluster. The component works with the following custom resources:
    • ArgoCD: Main resource for deploying and configuring an Argo CD instance.
    • ArgoCDExport: Exports Argo CD configuration and state for backup or migration. The operator reads the ArgoCDExport custom resource and creates a Job/CronJob with the same name as the ArgoCDExport resource. The created Job/CronJob performs backup of the Argo CD instance configuration.
    • NamespaceManagement: Defines namespace management rules for an Argo CD instance. The operator watches the NamespaceManagement custom resource and updates the argocd-cmd-params-cm ConfigMap accordingly.
    • NotificationsConfiguration: Defines notification settings for events in Argo CD and applications. The operator reads NotificationsConfiguration custom resources and updates configuration in the argocd-notifications-cm ConfigMap based on them.

    Argocd-operator-controller-manager creates Deployment, Secret, ConfigMap, StatefulSet, and other resources for each ArgoCD custom resource, adding that resource name as a prefix to the created resources.

    It consists of the following containers:

    • manager: Main container.
    • kube-rbac-proxy: Sidecar container with an authorization proxy based on Kubernetes RBAC that provides secure access to manager metrics.

    The following components describe resources created by argocd-operator-controller-manager based on configuration defined in the ArgoCD custom resource. The <ArgoCD name> prefix is used in descriptions and is replaced by the controller with the ArgoCD resource name.

  2. <ArgoCD name>-server (Deployment): Argocd-server. Main component for interacting with an Argo CD instance. Argocd-server provides REST/gRPC API and a web UI for Argo CD management. The component allows managing Application, ApplicationSet, and AppProject custom resources through the provided interfaces (web UI, API, CLI).

    The operator creates this component if the .spec.server.enabled parameter of the ArgoCD custom resource is set to true (default value is true).

    It consists of the following containers:

    • argocd-server-init: Optional set of init containers defined by the user in the .spec.server.initContainers parameter of the ArgoCD custom resource.
    • rollout-extension: Optional init container that loads the UI extension for the Rollout custom resource. The module does not provide a controller for this custom resource. Such controller must be installed and configured separately. Argocd-operator-controller-manager adds rollout-extension if .spec.server.enableRolloutsUI is set to true.
    • argocd-server: Main container.
    • argocd-server-sidecar: Optional set of sidecar containers defined by the user in the .spec.server.sidecarContainers parameter of the ArgoCD custom resource.

  3. <ArgoCD name>-repo-server (Deployment): Argocd-repo-server. Component responsible for template rendering, application manifest generation, and working with external repositories used by Argo CD. Argocd-repo-server synchronizes application manifests from configured repositories and passes them to the corresponding components for further deployment.

    The operator creates this component if the .spec.repo.enabled parameter of the ArgoCD custom resource is set to true (default value is true).

    It consists of the following containers:

    • copyutil: Init container that copies executables for use by the main container.
    • argocd-repo-server-init: Optional set of init containers configured through the .spec.repo.initContainers parameter of the ArgoCD custom resource to prepare the environment.
    • argocd-repo-server: Main container that generates and processes manifests and works with remote application Git repositories.
    • argocd-repo-server-sidecar: Optional set of sidecar containers defined by the user in the .spec.repo.sidecarContainers parameter of the ArgoCD custom resource and used to extend repo-server functionality.

  4. <ArgoCD name>-application-controller (StatefulSet): Argocd-application-controller. Component responsible for synchronization and state management of applications defined in Argo CD. Argocd-application-controller provides idempotent application of Kubernetes manifests, manages deployment, rollback, and self-healing workflows, and monitors resource state in the cluster.

    The operator creates this component if the .spec.controller.enabled parameter of the ArgoCD custom resource is set to true (default value is true).

    It consists of the following containers:

    • application-controller-init: Optional set of init containers configured through the .spec.controller.initContainers parameter of the ArgoCD custom resource to prepare the environment.
    • argocd-application-controller: Main container implementing synchronization logic for Application custom resources and resources created from them.
    • application-controller-sidecar: Optional set of sidecar containers defined by the user in the .spec.controller.sidecarContainers parameter of the ArgoCD custom resource and used to extend controller capabilities.

  5. <ArgoCD name>-applicationset-controller (Deployment): Argocd-applicationset-controller. Optional component consisting of a single applicationset-controller container and responsible for managing the ApplicationSet custom resource in Argo CD. It allows automatic creation, update, and deletion of Application resources based on configured templates and generators (for example, Git, List, Matrix, and Cluster generators). This simplifies mass management of similar applications that must be deployed across different environments or clusters.

    The operator creates this component if the .spec.applicationSet.enabled parameter of the ArgoCD custom resource is set to true (default value is true).

    For more details about the component, refer to the applicationset-controller documentation.

  6. <ArgoCD name>-argocd-image-updater-controller (Deployment): Argocd-image-updater-controller. Optional component consisting of a single argocd-image-updater container and intended for automatic container image updates in Argo CD applications when new versions appear in image registries. The component tracks image tag changes and, when a new version is found, updates corresponding Application resources in Argo CD (for example, image tags in manifests or Helm values) via a pull request to a Git repository or directly, depending on the selected workflow.

    Argocd-image-updater-controller performs the following functions:

    • Manages the ImageUpdater custom resource that defines settings for automatic updates of application container images.
    • Periodically checks application container images in supported registries (Docker Hub, Quay.io, Harbor, and others).
    • Supports filtering image tags by patterns and update strategies (semver, latest, and others).
    • When a new image version is found, automatically performs write-back (writes the new image tag value) to Argo CD Application or a Git repository depending on the configured method.

    For correct operation, the component requires access to Git repositories and, if needed, private image registries. Credentials for accessing image registries can be stored in Kubernetes Secrets.

    To enable the component, set .spec.imageUpdater.enabled to true in the ArgoCD custom resource.

    For more details about the component, refer to the argocd-image-updater documentation.

  7. <ArgoCD name>-notifications-controller (Deployment): Optional controller consisting of a single argocd-notifications-controller container that sends notifications about Argo CD events (for example, successful application sync, deployment failures, status changes, and others) to external notification systems, including email, Slack, Microsoft Teams, Telegram, OpsGenie, Webhook, and others.

    The main module operator argocd-operator-controller-manager generates notification settings based on NotificationsConfiguration custom resources and stores them in the argocd-notifications-cm ConfigMap and argocd-notifications-secret Secret used by the controller to generate and send notifications.

    To enable the component, set .spec.notifications.enabled to true in the ArgoCD custom resource.

    For more details on operation, refer to the Argo CD Notifications documentation.

  8. <ArgoCD name>-dex-server (Deployment): Argocd-dex-server. Optional component for user authentication in Argo CD, acting as an OIDC provider (OpenID Connect) based on Dex. The component enables user login through various external authentication providers (LDAP, GitHub, GitLab, SAML, Azure AD, and others) and supports static users defined in Dex configuration.

    It consists of the following containers:

    • copyutil: Init container that copies executables for use by the main container.
    • dex: Main container.

    To enable the component, define parameters in .spec.sso.dex section of the ArgoCD custom resource.

    For Argo CD user authentication in DKP, the operator-argo module supports integration with the user-authn module (built-in DKP authentication). Other external providers via Dex are not used in this configuration.

    For more details about module usage examples, refer to the corresponding documentation section.

  9. <ArgoCD name>-redis (Deployment): Argocd-regis. Mandatory component consisting of a single redis container and responsible for storing task queue data and session state in Argo CD. Argocd-regis provides a dedicated Redis database instance.

    Argocd-operator-controller-manager deploys this component if .spec.ha.enabled in the ArgoCD custom resource is false.

  10. <ArgoCD name>-redis-ha-server (StatefulSet): Argocd-redis-ha-server. Mandatory component for deploying Redis in high availability (HA) mode in Argo CD. It provides a fault-tolerant Redis cluster with replication and automatic failover using Redis Sentinel.

    It consists of the following containers:

    • config-init: Init container that prepares configuration for Redis and Sentinel before main containers start.
    • redis: Main container implementing a Redis server instance.
    • sentinel: Auxiliary container running Redis Sentinel to monitor Redis instance health and automatically switch to a replica if the primary instance fails.

    Argocd-operator-controller-manager deploys this component if .spec.ha.enabled in the ArgoCD custom resource is true.

  11. <ArgoCD name>-redis-ha-haproxy (Deployment): Argocd-redis-ha-proxy. Additional component for load balancing and distributing traffic to Redis cluster instances (redis-ha-server) based on the HAProxy load balancer/reverse proxy server.

    It consists of the following containers:

    • config-init: Init container that prepares HAProxy configuration before the main container starts.
    • haproxy: Container acting as a proxy server and providing transparent routing of client requests to available Redis master/replica instances, as well as automatic switching between them on failover.

    Argocd-operator-controller-manager deploys this component if .spec.ha.enabled in the ArgoCD custom resource is true.

    The following components are used to implement a secure and scalable multicluster setup in Argo CD:

    • Principal: The central control point. It stores state and distributes tasks.
    • Agent: The executor in each target cluster. It applies manifests and reports back.

    This approach allows you to manage multiple clusters without direct access from the central Argo CD to the Kubernetes API of each cluster, which reduces the number of required open inbound connections, provides isolation, and ensures fault tolerance.

  12. <ArgoCD name>-agent-agent (Deployment): Argocd-agent-agent. Optional component consisting of a single <ArgoCD name>-agent-agent container and responsible for executing operations on managed Kubernetes cluster resources based on requests from Argo CD. The component establishes connection to Argo CD Principal, synchronizes applications, and manages their state based on commands received from Argo CD Principal.

    For details on Argo CD multicluster architecture, refer to the Argo CD documentation.

    Argocd-operator-controller-manager deploys this component if .spec.argoCDAgent.agent.enabled in the ArgoCD custom resource is true. Argo CD Agent and Argo CD Principal cannot be enabled simultaneously in a single ArgoCD resource.

  13. <ArgoCD name>-agent-principal (Deployment): Argocd-agent-principal. Optional component consisting of a single <ArgoCD name>-agent-principal container and enabling Argo CD operation in a multicluster setup.

    When this component is enabled, argocd-operator-controller-manager reconfigures all components that use Redis connection to use Redis proxy instead. The Argocd-agent-principal component provides this Redis proxy and routes database requests by analyzing Redis keys: depending on key values, a request is sent either to a local Redis instance or to one of remote Argo CD Agents.

    Argocd-operator-controller-manager deploys this component if .spec.argoCDAgent.principal.enabled in the ArgoCD custom resource is true. Argo CD Agent and Argo CD Principal cannot be enabled simultaneously in a single ArgoCD resource.

  14. <Export name> (Job/CronJob): Argocd-export. Optional component implemented as Job or CronJob that creates a pod with a single argocd-export container. The component creates backup of Argo CD instance configuration and state.

Module interactions

The module interacts with the following components:

  1. External image registries: Receives image lists.
  2. External code repositories:
    • Receives application deployment manifests from repositories.
    • Updates image in Helm chart source code.
  3. External Argo CD Principal:
    • Connects to Argo CD principal cluster.
    • Receives processing requests.
    • Sends back processing results.
  4. Kube-apiserver:
    • Manages Application, ApplicationSet, AppProject, ArgoCD, ArgoCDExport, ImageUpdater, NamespaceManagement, NotificationsConfiguration custom resources, as well as Secret and ConfigMap.
    • Manages resources created during deployment of user applications described in the Application custom resource.
    • Authorizes requests for metrics retrieval.
  5. user-authn module: Redirects user for authentication.

The following external components interact with the module:

  1. Prometheus-main: Collects metrics provided by the operator and Argo CD instances.
  2. External Argo CD Agent:
    • Connects to Argo CD principal cluster.
    • Receives processing requests.
    • Sends back processing results.

Additional resources