Helm and Kustomize are two popular tools used for managing Kubernetes manifests efficiently. Both of them have their usage & Utilities. Here my take is based on the GitOps approach.
It is essential to have a clear distinction between Immutable and Mutable aspects of the application while implementing the GitOps Strategy. Choice of tool(Ex: ArgoCD,..) is irrelevant here.
- Immutable aspect refers to a single source of truth of the Application(Ex: Deployment Definition). This aspect remains unchanged except when there is a release update for the application.
- Mutable aspect is the application parameters changing from namespace to namespace or from one cluster to another cluster.Ex: number of replicas in Kubernetes deployment definition.
In the above picture, the left side depicts a sampleKustomize project & it’s patch(deployment-patch.yaml) deployed in 3 environments (dev/test/prod) . The red block shows the immutable aspect, which is acting as a single source of truth.
The right side depicts a sample Helm Chart & it’s values.yaml. The red block shows the immutable aspect, which is acting as a single source of truth. To deploy this helm chart in 3 different environments as above, it requires 3 different values. yaml.
As Kustomize deployment is based on that patch, it requires providing the exact definition, which is from GitOps point of view is immutable aspects and getting repeated with all the environment. If any release of an application changes this aspect (Ex: apiVersion: apps/v1 →apiVersion: apps/v2), it is required to change all the mutable deployment-patch.yaml .This makes things very hard to maintain in a large environment where instead of 3, there are 100s of environments.
At the same time in the case of the helm, one needs to change only template deployment.yaml and release the application and there is no impact on Mutavle aspect.
