We switched to jkcfg (https://jkcfg.github.io) for many of these same reasons and are very happy. Text templating on structured data is wrong for many reasons, and kustomize is quite inflexible. "Eww Javascript" but everybody knows it.
jkcfg reduced the amount of configuration code/data in our system by an order of magnitude or so.
> Text templating on structured data is wrong for many reasons, and kustomize is quite inflexible.
Amen! Was exactly my thinking.
> "Eww Javascript" but everybody knows it.
Well I don’t (at least not well) that’s why starlark was such a good choice - everyone on the team already knows this subset of python fairly well. Also because it has this amazing Go interpreter now it was much easier to integrate with native Kubernetes libraries.
Isopod is notable for allowing the fetching of remote data that can then be used to configure the kubernetes objects. Terraform and pulumi are the only other ones that allow this. Bad about isopod is that the tool does not appear to automatically delete resources in the cluster after they are deleted from the code, and instead, a delete function must be called manually. That is a conceptual weakness compared to terraform and pulumi, and also a weakness compared to `kubectl apply --prune`.
I have great respect for your work. Do you have ideas or plans how to automatically delete objects in the cluster after they were deleted from the code? Terraform and pulumi are notable for maintaining their own state outside of the cloud provider or kubernetes, and this state can go out of sync, but `kubectl apply --prune` should not need that.
Appreciate! Charles had really polished it up too and did all the heavy lifting for open-sourcing this thing so big kudos to him and other Cruisers who contributed!
For deletion I explored a similar approach used in helm3 - use tombstone object (crd) for every deploy and store the state there. Kubernetes objects are simply deleted if they didn’t appear in kube.put in the latest release and for any other state you can use “remove” callback from config itself because full config is stashed in kubernetes for every deploy.
jkcfg reduced the amount of configuration code/data in our system by an order of magnitude or so.