Helm Hook Test


Helm Hook Test

In this tutorial, we are going to discuss about helm hook test. Let’s understand how helm deployment can be tested. As a part of the chart, we can include the test conditions as well as the test script also, and that can be used to do the testing.

I’ll show the demonstration of how to do the testing and we will have quick over view on how the test script will be.

Example

For example, I do have the following deployments.

[email protected]:~$ helm list
NAME                            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
install-upgrade-rollback-demo   default         2               2021-05-30 17:20:05.063549035 +0530 IST deployed        upgrade-rollback-0.2.0  1.16.0     

I can invoke the command helm test and then this particular deployment.

[email protected]:~$ helm test install-upgrade-rollback-demo
NAME: install-upgrade-rollback-demo
LAST DEPLOYED: Mon Jun  7 15:43:43 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE:     install-upgrade-rollback-demo-test-connection
Last Started:   Mon Jun  7 15:44:40 2021
Last Completed: Mon Jun  7 15:44:45 2021
Phase:          Succeeded
NOTES:
1. Get the application URL by running these commands:
   export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=upgrade-rollback,app.kubernetes.io/instance=install-upgrade-rollback-demo" -o jsonpath="{.items[0].metadata.name}")
   export CONTAINER_PORT=$(kubectl get pod --namespace default $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
   echo "Visit http://127.0.0.1:8080 to use your application"
   kubectl --namespace default port-forward $POD_NAME 8080:$CONTAINER_PORT 

That’s going to invoke the testing against this particular deployment, whether it is working properly or not. So it will try to make connection with the running pods and check whether it is able to make a successful connection or not.

So it’s able to make a successful connection and it’s giving a message saying yes the test is succeeded and how this is possible. Again, it is going to be a small pod condition that we will be defining it within the test folder.

Test folder files

Let me get into the chart that we had created. Within templates, there will be a folder called test. So all the test conditions will be available here.

[email protected]:~/upgrade-rollback/templates/tests$ ls
test-connection.yaml

And I need to define what needs to be tested. So whatever the requirements or the templates that we are making that will be having corresponding test conditions.

So all the test conditions that needs to be tested should get included in this particular folder test and within this particular file it’s nothing but it’s just another pod.

[email protected]:~/upgrade-rollback/templates/tests$ cat test-connection.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "upgrade-rollback.fullname" . }}-test-connection"
  labels:
    {{- include "upgrade-rollback.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: wget
      image: busybox
      command: ['wget']
      args: ['{{ include "upgrade-rollback.fullname" . }}:{{ .Values.service.port }}']
  restartPolicy: Never

And I need to have an annotation saying it is a hook. Hook It’s going to get attached to the templates, but it will not get deployed as a manifest into the Kubernetes cluster.

We will be having detailed discussion about what this particular hook is and how it’s going to get used. Here I’ll give a very quick over view. Hook can get invoked in different stages. Say for example before deployment, after deployment, after rendering.

There are different stages where it will get invoked. In this particular case after deployment it will get invoked during the testing it’s going to run this particular container.

So this particular container its going to get an image called busy box and it will do a wget against this particular deployment and the port.

So it will try to ping that particular pod. And if it is available say, that service in the port If it is able to get the message, then it is going to provide a message saying its success or otherwise it’s going to give a failure.

List Pods

In case if I list the pods I can check there is a pod which got started for the test connection and it got over.

[email protected]:~/upgrade-rollback/templates/tests$ kubectl get all
NAME                                                READY   STATUS      RESTARTS   AGE
pod/install-upgrade-rollback-demo-994c4df47-2qvws   1/1     Running     0          30m
pod/install-upgrade-rollback-demo-994c4df47-rpvml   1/1     Running     0          30m
pod/install-upgrade-rollback-demo-994c4df47-bj57q   1/1     Running     0          30m
pod/install-upgrade-rollback-demo-test-connection   0/1     Completed   0          29m
pod/hookweightdemo-hooktest-749686bbfd-smwxq        0/1     Running     0          4s

NAME                                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
service/kubernetes                      ClusterIP   10.152.183.1             443/TCP   17d
service/hookweightdemo-hooktest         ClusterIP   10.152.183.175           80/TCP    3h45m
service/install-upgrade-rollback-demo   ClusterIP   10.152.183.84            80/TCP    30m

NAME                                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/install-upgrade-rollback-demo   3/3     3            3           30m
deployment.apps/hookweightdemo-hooktest         0/1     1            0           3h45m

NAME                                                      DESIRED   CURRENT   READY   AGE
replicaset.apps/install-upgrade-rollback-demo-994c4df47   3         3         3       30m
replicaset.apps/hookweightdemo-hooktest-749686bbfd        1         1         0       3h45m

NAME                                COMPLETIONS   DURATION   AGE
job.batch/preinstalljob-hook-1      1/1           4s         3h46m
job.batch/preinstalljob-hook-2      1/1           5s         3h46m
job.batch/preinstalljob-hook-3      1/1           7s         3h46m

This is how the testing will be achieved. Say for what condition needs to be tested, The corresponding pod will get invoked using some commands and the output of the command will determine whether that particular pods or service is working properly or not.

And mostly it will be testing against the exit condition. A successful exit that is exit 0. The important thing to be consider is that particular annotation saying it is the hook.

And as a part of the hook, we will discuss more about how to write this particular cases, different type of events, when the hook can get triggered. The sample conditions where we can run is whether the user name, password is working properly or not, the environmental variable that we have provided as a part of the helm deployment got injected properly into the required entities like services or pods or not.

Mostly we will be doing the asset of the services whether it is up and running and load balancing it properly or not. These are all some of the test conditions that we can do by using this particular test option. It purely depends on the condition that we are running within the test cases.

Helm Hook Test

Scroll to top