Architecture Decision Record: Helm and Kustomize Handling

Name: Taha Hawa

Initial Date: 2025-04-15

Last Updated Date: 2025-04-15

Status

Proposed

Context

We need to find a way to handle Helm charts and deploy them to a Kubernetes cluster. Helm has a lot of extra functionality that we may or may not need. Kustomize handles Helm charts by inflating them and applying them as vanilla Kubernetes yaml. How should Harmony handle it?

Decision

In order to move quickly and efficiently, Harmony should handle Helm charts similarly to how Kustomize does: invoke Helm to inflate/render the charts with the needed inputs, and deploy the rendered artifacts to Kubernetes as if it were vanilla manifests.

Rationale

Consequences

Pros:

Much easier (and faster) than implementing all of Helm's featureset
Re-use code from K8sResource already present in Harmony
Harmony retains more control over how the deployment goes after rendering (i.e. can act like Kustomize, or leverage Kustomize itself to modify deployments after rendering/inflation)
Reduce (unstable) surface of dealing with Helm binary

Cons:

Lose some Helm functionality
Potential lose some compatibility with Helm

Alternatives considered

Implement Helm fully
- Pros:
  - Retain full compatibility with Helm as a tool
  - Retain full functionality of Helm
- Cons:
  - Longer dev time
  - More complex integration
  - Dealing with larger (unstable) surface of Helm as a binary
Leverage Kustomize to deal with Helm charts
- Pros:
- Cons:

1.6 KiB Raw Blame History