TL;DR: Templating in Kubernetes is an important topic and is in the process of being standardized.
In Kubernetes you've got a powerful way of expressing the desired state, be it for applications or global resources such as network attached volumes. These documents, typically written in YAML, declare what you want and by using
kubectl you can submit them to the API Server, which in turn takes care of reconciling the current state with what you desire. After this mouthful, let's have a look at a concrete example of a deployment spec:
- name: sise
- containerPort: 9876
- name: SIMPLE_SERVICE_VERSION
As you can see in above listing, there are certain values that you may wish to change, depending on the environment or stage you're in. For example, rather than hard-coding the value
0.9 for the environment variable
SIMPLE_SERVICE_VERSION in the YAML file, you might want to override it when you execute
kubectl apply or let Kubernetes fill it in automatically. This is a limitation of the current way specs (and
The community has realized this limitation—cf. Issue 11492—and is working on a solution. An important step in this direction is the design proposal Templates+Parameterization: Repeatedly instantiating user-customized application topologies and Issue 23896.
In the meantime, various groups and companies were working hard to come up with a few solutions on their own, including but not limited to (in alphabetical order, both templating languages and tooling):
- Ansible Kubernetes module
- Helm Charts, initially mainly by Bitnami and Deis (now: Microsoft)
- Forge by Datawire.io
- k8comp by cststack
- kedge by Red Hat
- kdeploy by Flexiant
- kpm by Coreos (note: no longer developed or maintained)
- ksonnet/kubecfg by Bitnami and Heptio
- ktmpl by InQuicker
- kubeapps.com by the Kubernetes community
- kubegen by Ilya Dmitrichenko of Weaveworks
- OpenCompose by Red Hat
- OpenShift Templates by Red Hat
- Puppet Kubernetes modul by Gareth Rushgrove of Puppet
- Yipee.io by Yipee.io
If you're interested in contributing I'd like to encourage you to join us in the Apps Special Interest Group to share your use case, your criticism and feedback to what has been achieved so far, and help shape the final outcome.
Kudos to my colleague Mike Hepburn who provided valuable input for this post as well as Antoine Legrand whose Apps SIG mailing list post I've used as the starting point for this blog post. Last but not least, thanks to Brian Grant who pointed out his listing of tools in the context of Issue 23896.