OpenShift templates vs Helm templates

    I gathered in the following table a few arguments that might help you make up your mind.


    OpenShift templates

    Helm templates


    Comes natively with OpenShift

    A few steps need to be taken



    Tiller needs at least edit rights on all the projects you want to deploy into. (Admin if your Charts contains Role)

    Configuration file language

    A unique (long) file with a resource of a kind “template” listing all your resources, written in json or yaml with the insertion of variables following shell syntax ${}

    Several files in the template folder of your Chart, written in yaml with insertions of variables in go

    Templating structures


    Some coding structures such as iteration and condition. some utilities for text formatting (base64, indent, ...)

    Variable file name

    By convention in .params files

    In values.yaml

    Orchestrator coupling

    Only exists on OpenShift

    Works with OpenShift and kubernetes

    Release versioning


    Allows creating releases and rollback if needed

    Resources, sharing

    Some templates to install applications are available on GitHub, you can store your template in the cluster in object form so that anyone with reading access can use them

    The dynamic community provides Charts but they sometimes need to be adapted to OpenShift for security reasons

    Overview of configuration files

    Let us now compare basic syntaxes for configuration files. Here is what an OpenShift template.yaml looks like:

    You will then provide your variables in your production.params file:

    And deploy it with the command

    oc process template.yaml --param-file=production.params | oc apply -f -

    In the Helm case, you would have configmap.yaml, deployment.yaml, service.yaml, route.yaml configuration files in your templates folder. For instance, the configmap.yaml would look like this

    Your Values.production.yaml would contain something like

    And you would apply your template using

    helm upgrade -i my-release -f values.yaml

    Helm much more than templating

    Having said that, we should emphasize the fact that Helm is much more than just a templating tool. It is a package manager, with a dynamic community that prepares Charts for quick installation. A simple Helm install --name my-release stable/elasticsearch  will install an elastic search on your cluster. However, to use Helm Charts on OpenShift, you might need to adapt them, for instance, if the containers of a Chart run as root (forbidden by default on OpenShift).

    Security: Version 3 of Helm will reconcile OpenShift and Helm

    Overall the main argument against Helm is the loose privileges granted to Tiller. Since the default enabling of Role-Based Access Control in Kubernetes, Helm developers chose to give it default high privileges. That way new users can quickly start playing without having to deep dive into security controls. However, in recent articles, Helm developers announced Tiller will be removed in Helm 3. Indeed, the cluster’s shared release management that Tiller was taking care of, will be assured by Kubernetes resources and requests to the API server. User will be able to deploy through Helm only what their Kubeconfig allow them to. We will thus regain the wanted granularity of privileges.

    In the end, we have decided not to use Helm, to not give Tiller the high privileges it needs at the moment. Also, since we only need the templating functionality at the moment, Helm appears a bit as an overkill. However, the second Helm 3 is stable (it is alpha 2 at the moment) we will probably switch to it. If you want to debate or ask questions about templating on OpenShift, feel free to contact us.