As modern software architectures increasingly adopt microservices and cloud-native approaches. The deployment and management of applications in Kubernetes environments have become more complex. Maintaining consistency and reliability across deployments can be challenging with multiple services, configurations, and environment-specific settings.
Enter Helm, a package manager for Kubernetes. It solves resource issues by letting you bundle resource files into a single package. With Helm, you can define, install, and upgrade the entire application consistently and reliably. In this blog post, we will learn about Helm, how Helm works, the pros of Helm, and the shortcomings of Helm-cli.
What is Helm?
Helm, a Kubernetes package manager, simplifies application deployment over Kubernetes. The helm chart includes all the Kubernetes resources. They are defined in Yaml files, which are often called manifests. These resources include deployments, secrets, config maps, and services. Where the configuration values for each environment are templated from file name values.yaml. By leveraging the Helm charts you can streamline the deployment process. Instead of changing each manifest (deployments, secrets, config maps, and services), you must edit the values.yaml file. Helm then deploys your app with the new values to Kubernetes. It ensures consistency and reduces the potential for errors in configurations.
Helm Charts
Charts are the building blocks for the deployment of applications to Kubernetes. These charts are pre-configured packages. They contain templates of all the needed resources for your application to run on Kubernetes. These charts can be used to deploy something simple as a pod or something complex as a full-fledged enterprise application.
Consider an application with 15 microservices. They should be deployed across staging, development, and production environments. Each environment will have its own set of parameters and configurations
You may need 3 replicas for some services, at the staging environment. Production may need 5 copies. This is to ensure high availability, fault tolerance, and scalability. They are required to handle production-level traffic.
If your application includes a service like a database, the configuration and secrets will vary for each environment.
The monitoring and observability setup may differ across the environments.
The networking setup will differ across environments. It includes ingress setup (e.g., load balancers, and routing rules).
To handle this, you need to maintain multiple YAML files. You need them for each service and environment (staging, development, production). That gets complicated and error-prone. With Helm charts, you need to manage a single package. It's a chart of your application. It contains all the resources required to deploy the application to Kubernetes. Helm charts use templating architecture. This allows them to fetch environment-specific values (like staging, development, and production) from a single ‘values.yaml’ file. So when you need to deploy an application in any environment, you just need to modify a single ‘values.yaml’ file.
This approach makes configuration management simpler and promotes consistency across environments. It also helps with versioning and rollbacks.
Structure of Helm Chart
Let's understand the structure of a Helm chart by taking the example of the Nginx chart:
A typical Nginx Helm Chart has the following structure:
nginx/
├── Chart.yaml
├── values.yaml
├── templates/
│ ├── _helpers.tpl
│ ├── configmap.yaml
│ ├── deployment.yaml
│ ├── hpa.yaml
│ ├── ingress.yaml
│ ├── service.yaml
│ ├── serviceaccount.yaml
│ └── tests/
│ └── test-connection.yaml
└── README.md
Chart.yaml: This file contains metadata for the chart. i.e. name, version, etc.
values.yaml: This file contains the configuration values for the Application deployment to a specific environment. These values can be updated while deploying the Application to another environment.
templates/: This directory contains the Kubernetes resource manifests (deployments, services, configmaps, ingress, and secrets) templates that will be combined with the values from values.yaml to generate the final manifests.
_helpers.tpl: This file contains helper functions and templates that can be used in other templates.
configmap.yaml: This template defines a ConfigMap object that can be used to store Nginx configuration files.
deployment.yaml: This template defines the Deployment object for running the Nginx pods.
hpa.yaml: This template defines a HorizontalPodAutoscaler object for automatically scaling the Nginx deployment based on CPU usage or other metrics.
ingress.yaml: This template defines an Ingress object for exposing the Nginx service to external traffic.
service.yaml: This template defines a Service object for exposing the Nginx deployment internally within the cluster.
serviceaccount.yaml: This template defines a ServiceAccount object that can be used by the Nginx pods if needed.
tests/test-connection.yaml: This template defines a test pod that can be used to verify the Nginx deployment is working correctly.
README.md: This file contains instructions and documentation for the Nginx Helm chart.
Chart Repositories
Chart Repositories have a crucial role in the Helm ecosystem it provides a centralized location for sharing Helm charts. These Repositories can be hosted locally or on remote servers, making downloading and installing charts easy. E.g. Helm Repository is ArtifactHub. With these Chart Repositories developers can leverage pre-built charts for common applications and services like using a chart of Prometheus for monitoring purposes. This saves time and effort as you can use proven configurations for specific applications and services.
Helm Architecture
To understand how current Helm architecture works i.e. Helm 3, we need to understand the working of previous versions of Helm i.e. Helm 2.
The previous version i.e. Helm 2 was based on ‘Client-Server’ architecture. The components for that were:
Helm Client
Helm Server (tiller)
Helm Client
It’s a command line tool that helps you interact with the Helm server (Tiller) to manage Kubernetes resources (Helm charts). The Command Line Tool is responsible for creating, installing, upgrading, and uninstalling Helm charts.
Helm Server (Tiller)
Past then Kubernetes lacked functionality like Resource Base Access Control (RBAC). To allow the Helm to interact with the Kubernetes cluster while facilitating security, a new component “Tiller” was introduced.
A server-side component of Helm runs on your Kubernetes cluster. It handles the operations you request through the Helm client. Includes taking your configuration files, rendering the Helm charts, and communicating with the Kubernetes API server to create or modify the resources.
Helm 3 Architecture
As Role-Based Access Control (RBAC) gained traction in Kubernetes, users gained the capability to manage granular and precise permissions for Kubernetes resources and actions. In Helm 3, the middle component “Tiller” was completely removed. Now the security is being handled by the RBAC. In Helm 3, the client can directly communicate with the API server of your Kubernetes cluster.
How does Helm Works?
To understand how Helm simplifies application deployment and configuration management, let's consider a scenario where you need to deploy an application across multiple environments, such as production, staging, and development. Without using Helm, you would typically need to maintain separate Kubernetes resource files (YAML manifests) for each environment, managing the differences in configurations, replica counts, secrets, and other environment-specific settings.
Whereas with Helm, you can create a single chart for your application, which bundles all the necessary Kubernetes resources (deployments, services, ConfigMaps, secrets, etc.) into a unified package. Instead of modifying individual YAML files for each environment, you can just modify values.yaml file and deploy the application.
This is how the process works:
Creation of Helm Chart: You will start by creating a Helm Chart for your application, which includes templates for all required Kubernetes resources (deployments, services, ConfigMaps, secrets, etc.).
Values.yaml: You will be defining the configurations for your application as per the environment you are deploying. I.e. for staging if you require 2 replicas, you will be updating the values.yaml file accordingly.
Helm Renders Charts: During the deployment process, Helm renders the chart templates with the appropriate configuration for specific environments from values.yaml file and generate environment-specific Kubernetes manifests.
Deploying to Kubernetes Cluster: Once Helm generates the environment-specific Kubernetes manifests they are deployed to the Kubernetes cluster. According to the Helm request the Kubernetes APIs create or update the necessary resources based on configurations.
Advantages of Helm
Simplified Application Deployment: Helm packs all the necessary Kubernetes resources (deployments, services, ConfigMaps, secrets, etc.) into a single package called a chart, making it easier to deploy and manage applications on Kubernetes.
Consistent and Reliable Deployments: With the use of Helm charts, you can ensure consistent and reliable application deployment across environments (development, staging, production) by simply modifying the values.yaml file.
Configuration Management: Helm separates the application configurations from deployment manifests, allowing you to manage configuration more effectively. You can easily update configurations by modifying the values.yaml file.
Versioning and Rollbacks: Helm supports versioning of charts, allowing you to track changes and roll back to previous versions if needed, promoting better release management.
Reusability and Sharing: Helm provides a centralized repository (e.g., ArtifactHub) for sharing and discovering pre-built charts for common applications and services, enabling reusability and saving time and effort.
Challenges with Helm
At a point where Helm offers numerous advantages for deploying and managing your applications over Kubernetes, there are some challenges with it that users are most likely to face.
Learning Curve: Helm CLI, being a command line utility, brings up a learning curve for users to understand and master ample commands. On the other hand, the templating structure itself is quite complex when it comes to creating a helm chart for complex microservices.
Lack of Visibility and Monitoring: Helm CLI does not provide a built-in mechanism to view the health and status of applications deployed through its charts. Users need to rely on external monitoring tools or manually inspect the deployed resources to assess the state of their applications.
Limited Integration with GitOps Tools: Popular GitOps tools like ArgoCD do not natively store the deployment history of applications deployed through Helm. This can make it challenging to track changes and rollbacks for Helm-based deployments.