Isopod: Expressive DSL Framework for Kubernetes Config(github.com)
github.com
Isopod: Expressive DSL Framework for Kubernetes Config
https://github.com/cruise-automation/isopod
11 comments
> 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.
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`.
CUE also allows this in their scripting layer.
https://cuelang.org
https://godoc.org/cuelang.org/go/pkg/tool/http
https://cuelang.org
https://godoc.org/cuelang.org/go/pkg/tool/http
This is wip. I made some big strides in that direction but wasn’t able to finish it in time.
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.
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.
Ew. Isopods are gross. Questionable naming here...
Your username is 'zoidberg'. Hatin' on your fellow crustaceans, eh?
jkcfg reduced the amount of configuration code/data in our system by an order of magnitude or so.