First time at Zeet?

27 Sep
2023
-
10
min read

A Beginner's Guide to Creating Your First Helm Chart

Helm makes Kubernetes a breeze by packaging all the necessary resources into one simple chart. With an easy-to-use CLI and hundreds of pre-built charts, you'll be deploying and managing applications in Kubernetes before you know it.

Jack Dwyer

Product
How To
Content
heading2
heading3
heading4
heading5
heading6
heading7

Share this article

Helm at a Glance

In the vast sea of Kubernetes, Helm Charts act like a seasoned skipper, simplifying application deployment and management. An ingenious tool in your K8s toolkit, Helm Charts are quite simply pre-packaged Kubernetes resources. Think of them as your application's all-in-one packing list. Helm Charts are evolving how we approach Kubernetes and are quickly becoming an essential standard for cloud native app development. So, get ready to take a deep dive and learn how to navigate your Kubernetes journey with ease and efficiency using Helm Charts. 

Helm may seem confusing at first with its Charts, releases, repositories and more but stick with it. Once Helm clicks, you'll wonder how you ever managed Kubernetes without it. Helm is a must-have tool for any Kubernetes user, whether you're just getting started or managing deployments at scale. Fasten your seatbelts, it's time to helm the K8s ship! 

What Exactly is Helm?

Helm is like a package manager for Kubernetes, allowing you to easily install and upgrade applications on your cluster. If you've ever used apt, yum, or npm, Helm will feel familiar. Helm uses "Charts" which are bundles of Kubernetes YAML files and some handy templates to deploy applications. With a huge library of pre-built Charts and an easy to use CLI, Helm makes wrangling Kubernetes deployments way less painful than doing it manually.

Once you've installed Helm, you can start searching through their Chart repository for whatever application you want to deploy. Need a WordPress blog? There's a Chart for that. MySQL database? Yep, got that too. Helm Charts follow semantic versioning so you can have confidence when upgrading to the latest version of a Chart that it won't completely ruin your deployment. Charts also have hooks for running logic at certain points of the installation like pre-install or post-upgrade.

If you want to get really fancy, you can create your own Charts and share them with your team or the community. Just bundle up your Kubernetes YAML files, add a Chart.yaml for metadata and a values.yaml for configuration, and you've got yourself a Helm Chart! You can then version, test, and publish your Chart to a repository.

Helm may seem confusing at first with its Charts, releases, repositories and more but stick with it. Once Helm clicks, you'll wonder how you ever managed Kubernetes without it. Helm is a must-have tool for any Kubernetes user, whether you're just getting started or managing deployments at scale.

Installing Helm and Using Your First Chart

To get started with Helm, you'll need to install the Helm CLI on your local machine and also install the Helm Tiller server inside your Kubernetes cluster. The Helm docs have instructions for installing on all major platforms. Once you've got Helm installed, you're ready to start using Charts! If you're deploying with Zeet, we will handle the cluster part for you.

The first thing you'll want to do is add a Chart repository. The most popular one is the stable repo which contains hundreds of pre-built Charts. To add it, run:

$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/

Now you can search through the Charts in the stable repo using:

$ helm search

Let's install a Chart to see Helm in action. For this example, we'll use the mysql Chart to deploy a MySQL database. Run:

$ helm install stable/mysql

Helm will now give you a release name for this Chart installation. By default, it will also install the latest version of the Chart. If you want to install a specific version, use the --version flag.

Helm will now deploy MySQL to your cluster. You can check on the status of the release using:

$ helm status <release name>

To upgrade the Chart to the latest version, use:

$ helm upgrade <release name> stable/mysql

If the upgrade goes poorly for some reason, Helm also has a rollback feature to revert to the previous version:

$ helm rollback <release name>

To uninstall a release and delete the resources, use:

$ helm delete <release name>

