| I might as well plug in something I wrote to solve this problem in a different way. Warning: the project is undocumented, and require knowledge of Ruby. Obviously, if you don't like Ruby or like reading code, this will not work for you. https://github.com/matsuri-rb/matsuri Matsuri is built on the idea that K8S is a building block for higher-level tools. The gist is that rather than trying to template and substitute values, it uses Ruby class inheritance and mixins to construct the manifest being sent up to Kubernetes. Each key-value in the manifest schema is broken down into smaller, composable chunks. A single method `spec` composes it all together at the top. To customize, you use Ruby method overrides to override part or all of the methods used to generate specifications. This also allows you to mixin modules that partially override methods describing the manifest. This allows the YAML or JSON manifest to be programmatically constructed with a Turing-complete language rather than templated. The result is a single tool that allows you to describe pods (and services, etc.) that may require different things yet share some common functionality. For example, dev pods need to mount the source tree from the host and doesn't need secrets, doesn't need replication; staging and production might require volume mounts elsewhere and require secrets; staging might use a replication of n=1 while prod might be using replication n > 1; prod might have affinity, anti-affinity, and make use of node labelling while dev and staging do not. Matsuri also has an abstraction that groups collections of pods, services, and other K8S resources together into an "app". It also has standard hooks for common operations, such as attaching to containers, getting logs, etc. I have not updated Matsuri since around Feb of 2016, when I left the project this was extracted from. Sometime in the next six months or so, I'll be updating it again when I get my team's current project onto GCP. |