Need of Package Manager
This tutorial will discuss the purpose and need of package manager within the Kubernetes environment.
Within the Kubernetes cluster, we will be deploying n number of entities like Pods, services, deployments, secrets, config files and a lot more. All the definitions of these entities will be available as a YAML file.
So I will be having a collection of YAML files and will deploy the entire collection. And it demands the deployments to happen in some sequence.
So what we will be doing will consolidate all the YAML files in a single YAML file and maintain the YAML file within some repository. And from the repository using some CI/CD 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 the application. When I’m making the change or update to the application, I will change some values.
For example, let us consider this particular YAML file, which will be deploying the Redis service.
apiVersion: v1 kind: Service metadata: labels: app: redis name: redis namespace: vote spec: type: ClusterIP ports: - name: redis-service port: 6379 targetPort: 6379 selector: app: redis
Here I have mentioned the port and the target port for this particular service; it’s mentioned, and it is hardcoded within the YAML file.
And in case if this particular value changes depending on the environment, say, for example, I may have a test environment where I wanted the port value to be 1234 and the number of pod counts to be two.
So within the YAML file, we will have this particular hard coded value, and in production, I may have the port value as say 8080 and the pod count say 6.
So what I’ll end up doing, I’ll end up maintaining 2 YAML files—one YAML file for the test environment and another YAML file for the production environment.
Other than these values, the template, i.e., the other configuration details, will be the same. So what I’m maintaining? I’m maintaining some duplicate values.
Templatising and the package manager
To solve the above problem, templatizing and the package manager comes into the picture. So what I will be doing will extract the common elements as a template.
So I’ll have the variable referred over here, and only this particular variable needs to be substituted. I will be maintaining some value files over here for each environment.
So value for the 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 the production environment as well. While doing the deployment, all I need to do is use the template file, which will be the 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 CI/CD can pick the suitable files when it is getting deployed into the corresponding environment. This is where the most significant advantage of templatizing, repeatability, all that comes into the picture.
Another most significant advantage is if I am making any change to this particular system or any of this particular value, say if I am changing a specific service port from 8080 to 8088, what will happen?
It will identify the need and the hierarchy and the dependent services that need to be deployed, and only those entities will be deployed or upgraded.
So we can do different types of deployments like blue, green, or rolling and all other possible deployments within the cluster.
This exclusive representation of templates and values, the package manager that is helm provides some standards and structure, how should create templates and represent the values, how the sub-templates, and the complex representation of various entities Kubernetes cluster, is defined within the helm.
That’s what we are going to learn in detail about 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 teams over the Internet or share it with other CI/CD tools, we can go ahead and do that.
So this is a quick overview of the need and purpose of package manager within the Kubernetes environment.