Kubernetes State of Application Templating

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:

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

  name: sise-deploy

spec:

  replicas: 2

  template:

    metadata:

      labels:

        app: sise

    spec:

      containers:

      - name: sise

        image: mhausenblas/simpleservice:0.5.0

        ports:

        - containerPort: 9876

        env:

        - name: SIMPLE_SERVICE_VERSION

          value: "0.9"

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 kubectl) work.

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.