<p>Using <a href="https://kustomize.io/" rel="nofollow noreferrer">Kustomize</a> you can combine multiple helm charts and make tweaks to them on the fly.  <a href="https://jfrog.com/blog/power-up-helm-charts-using-kustomize-to-manage-kubernetes-deployments/" rel="nofollow noreferrer">JFrog has a tutorial</a> for doing this sort of thing.</p>

CC BY-SA 4.0
2022-08-09T20:40:49.640Z
2022-08-09T20:40:49.640Z
chicks
<p>There can be advantages to this. I have seen situations where &quot;includes&quot; can become very unwieldy. For example in C/C++, include files can go many, many layers deep.</p>
<p>If I have in my main entry point an &quot;include&quot; statement, I then have to go to another file to see what any code in that included file does if I know a function/procedure was not defined in my main file. If I get there and there is another &quot;include&quot; statement, and it turns out the function is not in this file either, but in the included file, I then have to look in <em>another</em> third file to figure out what my function/procedure does and how it works.</p>
<p>Now repeat that for a total of 5 times for multiple functions. Pretty brutal, right?</p>
<p>But similarly, the point is to be modular. It allows you to have a library that can be used by multiple programs. An example is the &quot;math&quot; library, or a library that allows you to format output.</p>
<p>You have similar here. You have a chart for Postgres, and one for ELK. Presumably, you might use those for other containers in the future. In this case, it makes sense to keep them broken out separately, so that you can re-use those charts for those other containers instead of having to copy the entire contents or sections of a monolithic chart. You can update <em>all</em> of your containers' ELK configurations if something changes for your ELK cluster. So you just have to think about if it makes sense to have something more monolithic (because it is specific to this container and only ever will be) or to modularize it because you will re-use it elsewhere.</p>
<p>So the answer to your question is ultimately situationally dependent. You can't say &quot;best practice is to <em>always</em> to put the YAML in a single chart&quot; because it just depends on your use case.</p>
<p><a href="https://devops.stackexchange.com/a/16413/2845">chicks answer</a> allows you to have the best of both worlds - you don't need to go hunting for code, but you also can still modularize when it makes sense.</p>

CC BY-SA 4.0
2024-06-03T17:50:40.507Z
2024-06-03T17:50:40.507Z
James Shewey
<p>It’s definitely a best practice in terms of maintaining k8’s manifests because with a single chart you have all the manifests in a single location and never have to worry about forgetting a specific manifest while deploying the application.</p>
<p>In the templates directory, write the configuration needed for all the services (Postgres, Spark and ELK monitoring) in <em>deployment.yml</em>, <em>service.yml</em>, <em>ingress.yml</em> as needed and do a<code>helm install</code></p>

CC BY-SA 4.0
2022-09-10T15:57:55.897Z
2022-09-10T15:57:55.897Z
Venkat Rahul
<p>I'm new to Helm and my first task was to recreate a simple pipeline. This pipeline is just:</p>
<p>PostgreSQL -&gt; Spark, with ELK monitoring the instances.</p>
<p>Someone mentioned I may be able to combine all of these into a single Helm chart; such that when I run the Helm chart it spins up PostgreSQL, Spark, and ELK. Is there any advantage to this? Before I attempt to do this, is it a best practice or would it be better to keep each one separate?</p>

<docker><kubernetes><containers><helm>
Combine Helm charts or leave separate?
Hustlin
# Combine Helm charts or leave separate?

(Asked by: username_0 on 2022-08-09)

I'm new to Helm and my first task was to recreate a simple pipeline. This pipeline is just:

PostgreSQL -> Spark, with ELK monitoring the instances.

Someone mentioned I may be able to combine all of these into a single Helm chart; such that when I run the Helm chart it spins up PostgreSQL, Spark, and ELK. Is there any advantage to this? Before I attempt to do this, is it a best practice or would it be better to keep each one separate?

**Tags:** docker, kubernetes, containers, helm


---

## 3 answers

### Answer by username_1 on 2022-08-09. Score: 2

Using [Kustomize](https://kustomize.io/) you can combine multiple helm charts and make tweaks to them on the fly. [JFrog has a tutorial](https://jfrog.com/blog/power-up-helm-charts-using-kustomize-to-manage-kubernetes-deployments/) for doing this sort of thing.


---

### Answer by username_2 on 2024-06-03. Score: 0

There can be advantages to this. I have seen situations where "includes" can become very unwieldy. For example in C/C++, include files can go many, many layers deep.

If I have in my main entry point an "include" statement, I then have to go to another file to see what any code in that included file does if I know a function/procedure was not defined in my main file. If I get there and there is another "include" statement, and it turns out the function is not in this file either, but in the included file, I then have to look in *another* third file to figure out what my function/procedure does and how it works.

Now repeat that for a total of 5 times for multiple functions. Pretty brutal, right?

But similarly, the point is to be modular. It allows you to have a library that can be used by multiple programs. An example is the "math" library, or a library that allows you to format output.

You have similar here. You have a chart for Postgres, and one for ELK. Presumably, you might use those for other containers in the future. In this case, it makes sense to keep them broken out separately, so that you can re-use those charts for those other containers instead of having to copy the entire contents or sections of a monolithic chart. You can update *all* of your containers' ELK configurations if something changes for your ELK cluster. So you just have to think about if it makes sense to have something more monolithic (because it is specific to this container and only ever will be) or to modularize it because you will re-use it elsewhere.

So the answer to your question is ultimately situationally dependent. You can't say "best practice is to *always* to put the YAML in a single chart" because it just depends on your use case.

[username_1 answer](https://devops.stackexchange.com/a/16413/2845) allows you to have the best of both worlds - you don't need to go hunting for code, but you also can still modularize when it makes sense.


---

### Answer by username_3 on 2022-09-10. Score: -1

It’s definitely a best practice in terms of maintaining k8’s manifests because with a single chart you have all the manifests in a single location and never have to worry about forgetting a specific manifest while deploying the application.

In the templates directory, write the configuration needed for all the services (Postgres, Spark and ELK monitoring) in *deployment.yml*, *service.yml*, *ingress.yml* as needed and do a`helm install`


---

