Guest post originally published on the Nirmata blog by Spruha Pandya
The adoption of microservices architecture has revolutionized the way applications are developed today. As the microservices architecture replaced the monolithic architecture, containers replaced VMs. However, with this transformation, application deployment was no longer an easy task. Container orchestration was a new challenge, which was solved by Kubernetes. Just like any new technology, containers and Kubernetes brought in new complexities with them.
Among all the challenges, deployment and management of applications on Kubernetes has proved to be the most difficult one for IT teams. But, due to the runaway success of Kubernetes, there is a growing ecosystem of tools focussed on addressing the complexities of application deployment. The majority of these tools exist as open-source projects maintained by the developer community. Helm is one such open-source project that has been successfully simplifying the lives of Kubernetes users since 2016.
Helm is a result of the combined efforts of Deis (a container tooling company, now part of Microsoft) and Google. It was a part of the Kubernetes 1.4 release in 2016. Helm helps IT teams manage Kubernetes applications through Helm Charts. These charts can enable teams to define, install, and upgrade even the most complex Kubernetes applications.
What makes Helm so popular?
While the problem of managing applications on Kubernetes can be complex, Helm itself is quite simple to use. Here is a typical view of how deployments happen without helm and how Helm simplifies them.
Without Helm:
Teams rely on Kubernetes YAML files to configure Kubernetes workload. These YAML files specify everything needed for deploying containers. Everything from the way each Pod needs to be configured to how load balancing is done by the Kubernetes cluster, has to be mentioned in those YAML files. Thus, to set up a new Kubernetes workload, you need to create a YAML file for that workload. To do it manually means writing multiple YAML files – one for each workload you create.
With Helm:
Instead of having to write separate YAML files for each application manually, you can simply create a Helm chart and let Helm deploy the application to the cluster for you. Helm charts contain templates for various Kubernetes resources that combine to form an application. A Helm chart can be customized when deploying it on different Kubernetes clusters. Helm charts can be created in such a way that environment or deployment-specific configurations can be extracted out to a separate file so that these values can be specified when the Helm chart is deployed. For example, you need not have separate charts for deploying an application in development, staging, and production environments.
Helm has evolved with time and with each new upgrade, it has made application management on Kubernetes simpler. With the recent release of Helm 3, the benefits have surpassed expectations of the DevOps community and it has been happily added to the list of must-have tools for deploying applications to Kubernetes.
Helm 3 – Adiós Tiller
When Helm 2 was launched, Kubernetes did not have Role-Based Access Control (RBAC). Helm included a component called Tiller which was responsible for deploying the chart. But, with newer versions of Kubernetes, RBAC is enabled by default and Tiller allows users to bypass access control. So, in Helm 3, the Tiller was removed – finally eliminating the security weak-link of Helm, making it more reliable and stable.
Benefits of Helm:
- Helm Charts provide the ability to leverage Kubernetes packages through the click of a button or single CLI command. You can also include Helm charts within other Helm charts and have various dependencies.
- Helm charts are built atop Kubernetes. These charts complement the cluster architecture of Kubernetes. While using Helm for deploying applications to Kubernetes, scalability is a default benefit from the very start as all the charts of the container images used by Helm are stored in a registry called Helm Workspace, which the DevOps teams can look up and add to their projects with ease.
- Another distinguishing feature Helm offers is the ability to customize application configurations during deployment. The DevOps team can provide configurations for all the Kubernetes resources included in the application as well as configure all the environment-specific requirements for those resources. This enables teams to reuse one Helm chart across multiple environments.
- It is obvious that Helm is a must-have for Kubernetes deployments. But the real benefits lay in the role it plays in streamlining your CI/CD pipelines.
- Helm automatically maintains a database of all the versions of your releases. So, whenever something goes wrong during deployment, rolling back to the previous version is just one command away.
- There are several CI/CD integration hooks available in Helm that enable teams to automate certain actions to take place by default, just like macros in Microsoft office, for example, before installation begins, or after an upgrade has finished. You can even schedule health checks for Helm to verify if a deployment has been completed successfully.
Even with all these benefits, Helm 3 isn’t all rainbows and sunshine…
- Troubleshooting and Debugging
The biggest challenge for Helm is complexity. The whole system is based on templating Helm charts which makes it very difficult to create and debug complex applications that may consist of multiple Kubernetes resources. The more Helm charts there are, the more complex the entire system is. Imagine how much time it would take for a team to spot and resolve a bug in a Helm chart template that has been used numerous times across many Kubernetes resources in a complex application. - Learning curve
Helm simplifies the management of Kubernetes clusters. But, creating the first Helm chart is definitely not as simple as typing out a few commands. The process is rather complex and involves a steep learning curve that might take some time for the DevOps teams to get used to. Helm tries to simplify this as much as possible through its extensive documentation about how to get things done.
Helm Alternatives
When it comes to CI/CD with Kubernetes, it is challenging for a tool to address all scenarios well. Helm tries to simplify application deployment but has some limitations. There are several alternatives to Helm available that you might want to explore if Helm does not meet your needs.
Out of all the Helm alternatives out there, Kustomize is the most popular. Kustomize is a template-free way to customize application configurations and manage Kubernetes workloads. There are several instances in which templating using Helm could be complicated. This is when Kustomize can come to your rescue. Developers tend to use both, Helm and Kustomize depending on their requirements. When it comes to the question of which one is better out of the two, the jury is still out there.
Final Takeaway
Additionally, there is one more thing to keep in mind while starting off with container deployment – do not lose sight of the big picture. DevOps users need the flexibility to choose the right tool based on their requirements. But it is also important to ensure that you are aware of the limitations of these tools so that your project is not stalled or delayed. Helm is definitely a popular tool when it comes to packaging your applications and it is also the most widely supported by container management platforms such as Nirmata.
Kubernetes offers many advantages to Day 0 and 1 stages of the application lifecycle. However, most organizations have found it lacks critical Day 2 capabilities like reliability, security, and risk management. Download the Day 2 Kubernetes whitepaper to understand these challenges and how you can maximize your success with Kubernetes.