In this tutorial, we are going to discuss about quick overview on various components of helm.
When it comes to helm, the main components with which we are going to interact is helm client and we can install 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.
The next important component of helm is the charts ,that’s going to be the building block of the entire helm where the entire application definition will be made within the charts and the charts provides various features, how the applications can be defined within the Kubernetes environment.
Charts has collection of files, different structures to define values and how to build a sub chart and to represent any complex environment within the Kubernetes cluster, It has the options.
Helm configuration files are referred to as 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 discussion about each and 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 can be shared with other team members as well as the next version can be created and that we call it as repositories.
Repositories are nothing but a storage environment where various charts of various applications can be stored and can be shared with other members within the team or across the teams.
Once the chart is released into the environment, that instance we call it as release and we can have multiple versions of release in multiple environment and all that will be managed by the helm client.
What releases installed, in what environment, what values were used and any value that I wanted to change and make a next upgrade of the release or rollback of the release.
Everything will be handled and release is nothing but the instance of a chart that is deployed into the environment.
So if I had to collaborate all these terminologies as a workflow, we can 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 available, I can store within the repositories and the repositories will facilitate to store 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 all the dependent files of the charts will be put within a single zipped file and it can be sent to the external world or store it in a different environment.
Once if 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, roll back, deleting, status maintenance as well as version handling of the application.
The version handling going to be very simple with the helm where in a single command, I can roll back to the whatever version that I wanted as well as upgrading is also going to be using a single command.
We will be seeing the entire lifecycle, as well as all the components that we have discussed over here in detail in future tutorials.