Search code examples
kuberneteskubernetes-helm

Helm Chart Definitions for Multi Cluster Codebase


I have a project that contains the deployment descriptor files for Kubernetes. This project has a folder structure that looks like this:

> project-deployment
>  - base
>  - dev
>  - production

Inside the base folder, I have the kubernetes deployment files (deployment, service, namespaces etc.,). In the dev and production folder, I have kustomization.yaml that composes everything from the base folder. So far so good. I now want to introduce helm into this so that I can manage my releases much better. My question now is how do I go about structuring my folder structure?

Should I move everything (base, dev and production) folder into templates and just have one Charts.yaml and values.yaml? Any thoughts?


Solution

  • The configuration values that you push into your charts should be separate between environments. Build simple extendable charts that can have overrides per environment. For example, a good workflow would have different value files per environment with specific differences in configuration:

    ~/myapp
    └── config
    ├── production.yml
    └── staging.yml
    

    There are tools that can help you manage that particular use case. For example, consider using orca:

    What Orca does best is manage environments. An Environment is a Kubernetes namespace with a set of Helm charts installed on it. There are a few use cases you will probably find useful right off the bat.

    There are also some examples provided with it.

    I also recommend going through the official The Chart Best Practices Guide.