And that's the basics of using Helm Charts! I wanted to point out, if you’re a Zeet user, you don’t need to worry about any of these commands. I’ll share more later in this post. Even so, it is always good to know what is happening under the covers so knowing the commands is good knowledge. Helm has a lot more capabilities around managing repositories, creating your own Charts, automation and more but this should get you started with the essentials. Have fun churning out those Helm releases! 

Helm Architecture

Helm has two main components: The Helm CLI and the Tiller server. The Helm CLI is used to create and manage Charts. The Tiller server runs inside your Kubernetes cluster and manages the lifecycle of Kubernetes applications. The Helm CLI talks to Tiller to install, upgrade, query, and remove Kubernetes applications.

Think of the Helm CLI as the client interface and Tiller as the server-side brains of the operation. The CLI is what you'll use to search for Charts, install releases, get info on releases, etc. But behind the scenes, the CLI is communicating with Tiller which then interacts directly with the Kubernetes API server to deploy applications.

Tiller has permissions to deploy to Kubernetes, not the CLI. So the CLI never touches your cluster directly. This architecture allows you to keep the CLI on your local machine while the Tiller server runs in your cluster. The CLI and Tiller communicate using gRPC.

When you run a Helm install, the CLI will send the Chart information to Tiller which will then read the Chart and deploy the Kubernetes resources defined in the templates. Tiller keeps track of all the releases of Charts in your cluster and their current state. So when you want to upgrade or rollback a release, the CLI will tell Tiller to handle that.

The separation of concerns between the CLI and Tiller allows Helm to be flexible in how it's deployed. You could have multiple Tillers for different clusters or environments. The CLI is decoupled so it can talk to any Tiller. The downside is that an extra network hop is required for the CLI to communicate with Tiller. But for most use cases, the benefits of this architecture outweigh any minor performance hits.

Overall, the Helm architecture is pretty clever. The CLI and Tiller work together to simplify your Kubernetes deployments while still keeping concerns separated appropriately. The result is a package manager that's both robust and easy to use.

How to Create Your First Helm Chart

So you've installed Helm, familiarized yourself with some of the built-in Charts, and now you're ready to create your own. Sweet! Crafting Charts is actually pretty straightforward once you get the hang of it. Let's walk through creating a simple Chart to deploy a basic "Hello World" web app.

First, you'll want to scaffold a new Chart with the helm create command:

$ helm create hello-world

This will create a hello-world directory with the standard Chart files:

  • Chart.yaml: Contains metadata about your Chart like name, version, description, etc.
  • values.yaml: Default configuration values for your Chart. You can override these values at install time.
  • templates/: A directory containing templated Kubernetes manifest files. Helm will process these templates with the values from values.yaml to generate the final YAML files for your release.

Next, we'll update the templates with manifests for our app. In templates, create a deployment.yaml, service.yaml and ingress.yaml:

deployment.yaml


apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-world
spec:
replicas: 1
selector:
matchLabels:
app: hello-world
template:
metadata:
labels:
app: hello-world
spec:
containers:
- name: hello-world
image: gcr.io/example/hello-world:1.0.0
ports:
- containerPort: 80

service.yaml


kind: Service
apiVersion: v1
metadata:
name: hello-world
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app: hello-world

ingress.yaml


apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: hello-world
spec:
rules:
- host: hello-world.example.com
http:
paths:
- path: /
backend:
serviceName: hello-world
servicePort: 80

Now when we install this Chart, it will deploy our "Hello World" app with a Deployment, Service and Ingress. Rad! The last step is to bump the version in Chart.yaml, test the Chart, and you're ready to install it!

I hope this quick tutorial helps you craft your first Helm Chart. 

Comparing Helm to Other Kubernetes Configuration Management Tools: Why Helm Comes Out on Top

When it comes to managing Kubernetes, you've got options. Helm is just one in a sea of configuration management and deployment tools for Kubernetes. So why choose Helm over the competition? Here are a few reasons Helm reigns supreme:

Huge Ecosystem

