Learn Kubernetes with k3s - part5 - Helm

This post is the continuation of part 4.

Previously, I have used helm, the Kubernetes package manager to install an nginx application. To list all the releases

$ helm list
NAME      	NAMESPACE	REVISION	UPDATED                                	STATUS  	CHART        	APP VERSION
my-release	default  	1       	2024-03-19 22:58:08.794126266 +0800 +08	deployed	nginx-15.14.0	1.25.4

We can see the only one release my-release in the list. To get the release notes which was displayed on the initial installation

$ helm get notes my-release
NOTES:
CHART NAME: nginx
CHART VERSION: 15.14.0
APP VERSION: 1.25.4
...

To modify the application's config, modify values.yaml to

$ cat values.yaml
service:
  type: LoadBalancer

and run

$ helm upgrade my-release \
  oci://registry-1.docker.io/bitnamicharts/nginx \
  -f values.yaml

We see a confirmation message of the upgrade, and the content of the release notes has changed too. Run

$ kubectl get services/my-release-nginx
NAME               TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
my-release-nginx   LoadBalancer   10.43.206.241   <pending>     80:30080/TCP   6d22h

The service type of my-release-nginx has changed from NodePort to LoadBalancer. Note that this way of resource provisioning is a break from the imperative model of kubectl create as we now manage the application config in code: our values.yaml file.

To rollback

$ helm rollback my-release 1
$ kubectl get services/my-release-nginx
NAME               TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
my-release-nginx   NodePort   10.43.206.241   <none>        80:30080/TCP   6d22h

We see that we are back to release 1.

Now we are using the imperative model again, since the actual application config no longer aligns with what is in the code. We will find a more permanent solution to enforce IaC in future.

Finally to uninstall the application

$ helm uninstall my-release
release "my-release" uninstalled

You can find helm charts of many open-source applications on the public registry Artifact Hub. Sometimes the helm chart can be installed from an OCI link such as nginx.

Sometimes you would need to add a repository first. For example, to install milvus db,

$ helm repo add milvus https://milvus-io.github.io/milvus-helm/

$ helm repo list
NAME  	URL                                     
milvus	https://milvus-io.github.io/milvus-helm/

$ helm repo update

$ helm upgrade --install my-release milvus/milvus
Release "my-release" does not exist. Installing it now.
NAME: my-release
LAST DEPLOYED: Wed Mar 27 22:51:20 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

An organization who deploys frequently to Kubernetes would probably use a private registry, in which case, you need to login to the registry first, by helm registry login before you run helm repo add.

Summary

A Helm chart is a collection of YAML files that describe a related set of Kubernetes resources, such as deployments, services, secrets, configmaps, and ingresses. It packages all the necessary resources for an application into a single unit.

When you install a Helm chart, Helm renders all the YAML manifests in the chart and deploys them to the Kubernetes cluster together. This ensures that all the required resources are created together.

Helm charts use templating to reduce duplication of YAML code. This allows you to define common configurations in one place and reuse them across different environments or applications.

To be continued in part 6, the common Helm chart parameters.