Bob's Journey into Helm: Charting a New Course

Bob, now well-versed in Kubernetes security and observability, turns his attention to a new challenge: streamlining his deployments.

"I've learned a lot about securing and monitoring my applications," he muses, "but deploying them still feels a bit manual. I wish there were a way to simplify and automate the process."

Josie, sensing his desire for efficiency, approaches with a knowing smile. "Ready to take your Kubernetes skills to the next level, Bob?" she asks. "Let's explore the world of Helm, the Kubernetes package manager."

Bob's eyes light up. "Helm? That sounds like what I need!"

What is Helm?

Josie explains that Helm is like the 'apt' or 'yum' of the Kubernetes world. It simplifies the process of deploying and managing applications by packaging them into charts.

"Think of Helm charts as blueprints for your Kubernetes applications," she says. "They contain all the necessary configurations and resources to deploy your application in a repeatable and consistent manner."

Helm Charts

Bob learns that Helm charts are collections of YAML files and templates that describe a set of Kubernetes resources. They can be versioned, shared, and reused, making it easier to manage complex deployments.

"Helm charts are like building blocks for your Kubernetes deployments," Josie explains. "They allow you to assemble and deploy applications with ease."

Benefits of Using Helm

Bob leans back, considering what Josie just said, "This seems pretty handy, but what exactly are the advantages of using Helm?" he wonders aloud.

Josie nods. "Great question, Bob! Helm brings a lot to the table. For starters, it simplifies deployments significantly. No more juggling dozens of YAML files - everything gets neatly packaged into a single chart."

"So, less room for errors?" Bob asks, recalling a few instances where mismatched YAML files caused deployment headaches.

"Exactly!" Josie confirms. "And it's not just about simplicity. Helm charts are reusable. You create a chart once and deploy it across different environments - development, staging, production - with ease."

Bob's eyes widen. "That would be a huge time saver! No more tweaking configurations for each environment?"

"Precisely," Josie replies. "And because Helm charts are versioned, you can easily roll back to a previous version if something goes wrong. It's like having a safety net for your deployments."

"That takes care of my worries about updates," Bob says, relieved. "Is there anything else Helm can do?"

"Helm has a vibrant community," Josie continues. "You can find pre-built charts for tons of popular applications, and there's always someone to turn to for help. It's like joining a club of Kubernetes enthusiasts."

"Wow," Bob says, impressed. "Helm sounds like it can really streamline my Kubernetes workflow."

"Absolutely," Josie agrees. "With Helm, you can say goodbye to manual deployments and hello to automation and efficiency."

Helm Repositories

"Okay", says Bob, "but what are these repositories? Similar concept to my git repositories?"

"Pretty much yeah", Josie says, "Helm repositories are essentially app stores for your Kubernetes cluster," she says. "You can find pre-built charts for popular applications or share your own charts with others. But to start with, lets understand what a chart really is..."

Josie quickly brings up a console and creates an example chart and shows Bob a typical Helm chart structure:

$ helm create my-helm-chart
Creating my-helm-chart

$ tree my-helm-chart
my-helm-chart
├── charts
├── Chart.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── serviceaccount.yaml
│   ├── service.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

4 directories, 10 files

"There are 4 main parts to this structure:" she says,

1. "charts directory holds any dependencies your chart has"
2. "templates are where your Kubernetes resources live, basically all the things we built the other day to run your app in the dev cluster"
3. "Chart.yaml is the main metadata file for the helm chart that describe what/who/how it works and this is where the dependencies are typically defined"
4. "values.yaml holds the default configuration for your chart which can be overridden during the deployment"

With this info, Bob starts thinking about what his chart might look like and what dependencies he might have.

Building on the Shoulders of Giants

Josie explains that one of the great things about Helm is the ability to leverage existing charts and customise them.

"Imagine you want to deploy a popular database like MySQL," she says. "Instead of creating a chart from scratch, you can use a pre-built chart from a trusted repository such as the Bitnami repository and tailor it to your specific needs."

This concept excites Bob. He sees how he can save time and effort by building on top of industry-standard charts instead of reinventing the wheel.

"Helm repositories are like app stores for your Kubernetes cluster," she says. "You can find pre-built charts for popular applications or share your own charts with others."

Helm in Action

"Let's take a look at how easy it is to deploy something with these helm repos by spinning up a basic nginx hello world app", bringing up a console she types:

$ helm repo add bitnami https://charts.bitnami.com/bitnami

Explaining, "For now we'll leverage the bitnami repo and find their nginx chart"

$ helm search repo bitnami/nginx
NAME                                    CHART VERSION   APP VERSION     DESCRIPTION
bitnami/nginx                           18.2.5          1.27.2          NGINX Open Source is a web server that can be a...
bitnami/nginx-ingress-controller        11.5.4          1.11.3          NGINX Ingress Controller is an Ingress controll...
bitnami/nginx-intel                     2.1.15          0.4.9           DEPRECATED NGINX Open Source for Intel is a lig...

"From this, we get a few options but the one we want is the first one... we can install this with:"

