Part 13: Taming the YAML Beast: Getting Started with Helm

Throughout this series, we've built a single application. To do so, we've had to create and manage a growing number of YAML files:

• A Deployment
• A Service
• A ConfigMap
• A Secret
• A PersistentVolumeClaim
• An Ingress

This is for just one simple service. A real-world microservices architecture might have dozens of services, each with its own set of manifests. This is often called "YAML sprawl," and managing it is a significant challenge.

How do you install an application with all its related resources in one step? How do you manage its configuration for different environments (dev, staging, prod) without duplicating files? How do you share your application so that others can easily deploy it?

The answer to these questions is Helm.

What is Helm?

Helm is the de-facto package manager for Kubernetes. If you've ever used apt on Debian, yum on CentOS, or Homebrew on macOS, the concept is the same. Helm allows you to package all your related Kubernetes resources into a single, cohesive unit called a Chart.

• Analogy: If your Kubernetes YAML files are individual ingredients (flour, sugar, eggs), Helm is the complete recipe that tells you how to combine them to bake a cake. Even better, it's a recipe with customizable options (e.g., "Amount of chocolate chips: [your choice]").

Core Helm Concepts

1. Chart: A Helm Chart is a collection of files that describe a related set of Kubernetes resources. It's a folder with a specific structure, containing your YAML templates and default configuration values.
2. Release: A Release is a specific instance of a Chart that has been deployed to the cluster. If you have one Prometheus chart, you could deploy it twice: once as a release named prometheus-dev and again as prometheus-prod, each with different configurations.
3. Repository: A Helm Repository is a place where Charts can be stored and shared. It's like the Homebrew Taps or the Debian APT repository.

Installing Helm

First, let's install the Helm CLI on our local machine.

(Please follow the instructions for your Operating System)

macOS (using Homebrew):

brew install helm

Windows (using Chocolatey):

choco install kubernetes-helm

Linux (using a script):

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

Verify the installation with helm version.

Using a Public Chart

The easiest way to see the power of Helm is to install a complex application from a public repository. Let's install Prometheus, a powerful monitoring system that would normally require dozens of YAML files.

1. Add the Repository: First, we tell Helm about the repository where the chart lives.
   

   helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
   helm repo update
   

2. Install the Chart: Now, we can install the Prometheus chart, creating a new release named my-prometheus.
   

   helm install my-prometheus prometheus-community/prometheus
   

That's it! With one command, Helm has deployed multiple Deployments, Services, ConfigMaps, and other resources required to run a complete Prometheus stack. You can see all the Kubernetes objects that were created by this release:

helm get manifest my-prometheus

And you can see the running Pods:

kubectl get pods

You'll see pods for prometheus-server, prometheus-alertmanager, and prometheus-node-exporter. To clean everything up, just uninstall the release:

helm uninstall my-prometheus

Creating Your First Chart

Now, let's create our own chart for the hello-nginx application we've been building.

1. Create the Chart Structure: Helm provides a handy command to scaffold a new chart.
   

   helm create nginx-chart
   

   This creates a folder named nginx-chart with several subdirectories and files. The most important one is templates/, which is where our Kubernetes YAML files will live.

2. Clean up the default templates: The scaffold creates some example files. Let's delete them so we can start fresh.
   

   rm -rf nginx-chart/templates/*
   

3. Add Our Templates: Now, copy the deployment.yaml and service.yaml we created in previous parts into the nginx-chart/templates/ directory.

4. Install Our Local Chart: We can now install our application using Helm. Navigate to the directory containing your nginx-chart folder and run:
   

   # The dot '.' refers to the chart in the current directory
   helm install my-nginx ./nginx-chart
   

You should see your Nginx deployment and service running! Check with kubectl get deployments and kubectl get services.

This is just the beginning. The real power of Helm comes from templating. If you open the values.yaml file in the chart, you can define variables (like replicaCount: 1). Then, in your deployment.yaml, you can replace replicas: 1 with replicas: {{ .Values.replicaCount }}. This allows you to create flexible, configurable charts that can be reused for any environment, but that's a topic for a more advanced session.

What's Next

We have now tamed the beast of YAML sprawl. With Helm, we can package, distribute, and manage even the most complex applications in a simple, repeatable way.

We've covered the entire lifecycle of a Kubernetes application from the inside out. But how does our code get from a Git repository into a running container in our cluster? The final piece of the puzzle is understanding the workflow that connects our development process to our Kubernetes deployment.

In the next part, we will explore the concepts of CI/CD (Continuous Integration/Continuous Deployment) and GitOps, the modern automated workflows for building and releasing software on Kubernetes.