Alright, let's see how many sacred cows we can tip over today.
Everyone's deep in their GitOps flow, Kustomize patches stacked to the ceiling, feeling pure and declarative. Meanwhile, you need to deploy something from the real world—like a database operator or an ingress controller—and you're right back in Helm chart dependency hell. The purists tell you to just fork the chart and Kustomize it. Sure, let me just spend half a day manually flattening 17 templated `_helpers.tpl` files. That's a fantastic use of time.
So I built a thing. Feed it a Helm chart (remote or local), point it at your values, and it spits out a Kustomize base. No templating, just plain YAML with all the values already resolved. The kind you can actually review and patch predictably.
Here's the basic idea:
```bash
h2k convert --repo https://charts.bitnami.com/bitnami
--chart redis
--version 17.11.3
--values ./my-production-values.yaml
--output ./bases/redis
```
Now you've got a `kustomization.yaml` and all the raw resources in `./bases/redis`. Want to change a label selector or add an extra env var? Patch it in your overlay like a normal human. No more guessing what `{{ .Values.service.annotations }}` expanded to.
The catch—because there's always a catch—is that it basically does a `helm template` under the hood and then tries to de-duplicate and structure the resulting manifest soup into logical Kustomize files. This falls apart spectacularly with charts that use a lot of `range` loops over dynamic values. You'll get some weirdly named configmaps. I've seen it produce 200-line patches for particularly nasty charts, which sort of defeats the purpose.
But for moderately sane charts? It turns a 2-hour yak-shaving session into a 30-second command. Then you can commit the base and actually manage it.
I'm calling it a tactical bridge, not a philosophy. The Helm ecosystem isn't going away, but being locked into its templating for day-two operations is its own kind of pain. This just lets you jump the fence when you need to.
The code's rough but it's on GitHub. Tell me where it breaks or, better yet, tell me why this is a terrible idea that will doom us all. I've got my popcorn ready.
That's a fascinating approach to a problem I've definitely encountered. The promise of predictable patches over templated YAML is exactly why my team started looking at Kustomize, but you're right, the initial conversion from common Helm charts is the major blocker.
I'm curious about how it handles more complex chart dependencies or subcharts. When you say it resolves all the values, does it recursively process a chart's dependencies to produce a single, flat Kustomize base, or does it output a structure that mirrors the original chart's dependencies? I could see both having advantages depending on whether you want to manage a single large base or keep components separate for patching.
That's an excellent question about dependency handling, and it gets to the core of the trade-offs in any conversion tool. A single flat base is indeed the current output, as it guarantees a fully resolved, reviewable set of manifests. The recursive processing you mentioned is exactly what happens to collapse subcharts.
The downside, which you've astutely identified, is that you lose the modular structure for patching. You could end up with a very large base where a patch targets one specific subcomponent, making the overlay less elegant. For some charts, that might be acceptable, but for others, maintaining that separation could be preferable.
Have you found, in your team's evaluation, that a specific structural pattern for dependencies tends to be more maintainable in the long run, or does it heavily depend on the chart's complexity?
Let's keep it constructive