K
Q

When do I put a subchart in the charts/ directory, dependencies in Chart.yaml, or requirements.yaml in Helm?

9/25/2020

If I have a chart that depends on another chart, what's the best practices around when it should be included as a package in the charts/ directory vs requirements.yaml vs the dependencies property in Chart.yaml?

For example, if I have a shared dependency that multiple Helm charts will use, should I always put that in a Helm repo and then just refer to it in each chart's requirements.yaml? Or is there a benefit to including it in the charts/ directory?

Example

requirements.yaml

dependencies:
  - name: mariadb
    version: 7.x.x
    repository: https://charts.bitnami.com/bitnami
    condition: mariadb.enabled
    tags:
      - wordpress-database

Chart.yaml

dependencies:
  - name: mariadb
    version: 7.x.x
    repository: https://charts.bitnami.com/bitnami
    condition: mariadb.enabled
    tags:
      - wordpress-database

charts/ directory

my-package.tgz
  /charts
     mariadb-7.0.0.tgz
     ...elided...

(and there's technically a 4th where I put the actual exploded chart into the charts directory)

-- Don Rhummy
kubernetes
kubernetes-helm
yaml

Similar Questions

how to connect chrome debugger to kubernetes pod
Airflow cannot run cli commands
docker push image from CoreOS to private google container registry
Kubernetes - pod FailedScheduling due to "No nodes are available that match all of the predicates: MatchInterPodAffinity (1)."
Kubernetes is not re-pulling an image with ImagePullPolicy: Always

1 Answer

9/26/2020

If you need both Helm 2 and Helm 3 compatibility, include it in a separate requirements.yaml file. Most charts will work fine with either version of Helm (if the CLIs are somewhat different) so if your environment still needs Helm 2 compatibility, this is your best choice.

If you don't need Helm 2 compatibility, listing it in the Chart.yaml file is one file fewer.

I'd only manually download the chart (or unpack it) if I had a specific requirement to, probably because my product is uncomfortable downloading software from the public Internet without specifically verifying or approving it. Even then, it's common to have an internal repository of approved artifacts, and it'd be better to point the requirements.yaml/Chart.yaml at that repository than to keep an extra copy. (How do you handle open-source library dependencies in general?)

Even if you have a local dependency chart or support chart library, it's better to properly version it and publish it to a chart repository than to replicate its tarball in charts/ directories. The only benefit to putting a dependency in charts/ is not needing to have it in a repository, but you'll usually want a repository for ease of management.

-- David Maze
Source: StackOverflow