X
  • September 12, 2018

Take the Helm: Kubernetes Package Management

Mickey Boxell
Product Management

Overview

As with any new technology, there is a learning curve when it comes to implementing Kubernetes. Companies adopting the container orchestration tool can be hampered by the increased complexity of deploying Microservice environments. Companies often start by manually deploying their applications through the use of kubectl. In doing so, Kubernetes treats your application as a number of decoupled resources and requires you to individually deploy each component. To repeat deployments you will have to keep track of the step by step process used for the application and manage releases for each component. Each additional resource will likely require another command to run. As the complexity of the environment increases, this approach becomes not only exhausting, but also prone to human error. Imagine having to share this process with another group or with an end user and expecting them to follow through without making a typo or forgetting a single command along the way.

What if you prefer to treat your application as a whole: a collection of parts neatly wrapped up and managed as a package? You can decrease the time spent deploying development and testing environments and instead spend that time on application development. Simplifying the deployment process might also shorten the learning curve and lead to the faster adoption of Kubernetes within your organization. The process becomes easier to share and to follow. Removing human error and creating a templated deployment process might help you overcomethe final jitters preventing you from moving your deployment to production. Helm offers a solution.

Solution

In a nautical setting, a helm is a wheel used to steer a ship. In the world of containers, the open source tool Helm has a similar purpose: it is used to steer or manage Kubernetes applications. Helm is a package management tool for Kubernetes and, just like Kubernetes, Helm is a CNCF project. The simplest way to think of Helm is as a package manager similar to yum, brew, apt-get, choco, etc., but specifically for Kubernetes. Helm addresses the challenges above by providing a method for repeatable application installation, configuration, and versioning through the use of charts, repositories, and releases.

  • Chart: a package of pre-configured Kubernetes resources defined by a YAML file used to describe the components of applications designed to run in a Kubernetes cluster and searchable metadata.

  • Repository: a searchable collection of Helm Charts.

  • Release: an instance of a Helm Chart deployed to a Kubernetes cluster. There is a new release created each time a chart is installed.

Thanks to repositories and releases, Charts are easy to update, version, and share. By packaging up the various resources involved in our configuration, Helm enables us to treat our application as a whole rather than a series of resources individually deployed on a cluster. With Helm, user configurations become reusable.

There are two key parts of the Helm architecture:

  • Helm: a client running on your local system.

  • Tiller: a server in your Kubernetes cluster that interacts with the Kubernetes API server used to manage your Helm deployments

It is worth noting that Tiller is expected to be deprecated with the release of Helm 3 as the client/server separation is removed.

Architecture

Installation

To run Helm you need access to a Kubernetes cluster. For help creating a Kubernetes cluster with Oracle Cluster Engine for Kubernetes (OKE) follow this guide. If you choose to use OKE for your Kubernetes environment you can simplify the Helm set up process by clicking the box that says "Tiller (Helm) Enabled" when provisioning an OKE cluster.

One advantage of using Helm is being able to find and access an existing repository of stable Charts containing popular software packages. I recommend starting out by running a helm search command to see the list of Charts. Run helm inspect followed by the Chart name to find more information about a particular Chart. When you have chosen a Chart to deploy, run helm install followed by the chart name. The Helm client will send a request to Tiller to install the Chart in your Kubernetes cluster. This process will create a release name for your application.

One of my favorite parts of Helm is the simplified deletion or cleanup process. Once again, thanks to Helm's ability to treat our group of resources as a single application, we can run a single command to remove everything associated with our application rather than having to run individual kubectl commands to clean up each resource. After verifying the application was successfully deployed, you can clean up the environment with helm delete followed by the release name.

After you get more comfortable with Helm you can begin to use it to define custom Charts and create your own Chart repository. Helm can also be tied to a CI/CD system and used to configure releases. Helm can be also be useful to productionize your application by reducing complexity and increasing the repeatability of deployments.

Conclusion

If you are a developer just starting to use Kubernetes or an advanced user wanting to streamline your application deployment process, Helm is a good fit for you. With Helm installed, you have the ability to efficiently manage packages of Kubernetes resources, access and share a repository of Charts, and control the version history and upgrades of your releases. Check out this guide for more information about how to configure and use Helm in your environment. For additional information about using Helm, check out the Official Helm Project.

 
 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.