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):

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.

Categories
OpenShift Ecosystem, Products
Tags
,