Hi, let us understand the purpose and need of a package manager within kubernetes environment.
Within kubernetes cluster, we will be deploying n number of entities like pods, services, deployments,
secrets, conflict files and lot more, and all the definition of these entities will be available as a YAML file.
So I will be having a collection of Yaml files and the entire collection will be deployed.
And it demands the deployments to happen in some sequence.
So what we will be doing, we will consolidate all the Yaml files in a single YAML file and the YAML
file will be maintained within some repository.
And from the repository using some CICD tools, we will be deploying it into the kubernetes cluster.
So things will be done there
But the problem originates whenever I wanted to make some changes or update to the application.
When I'm making the change or update to the application, I will be making change to some values.
For example, let us consider this particular YAML file, which will be deploying redis service.
Here I have mentioned the port and the target port for this particular service
It's mentioned and it is hard coded within the YAML file.
And in case, if this particular value changes depending on the environment, say for example,
I may have test environment where I wanted the port value to be 1234.
And number of pod count to be two.
So within the yaml file, we will be having this particular hardcoded value and in production
I may have the port value as say 8080 and the pod count say 8
So what I'll end up doing, I'll end up maintaining two YAML files.
So one YAML file for test environment and another YAML file for production environment.
Other than these values, the template that is the other configuration details will be the same
So what I'm maintaining, I'm maintaining some duplicate values.
Here's where the advantage of Templatising and the package manager comes into the picture.
So what I will be doing, I will extract the common elements as a template, so I'll have the variable
to be referred over here.
And only this particular variable needs to be substituted.
So I will be maintaining some value file over here.
for each environment. So value for test.
And that can be maintained as a json file or different file formats.
Here I am demonstrating for understanding purpose.
Don't worry about the syntax or the format of the files.
And the same way I will be having another value file for production environment as well.
And while doing the deployment, all I need to do is I need to use the template file, which is going
to be same for both environments.
Only, the value file will be fed into the system depending on the type of deployment that I wanted to do.
And CICD can take care of picking the right files when it is getting deployed into the corresponding
environment. This is where
The biggest advantage of templatising repeatability, all that comes into picture.
Another biggest advantage is
In case if I am making any change to this particular system or any of this particular value, say,
for example, if I am changing a port of a specific service from 8080 to 8088 what will happen
It will identify the need as well as the hierarchy and the dependent services that needs to get deployed.
And only those entities will be deployed or
It will get upgraded and we can go ahead and do different type of deployments like blue green, or rolling
and all other possible deployments within the cluster and this entire representation of templates and
values, the package manager that is helm provide some standards and structure, how the templates should
be created and how the values can be represented.
How the sub templates as well as the complex representation of various entities of kubernetes cluster
is defined within the helm.
That's what we are going to learn in detail of each and every syntax within the template, the value
files and how to package the entire structure
That is, the template files, value files, all of them together and send it across
or share it with other team members in case if I want to version it as a repository and share it with
other team over the Internet or share it with other CICD tools, we can go ahead and do that.
So this is a quick overview on the need and purpose of package manager within the kubernetes environment.