Creating, Developing, and Testing a Helm Chart
The Starter Template
Helm provides a starter template that can be used as a base for creating new charts. The general syntax for bootstrapping a new chart is:
helm create [CHART_NAME]
In our case, we will create a chart named todo-chart:
# CD into the home directory
cd $HOME
# Create the chart with the name "todo-chart"
# the chart name is usually lowercase and hyphenated
helm create todo-chart
The previous command will create a directory named todo-chart (under the current directory) with the following structure:
todo-chart/
├── Chart.yaml
├── charts
├── templates
│  ├── NOTES.txt
│  ├── _helpers.tpl
│  ├── deployment.yaml
│  ├── hpa.yaml
│  ├── httproute.yaml
│  ├── ingress.yaml
│  ├── service.yaml
│  ├── serviceaccount.yaml
│  └── tests
│  └── test-connection.yaml
└── values.yaml
The templates directory is the main part of the chart. It contains the Kubernetes manifest templates that Helm uses to generate the final manifests during installation or upgrade. Here is a brief description of each file and directory inside this directory:
deployment.yaml: Use this template to manage the lifecycle of your application Pods, rolling updates, and scaling.
This file is a template for a Kubernetes Deployment resource. It defines how to deploy the application, including the number of replicas, the container image to use, ports, probes, resource requests/limits, and other configurations like node selectors, tolerations, affinity, and security contexts.
service.yaml: Use this template to define how your application is accessed within the cluster or from outside.
This template defines a Kubernetes Service resource for the todo-app application. It is usually used to expose the Deployment defined in deployment.yaml to other services within the cluster (ClusterIP) or externally (LoadBalancer/NodePort).
ingress.yaml: Use it when you want to expose your application via HTTP/HTTPS using an Ingress controller.
If your application is an HTTP/HTTPS service, this template defines an Ingress resource to manage external access to the service. It allows you to set up hostnames, paths, TLS termination, and routing rules.
serviceaccount.yaml: Use it to manage RBAC permissions for your application.
If your application requires specific permissions to interact with the Kubernetes API, this template defines a ServiceAccount resource. It can be used to create a dedicated identity for your application pods.
hpa.yaml: Use it to scale your application based on resource usage.
The HorizontalPodAutoscaler (HPA) template allows you to define automatic scaling policies for your deployment based on CPU/memory usage or custom metrics.
httproute.yaml: Use it to define routing rules using the Gateway API.
This template defines an HTTPRoute resource, which is part of the Gateway API. It allows you to specify how HTTP traffic should be routed to your application based on hostnames, paths, and other criteria.
ℹ️ The Gateway API is an evolution of the Ingress API, providing more flexibility and features for routing traffic in Kubernetes.
tests/: Use it to validate your application after installation.
In this directory, you can define Helm tests that will be executed after the chart is installed or upgraded. These tests can be used to verify that the application is running correctly. Tests are usually defined as Pods that perform checks against the deployed application and report success or failure.
Example: The following content is an example of a Helm test defined in the tests/smoke-test.yaml file:
# tests/smoke-test.yaml
apiVersion: v1
kind: Pod
metadata:
name: "{{ include "myapp.fullname" . }}-test"
annotations:
"helm.sh/hook": test
spec:
restartPolicy: Never
containers:
- name: curl
image: curlimages/curl:8.10.1
args: ["-f", "http://{{ include "myapp.fullname" . }}.{{ .Release.Namespace }}.svc.cluster.local/healthz"]
The image curlimages/curl:8.10.1 is used to create a Pod that will attempt to connect to the /healthz endpoint of the deployed application.
Where:
{{ include "myapp.fullname" . }}: is a Helm helper function that returns the full name of the application (usually the release name + chart name). The same name is used when creating the Service resource in theservice.yamltemplate.
# service.yaml
apiVersion: v1
kind: Service
metadata:
# This is the service name created for the application
name: {{ include "myapp.fullname" . }}
labels:
{{- include "myapp.labels" . | nindent 4 }}
spec:
typeHelm in Practice
Designing, Deploying, and Operating Kubernetes Applications at ScaleEnroll now to unlock current content and receive all future updates for free. Your purchase supports the author and fuels the creation of more exciting content. Act fast, as the price will rise as the course nears completion!
Hurry! This limited time offer ends in:
To redeem this offer, copy the coupon code below and apply it at checkout:
