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?
Kubernetes is an open-source container orchestration tool that is backed by Google and is becoming too popular in the software industry because of the benefits that it provides.
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.
Image credits: Knoldus .Inc
In Kubernetes, there is a master node and multiple worker nodes, each worker node can handle multiple pods. Pods are just a bunch of containers clustered together as a working unit. You can start designing your applications using pods. Once your pods are ready, you can specify pod definitions to the master node, and how many you want to deploy. From this point, Kubernetes is in control. It takes the pods and deploys them to the worker nods. If a worker node goes down, Kubernetes starts new pods on a functioning worker node. This makes the process of managing the containers easy and simple. It makes it easy to build and add more features and improving the application to attain greater customer satisfaction. Know more in this video in detail: What is Kubernetes
Kubernetes was originally designed by Google and then it was later donated to the Cloud Native Computing Foundation (CNCF).
Why is Kubernetes so powerful?
- Horizontal scaling
- Self-healing
- Load balancing and service discovery
- Automated rollouts and rollbacks
- Storage orchestration
- Batch execution
- Configuration management
What is Helm & how it works?
Helm is a tool for Kubernetes that helps you install and manage applications. In terms of architecture, Helm has two sides, there is a client-side, which is the Helm command-line tool (helm CLI), and there is also a service side, which is called Tiller.
Image credits: On Slideshare by Codefresh
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.
Helm terminologies:
Image credits: DigitalOcean
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
Helm makes it easy to start using Kubernetes with real applications. Kubernetes + Helm duo has become the basic toolset for any DevOps specialist. This guide about Helm charts best practices offers some best practices to structure and specify your Helm charts that will help K8s deliver your container applications smoothly. Helm provides several CI/CD pipeline integration hooks, we can configure actions to occur; for example, before installation begins, or after an upgrade has finished. You can even set health checks for Helm to run and verify a deployment has completed successfully.
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.
Two years later, Buffer is running three k8s clusters with over 140 services. They faced several challenges with Kubernetes deployments along the way, but then they're solving by them moving onto Helm package manager that allows developers to define Charts to describe k8s configuration making deployments easy.
[Source credits for above Buffer's story: Stackshare]
One more good example is Neptune, a cloud-native data science lab, had a challenge handling infrastructure as most of the folks were data scientists or mathematicians, they wanted to make these folks work painlessly.
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.
[Source credits for above Neptune's story: CodiLime]
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 Mocevicius, one of the co-founders of Helm recently wrote an article in which he talks about the Helm v3 Beta Features and some major changes introduced in Helm v3.
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.
The helm search command has been refactored to have sub-commands that can search the local repositories and the Helm Hub.
Source credits: Rimusz Blog (I have taken Rimas Mocevicius’s permission to talk about it here)
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
This official guide from Helm website should help you see how to migrate Helm v2 to v3 with use cases - when you have Helm v2 and v3 managing the same cluster, this case is when you want to move out of Helm v2 gradually and do not require v3 to manage any releases deployed by v2. In other case, migrating Helm v2 to Helm v3 where you want Helm v3 to manage existing Helm v2 releases. If you have any questions related to migration from v2 to v3, take a look at the official Helm FAQ page.
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.