53 lines
1.6 KiB
Markdown
53 lines
1.6 KiB
Markdown
# 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:
|
|
-
|
|
|
|
## Additional Notes
|