4 ms·

The better way is to use manifest generators with a Turing-complete language. I wrote such a tool in Ruby. The problem is that it is written in Ruby. It's grea

by hosh 2y ago

The better way is to use manifest generators with a Turing-complete language. I wrote such a tool in Ruby. The problem is that it is written in Ruby. It's great for shops that already have Ruby expertise. Wherever I have implemented this, it's worked out great. I have my doubts about it in other shops. The community went a different way -- starting with templated JSON (not even JSON transforms). It was the least common denominator. This is an issue with the ecosystem rather than design flaws of Kubernetes itself.

lmm 2y ago
Sort of. Kubernetes is lowest common denominator by design. Specific ecosystems had much more efficient solutions to these problems (e.g. rather than having to deploy a whole docker container to do a version upgrade you deploy just your specific web application) but the problem was those solutions only worked for those specific ecosystems.
- hosh 2y ago
  I disagree. Kubernetes is composed from primitives that can be applied in versatile ways. Those primitives can be swapped out for even greater extensibility. Kubernetes is not the lowest common denominator, and more of a toolkit that can broadly and deeply applied to many setups. Templated yaml or json is a step backwards. Those are not composable. If we wanted something like that, then we would need to at least be able to do merges and transforms. Something like jquery or css for yaml that allows to transform fields based upon selectors. Manifest generators using a real language, on the other hand, start with data structures that can be merged and transformed before its final output as yaml. They can take advantage of language features. The one I wrote in Ruby can take advantage of class inheritance and mixins, allowing me to define common configs across resources. Someone who can distill the algebra of merging Kubernetes manifests can do that for a functional programming language.
jamesfinlayson 2y ago
> The better way is to use manifest generators with a Turing-complete language. I wrote such a tool in Ruby. I've seen something similar at a previous company - some Ruby DSL written to generate CloudFormation. It was used in another department though so not sure how well it worked in practice.

by hosh 2y ago

lmm 2y ago

Sort of. Kubernetes is lowest common denominator by design. Specific ecosystems had much more efficient solutions to these problems (e.g. rather than having to deploy a whole docker container to do a version upgrade you deploy just your specific web application) but the problem was those solutions only worked for those specific ecosystems.

hosh 2y ago
I disagree. Kubernetes is composed from primitives that can be applied in versatile ways. Those primitives can be swapped out for even greater extensibility. Kubernetes is not the lowest common denominator, and more of a toolkit that can broadly and deeply applied to many setups. Templated yaml or json is a step backwards. Those are not composable. If we wanted something like that, then we would need to at least be able to do merges and transforms. Something like jquery or css for yaml that allows to transform fields based upon selectors. Manifest generators using a real language, on the other hand, start with data structures that can be merged and transformed before its final output as yaml. They can take advantage of language features. The one I wrote in Ruby can take advantage of class inheritance and mixins, allowing me to define common configs across resources. Someone who can distill the algebra of merging Kubernetes manifests can do that for a functional programming language.

jamesfinlayson 2y ago

> The better way is to use manifest generators with a Turing-complete language. I wrote such a tool in Ruby. I've seen something similar at a previous company - some Ruby DSL written to generate CloudFormation. It was used in another department though so not sure how well it worked in practice.