Helm alternative

This is a follow-up to a great post “Think twice before using Helm”. Recently we’ve had a lot of questions about what could be an alternative to Helm. In this blog post I will try to show you an alternative.

What do we need

To download render application visit:
https://github.com/VirtusLab/render

Helm Chart that is interesting for us — can be downloaded here:
https://github.com/helm/charts

How to do it — TL/DR

Get Chart you are interested in.
Remove unneeded stuff from both directory structure and files.
Merge all templates into one — following desired resource creation order (optional but recommended).
Render the newly created template file with desired config file(s).
Commit to your VCS (optional but recommended).
Deploy to Kubernetes
Feel good!

How to do it —instructions in more details

Let’s convert a Helm Chart to plain Kubernetes manifest template. As an example we will use kube2iam Chart.
Let’s have a look what can be found in typical Chart directory:

To create valid Kubernetes manifest we only need these files:

clusterrole.yaml
clusterrolebinding.yaml
daemonset.yaml
secret.yaml
serviceaccount.yaml

and a confog file:

values.yaml

Now we can merge them into single file (ensure resource creation order as a good practice):

1find . -type f -not -name kube2iam.yaml.tmpl -not -name NOTES.txt -not -name _helpers.tpl -exec echo "---" \; -exec cat {} \; > kube2iam.yaml.tmpl

Next step for our newly created template file is to remove stuff that is not needed anymore. All Helm specific variables should be removed since we do not need them.

These would be variables and functions using:

1sed -i '/.Chart/d' ./kube2iam.yaml.tmpl
2sed -i '/.Release/d' ./kube2iam.yaml.tmpl

Be aware that this is a quick workaround. I strongly recommend to make these changes manually so you can make sure you are not introducing any breaking changes or leaving leftovers in the template file.

Search for .Capabilities in template and remove it since this is pure Helm functionality.

{{ template "kube2iam.name" }} and {{ template "kube2iam.fullname" }} can be changed to .Name and .FullName.

Finally all configuration variables are passed without the `.Values` prefix. This means you can remove it from your new manifest template by running the following command (again, please use this command with caution and review the results):

1sed -e 's/.Values//g' -i ./kube2iam.yaml.tmpl

After all modifications we get a nice and clean kube2iam.yaml.tmpl manifest template which should look like this:

1---
2{{- if .rbac.create -}}
3apiVersion: v1
4kind: ServiceAccount
5metadata:
6  labels:
7    app: {{ .Name }}
8  name: {{ .FullName }}
9{{- end -}}
10---
11{{- if .rbac.create -}}
12apiVersion: rbac.authorization.k8s.io/v1beta1
13kind: ClusterRoleBinding
14metadata:
15  labels:
16    app: {{ .Name }}
17  name: {{ .FullName }}
18roleRef:
19  apiGroup: rbac.authorization.k8s.io
20  kind: ClusterRole
21  name: {{ .FullName }}
22subjects:
23  - kind: ServiceAccount
24    name: {{ .FullName }}
25{{- end -}}
26---
27{{- if .rbac.create -}}
28apiVersion: rbac.authorization.k8s.io/v1beta1
29kind: ClusterRole
30metadata:
31  labels:
32    app: {{ .Name }}
33  name: {{ .FullName }}
34rules:
35  - apiGroups:
36      - ""
37    resources:
38      - namespaces
39      - pods
40    verbs:
41      - list
42      - watch
43{{- end -}}
44---
45apiVersion: extensions/v1beta1
46kind: DaemonSet
47metadata:
48  labels:
49    app: {{ .Name }}
50  name: {{ .FullName }}
51spec:
52  template:
53    metadata:
54    {{- if .podAnnotations }}
55      annotations:
56{{ toYaml .podAnnotations | indent 8 }}
57    {{- end }}
58      labels:
59        app: {{ .Name }}
60      {{- if .podLabels }}
61{{ toYaml .podLabels | indent 8 }}
62      {{- end }}
63    spec:
64      containers:
65        - name: kube2iam
66          image: "{{ .image.repository }}:{{ .image.tag }}"
67          imagePullPolicy: "{{ .image.pullPolicy }}"
68          args:
69            - --host-interface={{ .host.interface }}
70          {{- if .host.iptables }}
71            - --host-ip={{ .host.ip }}
72          {{- end }}
73            - --iptables={{ .host.iptables }}
74          {{- range $key, $value := .extraArgs }}
75            {{- if $value }}
76            - --{{ $key }}={{ $value }}
77            {{- else }}
78            - --{{ $key }}
79            {{- end }}
80          {{- end }}
81          {{- if .verbose }}
82            - --verbose
83          {{- end }}
84            - --app-port={{ .host.port }}
85          env:
86            - name: HOST_IP
87              valueFrom:
88                fieldRef:
89                  fieldPath: status.podIP
90          {{- if and .aws.secret_key .aws.access_key }}
91            - name: AWS_ACCESS_KEY_ID
92              valueFrom:
93                secretKeyRef:
94                  name: {{ .FullName }}
95                  key: aws_access_key_id
96            - name: AWS_SECRET_ACCESS_KEY
97              valueFrom:
98                secretKeyRef:
99                  name: {{ .FullName }}
100                  key: aws_secret_access_key
101          {{- end }}
102          {{- if .aws.region }}
103            - name: AWS_DEFAULT_REGION
104              value: {{ .aws.region }}
105          {{- end }}
106          {{- range $name, $value := .extraEnv }}
107            - name: {{ $name }}
108              value: {{ quote $value }}
109          {{- end }}
110          ports:
111            - containerPort: {{ .host.port }}
112        {{- if .probe }}
113          livenessProbe:
114            httpGet:
115              path: /healthz
116              port: {{ .host.port }}
117              scheme: HTTP
118            initialDelaySeconds: 30
119            periodSeconds: 5
120            successThreshold: 1
121            failureThreshold: 3
122            timeoutSeconds: 1
123        {{- end }}
124          resources:
125{{ toYaml .resources | indent 12 }}
126        {{- if .host.iptables }}
127          securityContext:
128            privileged: true
129        {{- end }}
130      hostNetwork: true
131    {{- if .nodeSelector }}
132      nodeSelector:
133{{ toYaml .nodeSelector | indent 8 }}
134    {{- end }}
135    {{- if .affinity }}
136      affinity:
137{{ toYaml .affinity | indent 8 }}
138    {{- end }}
139      serviceAccountName: {{ if .rbac.create }}{{ .FullName }}{{ else }}"{{ .rbac.serviceAccountName }}"{{ end }}
140      tolerations:
141{{ toYaml .tolerations | indent 8 }}
142  updateStrategy:
143    type: {{ .updateStrategy }}
144---
145{{- if and .aws.secret_key .aws.access_key -}}
146apiVersion: v1
147kind: Secret
148metadata:
149  labels:
150    app: {{ .Name }}
151  name: {{ .FullName }}
152type: Opaque
153data:
154  aws_access_key_id: {{ .aws.access_key | b64enc | quote }}
155  aws_secret_access_key: {{ .aws.secret_key | b64enc | quote }}
156{{- end }}

Now we can render our template to a valid Kubernetes manifest:

1./render --in kube2iam.yaml.tmpl --config values.yaml --out kube2iam.yaml --set Name=kube2iam --set FullName=kube2iam_fullname

This will output rendered file kube2iam.yaml.tmpl to kube2iam.yaml file which can be deployed to Kubernetes:

1kubectl -n kube-system apply -f kube2iam.yaml

From now on we can live a happy and prosperous Helm free life.

Summary

Using simple rendering as a part of deployment process has a lots of benefits, but on the other hand you have to be aware of some of the more advanced Helm functionalities you lose with a simple renderer.

Pros:

simple deployment process with full visibility and useful audit logs
using native Kubernetes authorization mechanism (RBAC)
no more tiller server security issues (one giant sudo server)
no separate state in ConfigMap and Etcd
client side, transparent, git friendly rendering

Cons:

no complex Helm features like hooks
no Helm dependency management
no automatic removal of resources (kubectl diff might be helpful here)

Helm alternative

What do we need

How to do it — TL/DR

How to do it —instructions in more details

Summary

Subscribe to our newsletter and never miss an article

Explore more topics

Jenkins Operator Sunset

Cloud infrastructure end-to-end or conformance testing: What’s the difference

Cloud security policies in GCP: How to set them up using Terraform