Enabling the module

Before you start using the operator-argo module in your Kubernetes cluster, it needs to be enabled. This can be done in one of the ways described below.

Method 1: Enabling using ModuleConfig

Create a ModuleConfig resource to enable the module:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: operator-argo
spec:
  enabled: true

Method 2: Enabling using deckhouse-controller

To enable the module, run the following command:

kubectl -n d8-system exec deploy/deckhouse -c deckhouse -it -- deckhouse-controller module enable operator-argo

Disabling the module

Disabling the module will remove the ArgoCD operator (all resources from the namespace d8-operator-argo). However, deployed ArgoCD installations and applications will remain untouched.

If you need to disable the operator-argo module, you can do so using one of the methods described below.

Method 1: Disabling using ModuleConfig

Disable the module by setting the enabled value to false in the ModuleConfig:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: operator-argo
spec:
  enabled: false

Method 2: Disabling using deckhouse-controller

To disable the module, run the following command:

kubectl -n d8-system exec deploy/deckhouse -c deckhouse -it -- deckhouse-controller module disable operator-argo

Installing ArgoCD and deploying an ArgoCD application

Deploy ArgoCD, which will be accessible via Ingress. Create the necessary resources using the following manifest:

---
apiVersion: v1
kind: Namespace
metadata:
  name: argocd
---
apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd
  namespace: argocd
spec:
  server:
    host: <argocd-domain>
    ingress:
      enabled: true
      tls:
      - hosts:
        - <argocd-domain>
        secretName: argocd-ingress-tls
    # To avoid internal redirection loops from HTTP to HTTPS, the API server should be run with TLS disabled.
    # https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/#disable-internal-tls
    insecure: true
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: argocd-ingress
  namespace: argocd
spec:
  dnsNames:
  - <argocd-domain>
  issuerRef:
    kind: ClusterIssuer
    name: letsencrypt
  secretName: argocd-ingress-tls

Create a namespace for your future application. This will provide isolation and management for your application’s resources:

apiVersion: v1
kind: Namespace
metadata:
  name: demo
  labels:
    argocd.argoproj.io/managed-by: argocd

Deploy an ArgoCD application by specifying where your application is located and how to deploy it. Use the following manifest to create the application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo
  namespace: argocd
spec:
  destination:
    namespace: demo
    server: https://kubernetes.default.svc
  project: default
  source:
    path: helm-guestbook
    repoURL: https://github.com/argoproj/argocd-example-apps
    targetRevision: HEAD
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

High availability ArgoCD

Enable HA by setting spec.ha.enabled: true in the ArgoCD CR.

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd
  namespace: argocd
spec:
  ha:
    enabled: true
    resources:
      requests:
        cpu: "500m"
        memory: "512Mi"
      limits:
        cpu: "1"
        memory: "1Gi"

NOTE:

HA mode in ArgoCD provides high availability for Redis (state storage) using HAProxy and does not imply automatic high availability for all ArgoCD components.

The HA installation will require at least three different nodes due to pod anti-affinity roles in the specs. Additionally, IPv6 only clusters are not supported.

When ha is enabled, changes to .spec.redis.resources doesn’t have any effect. Redis resource limits can be set using .spec.ha.resources.

Authentication

Using Deckhouse Kubernetes Platform single sign-on system for authentication in ArgoCD

Create an OAuth2 client that will be used for authentication in ArgoCD:

apiVersion: deckhouse.io/v1
kind: DexClient
metadata:
  name: argocd
  namespace: argocd
spec:
  redirectURIs:
    - https://<argocd-domain>/api/dex/callback
    - https://<argocd-domain>/api/dex/callback-reserve

After creating DexClient resource, DKP will register a client with the client ID (clientID) dex-client-argocd@argocd(dex-client-<name>@<namespace>).

Wait for Deckhouse Kunernetes Platform to create a Secret with the client secret:

kubectl -n argocd get secret/dex-client-argocd

Configure ArgoCD to use the DKP single sign-on system:

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd
  namespace: argocd
spec:
  sso:
    dex:
      config: |
        connectors:
          - type: oidc
            id: deckhouse
            name: deckhouse
            config:
              issuer: "https://dex.<cluster-domain>/"
              clientID: "dex-client-argocd@argocd"
              clientSecret: "$dex-client-argocd:clientSecret"
              insecureEnableGroups: true
              scopes:
               - profile
               - email
               - openid
               - groups
    provider: dex
  server:
    host: <argocd-domain>
    ingress:
      enabled: true
      tls:
        - hosts:
            - <argocd-domain>
          secretName: argocd-ingress-tls
    # To avoid internal redirection loops from HTTP to HTTPS, the API server should be run with TLS disabled.
    # https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/#disable-internal-tls
    insecure: true

Restart the ArgoCD server:

kubectl -n argocd rollout restart deploy/argocd-server

If you don’t restart the server, login attempts will fail, and you will see an error in the ArgoCD server log (issue).

An example of the error message... time="2024-10-16T14:12:59Z" level=warning msg="Failed to verify token: failed to verify token: token verification failed for all audiences: error for aud "argo-cd": Failed to query provider "https://argocd./api/dex": Get "https://argocd./api/dex/.well-known/openid-configuration": tls: failed to verify certificate: x509: certificate is valid for ingress.local, not argocd., error for aud "argo-cd-cli": Failed to query provider "https://argocd./api/dex": Get "https://argocd./api/dex/.well-known/openid-configuration": tls: failed to verify certificate: x509: certificate is valid for ingress.local, not argocd."

ArgoCD authentication without Dex (admin user)

During the initial deployment of ArgoCD, the operator creates a Kubernetes Secret:

  • Namespace: argocd
  • Secret: argocd-cluster
  • Key: admin.password

This secret stores the initial password of the admin user in base64-encoded form.

You can retrieve the initial admin password using the following command:

kubectl -n argocd get secret argocd-cluster \
  -o jsonpath='{.data.admin\.password}' | base64 -d

Granting ArgoCD access to cluster-wide resources

To allow ArgoCD to manage cluster-wide resources, specify the clusterConfigNamespaces parameter in the module settings:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: operator-argo
spec:
  enabled: true
  settings:
    clusterConfigNamespaces: <list of namespaces of cluster-scoped Argo CD instances>
  version: 1

Using a Custom Cluster Domain Instead of cluster.local

To configure ArgoCD to use a custom cluster FQDN (e.g., prod.local), set the clusterDomain field accordingly:

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd
  namespace: argocd
spec:
  ...
  clusterDomain: "prod.local"
  ...