Helm uses Go templates. You define your variables in a top level values.yaml, and then install the chart to your cluster. The variables get expanded on chart install.

Here is a snippet from a deployment:

    env:
        {{- range $key, $value := .Values.my_env_vars }}
          - name: {{ $key }}
            value: {{ $value  | quote }}
        {{ end }}

I'd really like to get rid of my custom hacky kubectl wrapper scripts and either just use a cluster add-in or have a kubectl build-in processor that helps reuse.

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.

You can define an inheritance relationship, where your template inherits pretty much everything EXCEPT the environment variables. Or the jsonnet cli lets you specify variables to be replaced in the template.

There's some kubernetes flavored examples in [1].

[0] http://jsonnet.org/

[1] https://github.com/google/jsonnet/tree/master/case_studies/k...

[1] https://github.com/InQuicker/ktmpl [2] https://github.com/kubernetes/kubernetes/blob/master/docs/pr...