If Kubernetes is the pilot that steers the ship, then Helm Charts are the navigational maps that guide the journey correctly. We have seen this happening over the years in the world of software development, one tool comes with an idea, serves the purpose, and becomes obsolete in some years, and then one more tool gets introduced that replaces the old approach, and this journey continues. Similarly, today is the era where Kubernetes is looked upon as the king of container orchestration. Backed by Google, Kubernetes has grown leaps and bounds by increasing its reach and community to every part of the world.
But, as we all know, with high power and popularity, Kubernetes comes with some complexity. To mitigate this complexity that Kubernetes poses, we have Helm. What is Helm? How does it work with Kubernetes? We will discuss all this further in the article.
What is Kubernetes & how it works?
Think, for example, you are building an application using containers, you go ahead and deploy the application, the application becomes too popular and to keep up with the increased popularity, you need to scale the resources and now, instead of a few containers, you have to deal with hundreds of containers. That becomes a mess, you need a simple way to automate the process, and this is where Kubernetes comes to the rescue.
Why is Kubernetes so powerful?
- Horizontal scaling
- Load balancing and service discovery
- Automated rollouts and rollbacks
- Storage orchestration
- Batch execution
- Configuration management
What is Helm & how it works?
The helm CLI is what you execute and run in your local command-line environment. It uses a templating engine to generate Kubernetes YAML from some source templates that you set up in Helm. Once the YAML has been generated, it then sends those requests to the Tiller that’s running on your Kubernetes cluster. Tiller then executes updates inside your Kubernetes cluster to make sure it is up to date with what you needed based on the chart, and the tiller will make sure that gets released and will be added to the helm history so that you can rollback to it in the future.
Chart: Packaged Kubernetes (k8s) resources (metadata)
Values: Parametrize and support multiple environments
Chart Repository: Registry of consumable charts, enables to share and reuse configurations
Release: A deployed instance of a chart
Templates: Templates are Kubernetes manifest files that describe the resources you want to have on the cluster. They help us control operations during deployment. To deploy your applications using helm, you need to package your applications into a chart (directory with some files in a specific structure)
The top-level directory is the name of your chart and, below that, you have chart.yaml, which stores metadata and version information for your chart. There is values.yaml to store default configuration values. requirements.yaml lets you specify dependencies like MongoDB or Postgres, and then there is Charts subdirectory where dependencies and packages are stored. Finally, there is templates directory, this is where we store source templates that are fed into the helm templating engine. Let’s not get into the technical details so we can stick to our topic.
Helm and Kubernetes to help you deploy with ease
The software firms are moving away from a monolithic architectural pattern to the microservices pattern, where simple software units work individually to perform a specific function. Different pieces are loosely copulated and are made to communicate with each other without breaking anything. Adopting to microservices boosts knowledge across different teams to work on a single piece of application with full responsibility.
The microservices are essential; they create ease to manage, update, and scale-up applications individually, unlike monolithic applications. Helm is a game-changer here, it has altered the way developers define, store, and manage the server-side applications. Helm, the package manager, simplifies the management of applications, and the implementation of microservices. Helm wraps the microservices and all the dependencies together.
Helm with Kubernetes is the most popular choice for managing containers on the cloud. The automatic deployment, ease of use, stability, and portability are Kubernetes key features. It includes multiple storage APIs, health check of container, systematic upgrades, and manual or automatic scaling.
Kubernetes solves a lot of problems,
- Makes sure all your containers are up and running
- Helps in service discovery
- Resource isolation and utilization efficiencies
- Prevent’s vendor lock-in problems
- Since everything is declarative in YALM, Devs can do Ops as well
- Kubernetes has big support from the community to help you solve your tech problems
Kubernetes is powerful but…..it comes with its own complex problems.
Kubernetes can be highly overwhelming and might become complex with all the objects that you need to handle – objects, config maps, services, pods, persistent volumes, and the list goes on. All this becomes too complex when you multiply all these objects with the number of releases that you need to manage. How do you manage all these complex activities? There comes Helm to the rescue.
Helm helps you package all of that complexity into one simple application and what you can configure.
Functions of Helm:
- Install software
- Automatically install software dependencies
- Upgrade software
- Configure software deployment
- Fetch packages from repositories
Let’s look this example, Buffer chose Helm for its deployments
For more than six years, Buffer, a social media management platform, had a monolithic architecture. In 2016, they decided to move to service-oriented architecture. They started using Docker for their development environments, and they needed a solution that can work well with containers. After assessing several tools in the market like Mesosphere and Amazon ECS, the Buffer crew settled on Kubernetes. They liked Kubernetes because of the problems that it solves with containers, by its relative maturity, large community, and cloud-provider-agnosticism.
The Buffer engineering team began the migration process by rebuilding a piece of the monolith’s functionality into its own, self-contained service. The project intended to set a remarkable example for other microservices at Buffer moving forward. After the success of this project, they looked towards breaking out different pieces of the monolith & making them separate microservices units.
After going through several alternatives, the team decided to use Kubernetes as a layer of abstraction that separates data scientists from the low-level infrastructure problems. Kubernetes started smoothly handling the fluctuating amount of resources. Along with Kubernetes, the team started embracing Helm templates to reduce the time needed to run new machines and start an experiment.
No doubt, Kubernetes has become a go-to solution for managing and running your application in Docker containers. Like we discussed in the article, with high power & popularity comes greater complexity. The Kubernetes YAML files & working with Kubernetes as a whole can be a bit hard. Helm is a tool that manages these deployments for you. It makes it easy to do versioning and templating of Kubernetes file. It allows you to define dependencies between deployable components to make the deployments and releases smooth as silk.
Rimas, in his own words, these are the changes and enhancements in the Helm v3 beta features,
- Tiller has been removed.
- Release information is now stored in the Namespace.
- helm init command has been removed.
- The Helm home directory has been located off user’s home directory.
- The stable repository is no longer added by default.
Source credits: Rimusz Blog (I have taken Rimas Mocevicius’s permission to talk about it here)
Removal of Tiller has been the most significant part in the Helm v3 and for the people who hated it and it has become a part of the history.
Migration from v2 to v3
Helm helps to optimize Kubernetes deployments with ease. Helm has become a popular tool in the Kubernetes ecosystem, gives all developers a way of building packages (known as charts) of related Kubernetes objects that can be deployed in a cohesive way to a cluster. It also enables parameterizing these packages, so they can be reused in different contexts and deployed to the different environments that the services they provide might be needed in.