Default Helm Template

burmi — Sat, 03 Feb 2024 09:13:02 +0000

Helm is my favorite way to deploy to Kubernetes. I got a little sick of making the same changes to the default files that helm create creates, so here is my go-to default helm template for simple apps, services, and microservice.

TL;Dr

Find the chart in my template repository here.

Introduction

In general, if you want to create a Helm chart for your app or whatever, helm create <app name> is a great place to start. It comes with almost everything you need to make basic deployment, however, if you want to be a little more flexible and explicit, you need to make some changes.

For once, the Ingress resource still has a version check for Kubernetes below version 1.18. or even 1.14.. If you still run Kubernetes in that version, stop everything and upgrade now! 😉

Also, the Deployment and Service need some rework to make changes to the source and target ports in the values.yaml.

In the following chapters, I go over the changes I made. You can follow along and crate a chart locally using helm create app and see what needs to be changed.

Testing

I remove the testing folder because I usually do not need it, I to use liveness- and readiness probes because its more accurate and has even more advantages.

Helper

Helm allows you to define helper functions to create values, such as names. If you have a look at the built-in helper it shows you how to define names for the resources you use, create a selection of labels, annotations, and selectors. I made some minor changes to create the name for the resources based on the parameter appName in the values.yaml.

Other resources will be named by that name plus the suffix of the type. So the appName mail will create a service called mail-svc. Same goes for the HPA - mail-hpa. The only exception are deployments, or pretty much anything that creates and manages pods, because their name depends on the name of the managing resource.

I would urge to expend the list if you add other resources, because it makes referencing them much easier and will reduce later confusion for you (when you come back to this), or your colleagues.

The file is called _helpers.tpl.

Service

The server needs to be edited to specify all of the parameters you see below:

apiVersion: v1 
kind: Service 
metadata: 
  name: {{ include "app.serviceName" . }} 
  labels: 
    {{- include "app.labels" . | nindent 4 }} 
spec: 
  type: {{ .Values.service.type }} 
  ports: 
    - port: {{ .Values.service.port }} 
      targetPort: {{ .Values.service.targetPort }} 
      protocol: {{ .Values.service.protocol }} 
      name: {{ .Values.service.name }} 
  selector: 
    {{- include "app.selectorLabels" . | nindent 4 }}

This implies we need to change the values.yaml to include those information as well:

service: 
  type: ClusterIP 
  port: 8080 
  targetPort: 80 
  protocol: TCP 
  name: http

but also the deployment.yaml to include the service changes:

ports: 
  - name:  {{ .Values.service.name }} 
    containerPort: {{ .Values.service.targetPort }} 
    protocol:  {{ .Values.service.protocol }}

Check the files in the repo mentioned above.

Deployment

The heart of the deployment of an application is the Pod managing entity, which is usually the deployment object. Others like Stateful Sets, Daemon Sets, Jobs or CronJobs are also possible. The deployment has the name of the value appName provided in the values.yaml. In addition to the by default created properties, I have added the following specs:

Init Containers
Liveness and Readiness probes are now passed in by the values.yaml and must be set.
Environment Variables can be passed into deployment in many different ways - either a direct value assignment, or as a secret- or config map key reference. This can be used in combination with a tool like external-secrets.

HPA

For the HPA, I only added the new variable of the deployment.

Service Account

Same thing as for the HPA, name change only.

PodDisruptionBudget

The PodDisruptionBudget ensures the desired number of pods that is available during voluntary disruptions - for instance by scaling down nodes. Involuntary disruptions like an outage can not be considered. When the HPA is enabled, the minimum number of pods will be used, otherwise, the PodDisruptionBudget.minAvailable will be used.

New Resources

You can add new resources like certificates, keda-scaler, whatever the case might be, I would suggest the following points:

create a name in the _helpers.tpl with an appropriate suffix
add metadata as shown in all objects of this template
- do not include the namespace!
use helm template functions if necessary

Please feel free to use the template and make changes as you like, this is my baseline whenever I need to deploy something and it has never let me down.

DEV Community: burmi