Using Helm Charts

Hands-On Lab


Photo of Michael McClaren

Michael McClaren

Linux Training Architect I in Content





In this hands-on lab, we are going to work with a local copy of a chart and modify it so that we can make it work in our environment.

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

Using Helm Charts


In this hands-on lab we will be installing Wordpress. We will be using the stable/wordpress helm chart, but this chart is not compatible with our environment. The chart is currently configured to use a persistent volume, and there is no provider in our environment. So we will need to disable persistence and set the chart to use a NodePort instead of a LoadBalancer, then set the HTTP port to 30080 .
Once this is complete, we'll load the page from the IP address of one of the nodes in the Kubernetes cluster to ensure that it is working.

Finally, with the chart in a working state, delete the release and confirm that there is nothing deployed. With nothing deployed, please complete the lab.

Getting Logged In

On the lab overview page, we'll see three servers: a Kube Master ( we'll call it km), and two Kube Nodes (kn1 and kn2). We can log into any of them using either an SSH client of our own, or by using Linux Academy's built in Instant Terminal program.

Search for, Download, and Decompress a Copy of the Most Recent Wordpress Chart from the stable Repository

On km, issue the command:

[cloud_user@km]$ helm search wordpress

In the output of this command locate the stable/wordpress chart.

Download and decompress a local copy of this chart using the command:

[cloud_user@km]$ helm fetch --untar stable/wordpress

Confirm that you have a directory named wordpress:

[cloud_user@km]$ ls -l

This should show a wordpress directory.

Modify the Chart to Allow It to Run without Persistence, and Set the Service to Run as 'NodePort' with an HTTP port of 30080

Locate the values.yaml file in the wordpress directory and open it in an editor (we're using Vim here):

[cloud_user@km]$ cd ./wordpress
[cloud_user@km]$ ls
[cloud_user@km]$ vim values.yaml

Locate the 2 locations that contain the persistence setting:

  enabled: true

Set these values to:

  enabled: false

There will be one for the MariaDB and one for the Wordpress installation.
Locate the Service definition and set it to:

    type: NodePort
    port: 80
    httpsPort: 443
      http: "30080"
      https: ""

Once this is complete save and quit.

Install the Wordpress Chart and Verify That It Is Working

From the home directory, run the install command for the chart:

[cloud_user@km]$ cd ~
[cloud_user@km]$ helm install ./wordpress

In the output of this command, confirm that the service is set to NodePort.

Once this is done, wait for the pods to become ready using:

[cloud_user@km]$ kubectl get pods

Ignore the busybox line. Run this command every so often until we get 1/1 as a READY status. When they are ready, copy the public IP address of kn1. Open a browser and navigate to:


Confirm that the wordpress application is up and running.

Clean up the Kubernetes Cluster and Ensure That There Are No Artifacts

Get the release name for the Wordpress release:

[cloud_user@km]$ helm ls --short

Remove the helm release:

[cloud_user@km]$ helm delete <RELEASE_NAME>

Confirm that there are no deployed resources. None of these commands (except for get pods, but we're ignoring busybox anyway, remember?) should return information:

[cloud_user@km]$ helm ls
[cloud_user@km]$ kubectl get pods
[cloud_user@km]$ kubectl get pv
[cloud_user@km]$ kubectl get pvc


We downloaded a Helm chart, modified it, deployed from a local copy of the chart, verified that it was running, and then cleaned it all up. That's what we set out to do. Congratulations!