Skip to content

ArgoCD

Argo CD

Official download

Argo CD releases — always current.

Runs on dke-mgmt and is the delivery mechanism for everything inside every cluster — CNI, ExternalSecrets/Vault integration, MetalLB, ingress, and application workloads — via ApplicationSet resources that target one or more registered clusters.

Registering a cluster as a target

Handled by the argocd-register-clust Terraform module during cluster bootstrap — it creates the in-cluster argocd-manager ServiceAccount/RBAC and the corresponding ArgoCD Cluster object. cluster_name is the de-duplication key; reusing the name a cluster was already registered under (rather than letting Terraform generate a new one) is what keeps a re-run from creating a duplicate entry for the same API server.

Tearing down a cluster's ArgoCD registration

If the target cluster's API server is already gone (fully destroyed), Terraform will try to delete the in-cluster ArgoCD-manager resources through the (now-unreachable) API and hang until it times out. There's nothing to actually delete at that point — terraform state rm the specific kubernetes_* resources under that module rather than letting terraform destroy retry a dead endpoint forever. Leave argocd_cluster resources (the ArgoCD-side registration, reachable via ArgoCD's own API, not the dead cluster's) to actually run and deregister properly.

The out-of-band bootstrap ApplicationSet

See the callout in Bootstrapping a New Cluster — the bootstrap ApplicationSet on dke-mgmt is applied by a provisioning script, not by ArgoCD's own git sync. It's the one ApplicationSet on this cluster where "push to git" alone is not sufficient.

Repo credentials for private Azure DevOps repos

ArgoCD's own Azure DevOps git repo credential is Vault-backed via an ExternalSecret (repo-devhome, in namespace default — not argocd, since this cluster's ArgoCD Helm release itself deploys into default, not the conventional namespace). Fixes the failed to list refs ... status code: 302 error Azure DevOps returns for any unauthenticated git request. Shape: creationPolicy: Owner plus a template (needed to set the argocd.argoproj.io/secret-type: repository label, which a plain data: block can't do), pulling azuredevops_pat and azuredevops_org_service_url from devhome/azure in Vault. The username field is arbitrary (azuredevops) since Azure DevOps PAT auth ignores it entirely — only the password/PAT matters.

An Application object can be deleted while its resources live on

None of the k8s/dke-mgmt/*-app.yaml manifests set metadata.finalizers: [resources-finalizer.argocd.argoproj.io] — the finalizer that tells ArgoCD to cascade-delete everything a chart created. Without it, deleting the Application object directly (kubectl delete application/-f) removes ArgoCD's tracking of the app but leaves every Deployment/StatefulSet/Service/Ingress/CronJob/PVC it created still running, fully orphaned. Options: add the finalizer before deleting, use argocd app delete <name> --cascade via the CLI, or clean up by label after the fact — Helm-installed resources reliably carry app.kubernetes.io/instance=<app-name>, but Secrets/ExternalSecrets created via separate manifests don't carry that label and have to be found by name. Separately: if a secret deletion fails with dial tcp ... rancher-webhook ...: connection refused, that's Rancher's admission webhook being briefly unreachable, not a problem with the specific secret — retry once it recovers, since its mutating webhook gates all secret deletions cluster-wide.