I don't like the idea of replacing one well known YAML schema (k8s as much as I hate it is well known), with another YAML schema that is not well known. I think I'd rather use something to get away from YAML altogether, rather than just trade one for another. The reason helm and kustomize work well is that your existing k8s resource knowledge transfers, it sounds like it wouldn't with this thing.
this post was submitted on 24 Dec 2023
22 points (89.3% liked)
Programming
17528 readers
248 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
Oh, it's all still Kubernetes YAML. The difference is in how it's represented. Helm Charts are packaged Golang templates of Kubernetes YAML, and as such have a whole lot of limitation since the only logic you can put into them is Golang template logic.
This is still Kubernetes YAML, but instead you write any program you want to return the YAML, as long as it fits in the sandbox, so it's pretty open-ended. For example, as a stretch goal, I might add an engine to it that could recompile Helm Charts into Mistletoe Modules.
I have no idea what any of your jibberjabber means but it sound suspiciously like an excuse to try to get someone to kiss you under the forced premise of a holiday tradition.
I think it would be helpful if you outlined where helm is falling short for you.
Personal opinion: I think packaging k8s manifests in OCI image format is probably the future. Helm, Kustomize, etc may still be useful in generating the yaml, but the "package management" part will be OCI image registries.
So Helm never fell short for me as an end user. As far as that goes, it's near-perfect.
Where it does fall short is as a package writer. A package in Helm is just Kubernetes YAML that's templated in Golang templates. As such, it gets very hard to any logic beyond the most basic, and projects that get larger get very unwieldy.
Hmm, what's your idea for the OCI image format, e.g., how would it work? That might be worth looking into, too.
OCI allows you to package arbitrary content in a docker image. In this case it would be a collection of k8s yaml files. Two main benefits of this approach are:
- Your gitops tool only needs image registry access, not git access
- The OCI image contains the final yaml. Your CI pipeline is responsible for generating the image.
Flux already supports this and I other tools to follow.