About Kubernetes architecture(4); Helm

I have previously discussed some stuffs about Kubernetes architecture ,check out my home page aleqxan.medium.com for them. In this article, I would be discussing an important factor in the Kubernetes architecture which is known as Helm, a package manager for Kubernetes services.

Helm

Helm

With the adoption of microservices for the deployment of applications, Kubernetes plays a vital role in reducing complexities while scaling and deploying these applications. Having microservices in view, lots of configurations would be involved especially when deploying applications with lots of funtionalities. Helm is a package manager that helps with configuration, packaging, and deploying those applications easily to the Kubernetes cluster.

Helm wraps up every single component of the application you intend to deploy. Helm packages these applications in charts, deploying them as one unit.

Helm helps you with improving your productivity and reducing the complexity when deploying microservices.

Helm charts

Helm Charts are Kubernetes YAML manifests combined into a single package that can be advertised to your Kubernetes clusters. Once packaged, installing a Helm Chart into your cluster is as easy as running a single helm install, which really simplifies the deployment of containerized applications.

Helm functionalities

• The client (CLI), which lives on your local workstation. It is responsible for push the resources you need
• The server (Tiller), which lives on the Kubernetes cluster to execute what’s needed, but is not available on helm any longer due to the power it yielded, so newer versions of helm(from version 3) doesn’t come with a tiller.
• It supports the installation and upgrades of charts as a whole
• It comes with a built-in chart rollback to its previous version without going through the CI/CD pipeline again.

Helm has a certain structure when you create a new chart. To create, run helm create (file name) when you run the command, your directory looks like this;

YOUR-CHART-NAME/
|
|- .helmignore 
| 
|- Chart.yaml 
| 
|- values.yaml 
| 
|- charts/ 
|
|- templates/

.helmignore: this is similiar to .gitignore, its used to specify files you don’t want to include in your helm chart.

Chart.yaml: this is where you put all the information about the chart you are packaging, could be name, dependencies or version.

Values.yaml: this file is used to pass values into the release helm chart. it defines all the values you want to inject into your templates. It is the default values that you can override later.

Charts: This is where you store other charts that your chart depends on.

Templates: This folder is where you put the actual manifest you are deploying with the chart. For example you might be deploying an nginx deployment that needs a service, configmap and secrets.

Installing and configuring Helm

The following prerequisites are required for running Helm;

1. A Kubernetes cluster
2. Installing and configuring Helm

It is recommended to use the latest stable release of Kubernetes, which in most cases is the second-latest minor release.

Download a binary release of the Helm client. You can use tools like homebrew, or look at the official releases page, then check out the installation guide.

Once you have Helm ready, you can add a chart repository. Check Artifact Hub for available Helm chart repositories.

helm repo add bitnami https://charts.bitnami.com/bitnami

Templating engine

When you are deploying a microservice application in the same environment you can create a common blueprint, use placeholders for dynamic values, this is possible with a template file.

{{ .Values.name }} means that you are taking a value from external configuration. The external configuration comes from an additional values files called values.yaml with it you can define all those values you will use in the template file. .Values means it’s an object that is created based on the values defined. The values defined are either via yaml file or with --set flag . Instead of having many files for your various microservice you just have one. It is practical mostly with CI/CD, helping you replace values as you keep building.

When deploying the same set of application across different environment(development, staging and production cluster), instaed of deploying the individual yaml file in each cluster, you can package them up making your own application chart that would have all the necessary yaml file that the deployment needs, then use them to redeploy the same application in different Kubernetes cluster environment using one command, making the deployment process easier.

Common Helm best practices

As defined by https://medium.com/devopscurry here are some common best practices for Helm.
→ Make sure you use the non-root containers to perform actions for production deployment. The non-root containers are executed by the users that are different from the root. Though setting a non-root container is a more complicated job than a root container. You should prefer to use a non-root containers for kubernetes like environments. You can add the securityContext section to your YAML files to make your chart work with non-root containers.
→ You should not persist in the configuration of the application. With Kubernetes, you can easily change the deployment parameters with easy commands. If the configuration is continued, it means none of the changes would be done. While making Helm charts, make sure that the configuration can be changed easily using helm commands.
→ You can use logging and monitoring tools to be integrated within your charts. To detect any threats at the early stage of deployment, it is essential to use monitoring tools and the right metrics tools to check the incurred cost and resources. With the proper monitoring and logging tools, you can easily handle the production workloads.
→ It is better to have a single chart containing a single application. This chart will include the required application’s resources. A single chart can also have dependencies on other charts.
→ Try to run your deployments from a clean setup. Else, it might get impacted by other repo settings. You can use the pre-built Docker image to create a clean environment.
→ You can always use a generic chart for a namespace configuration.
→ Always try to declare your repositories using an IAC tool and try to avoid a legacy chart repository.
→ Try to avoid hardcoding the namespace and write a good output template.
→ Try to run both upgrade and fresh install tests for your chart releases for better monitoring and testing.

Conclusion

Helm is a powerful package manager that makes installing and managing applications on top of Kubernetes as simple and easy process. With it you can package your microservices and avoid much complexities with other methods.