Helm has a huge ecosystem of pre-built Charts. With over 3,000 Charts in their stable repository, there's a good chance Helm already has a Chart for the application you want to deploy. No need to build it yourself! The wider the selection of Charts, the less work for you.

Kubernetes Integration

Helm is tightly integrated with Kubernetes. Helm was created specifically for Kubernetes so it understands the platform inside and out. Other tools were built to be generic configuration managers and just happen to support Kubernetes. With Helm, you get a tool purpose-built for streamlining deployments on Kubernetes.

CNCF Backing

Helm has the backing of the Cloud Native Computing Foundation. Helm is a graduated CNCF project, meaning the CNCF and its members stand behind Helm and support its development. The CNCF is also the home of Kubernetes, so you know their projects work well together!

Enterprise Features

Helm is easy to get started with but scales to enterprise usage. Helm has a simple CLI to get up and running quickly but also has role-based access control, auditing capabilities, and integrations with CI/CD tools for managing Helm at scale. Other tools may be easy to start with but lack the enterprise features.

Large Community

Helm has a large, active community. Helm has over 10,000 stars on GitHub, showing its popularity. It also has over 200 contributors, meaning bugs get fixed and features get added quickly. With an active, engaged community, Helm will continue to improve over time.

Some other options for Kubernetes configuration management include Kustomize, Kapitan, Jsonnet, and Ksonnet. While these tools have their uses, Helm remains the leading package manager for Kubernetes due to its huge ecosystem, tight integration, enterprise-ready features, and active community. For managing Kubernetes deployments, you really can't go wrong with Helm!

Installing and Using Helm CLI with Wordpress

As mentioned earlier, you'll first need to install the Helm CLI on your local machine. You can use a package manager like Homebrew on Mac or Chocolatey on Windows. Once installed, you'll have the `helm` command available to manage your Charts.

Next, you'll want to add a Chart repository so you have some Charts to install. As mentioned earlier in this post, the most popular repo is the `stable` repo which contains hundreds of pre-built Charts. You can add it with:

$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/

Now you can search the repo for Charts using `helm search`. For example, to find a WordPress Chart you'd run:

$ helm search wordpress

When you find a Chart you want to install, use the `helm install` command. For WordPress it would be:

$ helm install wordpress stable/wordpress

This will install the WordPress Chart and release it with the name `wordpress`. You'll get a summary of the installation including any credentials or endpoints you need to access your new deployment.

To upgrade a release to the latest version of the Chart, use `helm upgrade`. For example, to upgrade that WordPress release:

$ helm upgrade wordpress stable/wordpress

If the upgrade doesn't go well for some reason, you can quickly rollback to the previous version with 'helm rollback wordpress'.

To uninstall a release and delete the Kubernetes resources, use `helm delete`:

$ helm delete wordpress

And that covers the basics of installing and managing Helm Charts with Wordpress! While the Helm CLI may seem simple, under the hood a lot is going on. As mentioned, Helm is communicating with the Tiller server in your Kubernetes cluster to actually deploy and manage the resources. But from a user perspective, Helm makes wrangling Kubernetes applications about as easy as it can get.

How Does Chart Versioning Work?

Helm Charts follow semantic versioning, meaning each version number has three digits: MAJOR.MINOR.PATCH. When you make changes to a Chart that are backwards compatible, you bump the PATCH version. Changes that add functionality in a backwards compatible way bump the MINOR version. And changes that break backwards compatibility bump the MAJOR version.

Why does this matter? Well, when you install a Chart, you can specify the version you want to use. Then when a new version is released, you can upgrade to it knowing whether it will be a drop-in upgrade or if it may disrupt your existing deployment. Neat!

Say you install myAwesomeChart version 1.2.3. This is MAJOR version 1, MINOR version 2, and PATCH version 3. I then make a small bug fix and release version 1.2.4. You can upgrade to this new PATCH release knowing it won't change anything major. If I then add a new feature in a backwards compatible way and release 1.3.0, you can upgrade to that MINOR release to get the new functionality.

