The Helm Application: Argo CD rendering a chart from git

Prerequisites: application, argocd

Most components on devata were installed with helm install, which renders a chart on your laptop, pushes the result into the cluster, and leaves a release record behind. An application that uses a Helm source moves that rendering inside argocd: you describe which chart, which version, and which values, and the Argo repo-server runs helm template on every reconcile and applies the output itself. There is no helm install step, no in-cluster Tiller, and no release secret created by Argo. The chart becomes data in git like everything else, and the reconciliation loop keeps the rendered result true.

The shape of a Helm source

A plain Application points source.path at a folder of YAML. A Helm Application instead names a chart repository, a chart, and a version. The Argo CD Helm docs cover the full field set; the minimal form is:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kps
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://prometheus-community.github.io/helm-charts
    chart: kube-prometheus-stack
    targetRevision: 86.2.0          # the chart version, pinned
    helm:
      valuesObject:
        grafana:
          enabled: true
  destination:
    server: https://kubernetes.default.svc
    namespace: monitoring
  syncPolicy:
    automated: { selfHeal: true, prune: true }
    syncOptions: [ CreateNamespace=true ]

repoURL here is the chart repository (not a git repo), chart is the chart name, and targetRevision is the chart version. Pinning the version is the whole point: the chart is now a fact recorded in git, not whatever helm repo update last happened to pull. Bumping a component is editing targetRevision and letting the running Argo CD apply it, the same way upgrading Argo CD itself became an edit to a version string in bootstrapping-argocd.

Keep the values in git, not inline

valuesObject works, but it buries a component’s configuration inside its Application manifest. The cleaner shape keeps the chart upstream and the values in the lab repo, joined with a multi-source Application: one source is the chart, another is the git repo carrying a values.yaml, referenced through the $values ref.

spec:
  sources:
    - repoURL: https://prometheus-community.github.io/helm-charts
      chart: kube-prometheus-stack
      targetRevision: 86.2.0
      helm:
        valueFiles:
          - $values/kubernetes/infra/observability/kps/values.yaml
    - repoURL: https://github.com/PragalvaXFREZ/lab.git
      targetRevision: main
      ref: values

The second source contributes no manifests; ref: values only makes its files available to the first source’s valueFiles. This is the multiple-sources pattern. The result is that the chart version and the values are both versioned in git, in their natural homes.

Recovering the values you already run

A release on devata was installed with some set of overrides, and those overrides are what the migrated Application has to reproduce. Recover exactly them from the live cluster:

helm get values kps -n monitoring        # only your overrides
helm get values kps -n monitoring -a     # the full computed values, for reference

Commit the first output as the chart’s values.yaml. That file, plus the pinned targetRevision, is the entire declarative description of the component.

What Argo renders is not a Helm release

Because Argo runs helm template and applies the result itself, the objects it creates are tracked by Argo’s own instance label, not by a Helm release. After a component is migrated this way, helm list -n <ns> still shows the old release record, but Argo CD, not Helm, is now reconciling the live objects. That overlap, an Argo Application and a leftover Helm release both pointing at the same running resources, is what has to be handled carefully so neither fights the other. Reconciling it is the subject of adoption.