helm dependencies with different namespaces

Question

Right now, I have to install multiple helm charts in different namespaces for my product to work. I am trying to create a super helm chart in which I am planning to add the helm charts (of my tools, as mentioned above) and install them in one shot. My problem is, as these tools are in different namespaces I am not sure where to specify the namespace key where I want that particular dependency (chart) to be installed. For e.g. if below is the Charts.yaml of my super helm chart

dependencies:
- name: first_chart
  version: 1.2.3
  repository: https://firstchart.repo
- name: second_chart
  version: 1.5.6
  repository: https://secondchart.repo

I want my first chart to be installed in namespace foo and the second chart to be installed in namespace bar.

I was looking at using conditions but I believe conditions will only take a boolean as a value.

I stumbled upon this link (https://github.com/helm/helm/issues/2060) which says the we can do it in Helm 3 but mostly on how to keep releases between different namespaces. It does not specifically answer my question.

Delvecchio

Does this answer your question? How to set a different namespace for child helm charts? – Randall

Helm doesn't directly support this; the helm/helm#2060 issue seems to be a little more about keeping a separate list of releases per namespace rather than one globally per cluster. If you control the subcharts you can manually add a namespace: to their YAML, or tools like Helmfile or Helmsman can effectively do multiple helm installs with more control over their options. – Randall

Thanks David. I saw the stackoverflow link which eventually points to the one which I had pasted in my question. I guess I will take your comment to install individually. – Delvecchio

@Delvecchio did you eventually find the answer to this? I am having the same problem. – Doublestop

Answer 1

There is no builtin way to do this with pure Helm, but there is with helmfile.

Your example as helmfile.yaml:

releases:
  - name: chart1 # name of the release (helm install <...> first_chart)
    chart: repo1/first_chart
    version: 1.2.3
    namespace: foo

  - name: chart2
    chart: repo2/second_chart
    version: 1.5.6
    namespace: bar

# in case you want helmfile to automatically update repos
repositories:
  - name: repo1
    url: https://firstchart.repo
  - name: repo2
    url: https://secondchart.repo

Then, run:

• helmfile sync => run helm install/upgrade on all releases, or
• helmfile apply => same as sync, but do a diff first to only upgrade/install releases that changed

There is way more to helmfile, but this is the gist.

PS: if you struggle with values or want to have something similar to how umbrella Chart values are handled, have a look at helmfile: a simple trick to handle values intuitively

Mcentire

Answer 2

The way I solved this for my clusters with with ArgoCD's App of Apps cluster bootstrapping model. Of course, it requires that ArgoCD is install the cluster. However, for many reasons not relevant to this answer I would highly encourage installing ArgoCD regardless of the ease of bootstrapping capabilities.

Assuming ArgoCD is in place the structure is a single Helm chart containing templates for each of the child charts it will deploy and managed via Argo's Application CRD. You will notice there is a definition as part of the CRD, spec.destination.namespace, which governs where the chart will be deployed.

An example Application template which governs my cert-manager chart deployment to the cert-manager namespace looks like:

{{- if .Values.certManager.enabled }}
# ref: https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#applications
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cert-manager
  # You'll usually want to add your resources to the argocd namespace.
  namespace: argocd
  # Add a this finalizer ONLY if you want these to cascade delete.
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  # The project the application belongs to.
  project: cluster-configs

  # Source of the application manifests
  source:
    repoURL: https://github.com/yourOrg/Helm
    targetRevision: {{ .Values.targetRevision }}
    path: charts/cert-manager-chart

    # helm specific config
    helm:
      # Helm values files for overriding values in the helm chart
      # The path is relative to the spec.source.path directory defined above
      valueFiles:
        {{- range .Values.certManager.valueFiles }}
        - {{ . }}
        {{- end }}

      # Optional Helm version to template with. If omitted it will fall back to look at the 'apiVersion' in Chart.yaml
      # and decide which Helm binary to use automatically. This field can be either 'v2' or 'v3'.
      version: v3

  # Destination cluster and namespace to deploy the application
  destination:
    server: https://kubernetes.default.svc
    namespace: cert-manager
{{- end }}

With a corresponding values.yaml file for this parent chart which may look something like the following with the path to desired value file(s) in that child chart's directory specified.

targetRevision: v1.11.0

certManager:
  enabled: true
  valueFiles: 
    - "values.yaml"

clusterAutoScaler:
  valueFiles: 
    - "envs/dev-account/saas/values.yaml"

clusterResourceLimits:
  valueFiles: 
    - "values.yaml"

externalDns:
  valueFiles: 
    - "envs/dev-account/saas/values.yaml"

ingressNginx:
  enabled: true
  valueFiles: 
    - "values.yaml"

Below is a screenshot of one of my app of apps directory to complete the example.

Unopened