$ helm install my-nginx bitnami/nginx
NAME: my-nginx
LAST DEPLOYED: Mon Nov 25 06:23:59 2024
NAMESPACE: bobsjourney
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CHART NAME: nginx
CHART VERSION: 18.2.5
APP VERSION: 1.27.2

** Please be patient while the chart is being deployed **
NGINX can be accessed through the following DNS name from within your cluster:

    my-nginx.bobsjourney.svc.cluster.local (port 80)

To access NGINX from outside the cluster, follow the steps below:

1. Get the NGINX URL by running these commands:

  NOTE: It may take a few minutes for the LoadBalancer IP to be available.
        Watch the status with: 'kubectl get svc --namespace bobsjourney -w my-nginx'

    export SERVICE_PORT=$(kubectl get --namespace bobsjourney -o jsonpath="{.spec.ports[0].port}" services my-nginx)
    export SERVICE_IP=$(kubectl get svc --namespace bobsjourney my-nginx -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    echo "http://${SERVICE_IP}:${SERVICE_PORT}"

WARNING: There are "resources" sections in the chart not set. Using "resourcesPreset" is not recommended for production. For production installations, please set the following values according to your workload needs:
  - cloneStaticSiteFromGit.gitSync.resources
  - resources
+info https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

"And that's it!" Josie exclaims. "Your Nginx server is now deployed." Pointing at the output, she explains "So we get a bunch of information from the Chart that tells us the name, when it was last deployed if this was an upgrade and a bunch of other meta data relating to the chart. The information below that is useful info the chart maintainer thinks you might need"

Bob is amazed by the simplicity and power of Helm. He asks "Super simple then, but what has that done to our namespace?"

"Let's see...", Josie responds as she types out:

$ kubectl get pods,ingress,secrets,cm,svc
NAME                            READY   STATUS    RESTARTS   AGE
pod/my-nginx-5c5687475c-xjjgh   1/1     Running   0          53s

NAME                                    TYPE                             DATA   AGE
secret/imagecredentials-secret          kubernetes.io/dockerconfigjson   1      67s
secret/my-nginx-tls                     kubernetes.io/tls                3      54s
secret/sh.helm.release.v1.my-nginx.v1   helm.sh/release.v1               1      54s

NAME                         DATA   AGE
configmap/kube-root-ca.crt   1      74s

NAME               TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                      AGE
service/my-nginx   LoadBalancer   10.100.66.135   192.168.0.181   80:30338/TCP,443:30631/TCP   54s

Pointing at the screen, Josie runs through the different items, "So, we've got a single pod running which is out nginx app, a few secrets, a configmap and a service that exposes nginx on ports 80 and 443."

Bob notices, "Ah, but there's no ingress, so it's currently not accessible outside of the cluster."

Josie smiles, "That's right, and this is where the values.yaml file comes into play. It allows you to override configurations easily. When we build your To-Do List application chart, we'll explore how to add an ingress to make it accessible externally."

Grabbing her notepad, she sketches out the following flow saying "To give you a better idea of what happens under the hood when you use Helm, here’s a visual representation of the Helm deployment flow, it explains how Helm manages resource creation but also contextualises the namespace changes we observed earlier:"

"Understanding this process will help you grasp how Helm simplifies deployments and automates resource creation. This flow highlights how Helm handles the heavy lifting, so you can focus on configuring and managing your applications with ease", Josie concludes, "We'll build on this understanding when we dive into creating Bob's To-Do List application from scratch."

Opening up a browser, Josie goes to 🔗https://github.com/bitnami/charts and navigates to the nginx helm chart and show's Bob the readme, "These are all of the values that you can override, either by providing a values file or by setting command line options when running the helm install command"

Helm Templates

After spending the next 15 mins or so discussing the various options and how they might configure the nginx deployment based on the huge number of items in the README.md at which point Bob asks, "So, the values.yaml file plays a really important role in defining the out-of-box experience for apps deployed through a Helm chart. How do these values make it into the Kubernetes resources?"

Josie responds, "With Helm templates, we can leverage things like conditionals, variables, and loops to dynamically generate resources based on the values defined in the chart. For example, in the templates/deployment.yaml file, you can use 'if' and 'else' statements, include common elements from _helpers.tpl, and reference .Values to make your configurations flexible and reusable."

Bob nods, "Yeah, okay, it looks pretty complex, to be honest."

Chuckling, Josie reassures him, "These are advanced charts designed for every possible configuration. When we start building your chart, we'll keep it simple and add complexity as needed over time."

"That sounds like a sensible approach and gives me time to learn a new templating language," Bob says, feeling more confident.

Wrapping Up

Bob, now introduced to the world of Helm, feels a sense of excitement. He sees the potential for streamlining deployments and building upon existing charts to accelerate his workflows. "This is incredible, Josie! I can't wait to start using Helm for my own applications."

Josie smiles, "It's a powerful tool, Bob, and you're just scratching the surface of what it can do."

"So, what's next?" Bob asks eagerly. "Can we try building a Helm chart for my To-Do List application?"

"Absolutely!" Josie replies. "In our next session, we'll dive deeper and create a custom chart for your app from scratch."

Bob’s eyes light up with anticipation. "I’m ready for it!"