Helm Components
This tutorial will discuss a quick overview of various helm components.
Helm Client
When it comes to the helm, the main component we will interact with is the helm client, and we can install the helm client in any system.
Once the installation is done, that’s going to facilitate the interaction between the user and the helm components, as well as it’s going to facilitate the communication to the Kubernetes cluster.
Helm Charts
The following essential component of the helm is the charts, which will be the building block of the entire helm, making the entire application definition within the charts. The charts provide various features, how can define the applications within the Kubernetes environment.
Charts have a collection of files, different structures to define values, build a sub chart, and represent any complex environment within the Kubernetes cluster; it has the options.
Helm configuration files are charts and consist of a few YAML files with metadata and templates rendered into Kubernetes manifest files.
We will be having lots and lots of detailed discussions about every component in upcoming tutorials.
So charts are nothing but how a Kubernetes application should get deployed within the Kubernetes cluster. That’s going to be the definition file, and once the file is created, we need to manage the files.
So that we can share with other team members as well as the next version can be created and that we call repositories.
Repositories
Repositories are nothing but a storage environment where various charts of various applications can be stored and shared with other team members or across the teams.
Release
Once the chart is released into the environment, we call it a release, and we can have multiple versions of the release in multiple environments and all that the helm client will manage.
What releases were installed, in what environment, what values were used and any value that I wanted to change and make a next release upgrade or rollback?
Will be handle everything, and release is nothing but the instance of a chart deployed into the environment. So if I had to collaborate all these terminologies as a workflow, we could visualize it this way.
I can have n number of chart files, and the chart files will be packaged together using the helm, and basically, the helm will facilitate us to create that as a package.
Once the packages are available, I can store them within the repositories, which will facilitate storing the charts.
So, once the helm packages it, I can store it within the repository. Once the charts are available within the repositories, I can package them as a tar file where I will put all the dependent files of the charts within a single zipped file. It can be sent to the external world or stored in a different environment.
Once I have the charts within the repository, I can use them and create an application and deploy it into the cluster.
So here, the management of the entire lifecycle of the application will be handled. That is right from creating, installing, upgrading, rollback, deleting, status maintenance, and version handling of the application.
The version handling will be straightforward with the helm wherein a single command; I can roll back to whatever version I wanted, and upgrading will also be using a single command.
So this is a quick overview of the helm components. We will see the entire lifecycle and all the components that we have discussed over here in detail in future tutorials.