You can use a single chart with both deployments or a master chart with two subcharts one for app-nginx-phpfpm.yaml and one for app-mysql.yaml. If your whole app is not going to grow that much you can use a single chart. However, if you plan to keep adding components to your app (more deployments, etc) it's recommended that you use subcharts. More information here.

You can have both, depending on how you want to structure your deployments.

You should keep in mind the following

Considerations

Single chart benefits

• Easier to deploy: only deploy once, single diffing
• Single version, so rollback/upgrades happen on a single element
• You can uninstall parts by using feature flags
• Installing a new component without touching the rest of the elements may prove tricky

Single chart caveats

• Harder to deploy uncoupled services, e.g., a mock service for data access while upgrading the database
• Harder to decouple and test each instance
• Harder to name and make sense of each component (in different releases your {{.Release.Name}} would already change for each "app").
• Harder to provide/keep track of different release cycles for different components
• Versions stored in a single ConfigMap, which may lead to size limit problems if you have charts which contain, for example, testing data embedded

Note on version control

You can have a master chart that you use for testing with all subcharts, and package the subcharts independently but still have everything on the same repo.

For example, I usually keep things like either:

. / helm / charts / whatever / charts / subchart1
. / helm / charts / whatever / charts / subchart2
. / helm / charts / whatever / values.yaml

or

. / helm / charts / whatever-master / values.yaml
. / helm / charts / whatever-master / requirements.yaml
. / helm / charts / whatever-subchart1 / values.yaml
. / helm / charts / whatever-subchart2 / values.yaml

And use the requirements.yaml on the master chart to pull from file://../whatever-subchartx.

This way I can have whatever-stress-test and whatever-subcomponent-unit-test while still being flexible to deploy separately components that have different release cycles if so wanted.

This will in the end also depend on your upgrade strategy. Canary upgrades will probably require you to handle stateful microservices in a more specific way than you can have with a single chart, so plan accordingly.

Charts may depend on other charts; reference - https://helm.sh/docs/glossary/#chart-dependency-subcharts.

If you have a parent application, say: - greetings-app and 2 child applications, say: - helloworld - hiworld

You can create a chart for the parent "greetings-app" and then within the "charts/" directory have the charts of "helloworld" and "hiworld" moved or created then when you install the chart "greetings-app" - you will install the dependent charts along with it automatically. You will need to create "requirements.yaml" in the parent (greetings-app) listing the dependencies

dependencies:
  - name: helloworld
  - name: hiworld

Illustrative charts folder Structure would be :-

• greetings/
  • charts/
  • helloworld/
    • charts/
    • templates/
    • ....
  • hiworld/
    • charts/
    • templates
    • ....
  • Chart.yaml
  • requirements.yaml # this lists the dependencies

Alternate way is package the child applications and host them on a http server (GitHub) and then create the requirements.yaml listing the dependencies

dependencies:
  - name: helloworld-app
    repository: https://raw.githubusercontent.com/.../myhelmcharts/master/
    version: 0.1.0
    tags:
      - helloworld
  - name: hiworld-app
    repository: https://raw.githubusercontent.com/.../myhelmcharts/master/
    version: 0.1.0
    tags:
      - hiworld

The later is probably the preferred method - in my view is soft dependency but the application is managed separately.