However, if I then make breaking changes and release 2.0.0, when you upgrade you know you may have to make changes to your configuration or it could disrupt your deployment. The MAJOR version bump signifies breaking changes.

Using semantic versioning allows Chart users to have confidence when upgrading to the latest version of a Chart. You can see at a glance what the scope of changes are for any new release. It's a simple but effective system that Helm has adopted to keep the ecosystem stable. Semantic versioning for the win!

Why Choose Zeet for Helm Chart Management

Managing Helm Charts at scale can be challenging. Keeping track of all your releases across environments, controlling access, auditing changes, and quickly fixing issues requires tooling beyond just the Helm CLI. That's where Zeet comes in.

Zeet provides an easy to use platform for managing Helm Charts in a centralized, controlled fashion. The Zeet dashboard gives you an overview of all your Helm releases so you know the status of deployments at a glance. You get role-based access control to restrict who can install, upgrade or delete releases. An audit log shows who made what changes so you have visibility into how releases were impacted. Zeet also has CI/CD built in to automate your Helm deployments.

The Zeet Helm Chart Blueprint provides a standardized way to define, package, and deploy Kubernetes applications using Helm. Using the Blueprint allows users to create custom charts based on your environments, and define upgrade paths just like you would a normal Helm Chart. You can bring a values.yaml file, and configure it to match your specific deployment needs, such as the number of replicas, the database connection string, or the ingress rules.

Perhaps the biggest benefit of the Zeet platform is support from the team of Kubernetes and Helm experts. If you have any issues with your Helm deployments or need help optimizing your workflows, support is available directly in the Zeet dashboard. For startups and enterprises using Helm to manage mission-critical applications, this type of support is invaluable.

While Helm may be easy to get started with, managing it at scale across teams and environments can be challenging without the proper tooling. Zeet provides an out-of-box-ready solution for Helm that takes away many of the headaches that come with relying on an open-source project for such an important function. 

Custom Helm Configuration

For advanced users who wish to configure their Helm deployments, Zeet offers an easy Helm configuration override. You can just paste in your custom yaml and Zeet will apply it for you on your next workflow.

Zeet Dashboard: adding custom values for override

If your organization is using Helm to manage deployments in production, Zeet is worth evaluating. Zeet can help take your Helm workflows to the next level and give you peace of mind that your Kubernetes applications are deployed across clusters properly. 

What changed in Helm 3 and What's Coming Next?

Helm 3 was released in November 2019 and brought some major changes and improvements. Some of the highlights include:

  • Removal of Tiller - The Tiller server-side component was removed in Helm 3, simplifying the architecture. Now the Helm CLI talks directly to the Kubernetes API server to install Charts. This eliminates the security issues around granting Tiller admin access and the network hops required for the CLI to communicate with Tiller. Overall a much cleaner setup!
  • New Chart Format (v3) - Charts now have a v3 format with some handy new fields and simplifications to the schema. Existing v2 Charts are still compatible but new Charts should use the v3 format.
  • Improved Security - With Tiller gone, RBAC permissions are applied directly to the user/groups running Helm. New --kube-context and --kubeconfig flags can also be used to target specific clusters. Helm 3 also introduces cryptographic verification of Charts to ensure they haven't been tampered with.
  • Plugin Support - Helm 3 now has support for plugins to extend its functionality. The new plugin system uses Go plugins and allows you to add new subcommands, helpers or hooks to Helm. Pretty neat!
  • Lots of Other Improvements - Faster and more consistent templating, better namespace support, the ability to pin dependencies to specific versions, support for storing credentials in external files and more. Helm 3 is a major upgrade!

On the horizon for Helm, we can expect:

  • Continued security improvements - Security is always a top priority for Helm, so more enhancements are on the roadmap like signed Charts and PGP signature verification.
  • ARM support - There is ongoing work to support ARM architectures like ARM64 in addition to AMD64. This will make Helm more accessible to different platforms.
  • Simplified Chart Testing - The Helm team wants to make testing Charts even easier with things like simplified YAML-based testing and support for testing tools like Bats.
  • Improved Documentation - More thorough documentation and guides are always needed as Helm introduces new features and new users adopt the project.
  • Support for Kubernetes 1.19 and Beyond - Helm maintains close compatibility with the latest version of Kubernetes and its releases. Support for future Kubernetes versions will continue.
  • Continued Plugin Expansion - The new plugin system will allow Helm to be extended in many ways by the community. Expect to see more and more plugins over time that add useful functionality.

Helm 3 was a big step forward for the project, and the future looks bright. With an active community behind it, Helm will continue to be the leading package manager for Kubernetes. The roadmap promises more security, more simplicity, better testing, and a more pluggable architecture.

Examples of Helm in the Real World

Helm is used by many major companies to deploy applications on Kubernetes in production. Here are a few examples of Helm's real-world usage that I was able to find mentioned around the web:

  • Adobe uses Helm to manage releases of their Experience Platform infrastructure across multiple Kubernetes clusters. They have found Helm useful for handling configuring and setting up new deployments as code in a repeatable fashion.
  • Deutsche Bahn, Germany's national railway company, uses Helm to deploy microservices on Kubernetes for their telematics platform. Helm allows them to version control deployment configurations and roll back quickly if needed.
  • Philips Healthcare utilizes Helm to manage AI workloads on Kubernetes across on-premises and cloud environments. Helm gives them a consistent way to deploy applications whether running on bare metal or in the cloud.
  • Kubernetes as a Service providers like Linode, DigitalOcean, and Packet all use Helm internally to deploy their control planes and add-ons. When you launch a Kubernetes cluster with one of these providers, Helm is working behind the scenes!
  • Sony Interactive Entertainment, the company behind the PlayStation, uses Helm as part of their continuous delivery pipeline for game services. Helm allows them to package configurations and deploy to Kubernetes at scale.

These are just a few examples, but they show how Helm is used broadly in production by major companies for managing Kubernetes applications. Whether deploying microservices, data infrastructure, AI workloads or large scale SaaS offerings, Helm provides a consistent and robust way to manage Kubernetes deployments for organizations of all sizes.

While Helm started as an open-source project, it has become an essential tool for enterprises using Kubernetes in production. With its huge ecosystem of Charts, simple but powerful CLI, and enterprise-ready features, it's no wonder Helm has been adopted by companies across industries. Kubernetes and Helm together provide a platform for deploying applications at massive scale.

So don't just think of Helm as a neat open-source project - it is serious software enabling major companies to run their businesses on Kubernetes.

Helm Your Way to Kubernetes Mastery

If you've made it this far, you should now be a Helm Chart expert ready to deploy applications on Kubernetes like a pro! We've covered what Helm is, why you should use it, how to create and manage Charts, how to share them, and examples of Helm in the real world. 

Helm makes Kubernetes deployments as fun as it can be with its simple CLI, huge library of pre-built Charts, and robust enterprise features. Whether you just want to spin up a WordPress blog - as we showed - or are managing thousands of microservices, Helm has you covered.

Now that you're familiar with Helm, you can impress all your friends with your Kubernetes knowledge. But if managing Helm at scale starts to become a headache, you may want to check out Zeet. Zeet offers an easy to use platform for overseeing Helm Charts across environments with access control, auditing, automation, and support. For any serious usage of Helm, Zeet is worth evaluating.

So what are you waiting for? You can get started  and deploy Helm for free with Zeet up to 3 projects. 

Happy shipping! May the Helm be with you.

Subscribe to Changelog newsletter

Jack from the Zeet team shares DevOps & SRE learnings, top articles, and new Zeet features in a twice-a-month newsletter.

Thank you!

Your submission has been processed
Oops! Something went wrong while submitting the form.