so let's now see what is helm architecture okay so uh basically there are two watches of hell helm2 and helm3 okay helm2 no one is using these days .
Okay because it is an older uh you know older version of the helm and now the latest version is health 3.7 okay column 2 is very old so we have the kubernetes cluster on one side okay so i have ignored the rest of the components okay so we have the kubernetes cluster and there is a helm client .
Okay so uh how we are talking to the kubernetes cluster guys so we have the cube ctl utility right so this is a command line utility and there is a cluster involved kubernetes cluster okay so using cube ctl utility we can directly talk to the api server so that is running in the cluster .
Similarly if i wanted to install some application in the kubernetes cluster my helm utility okay so i'm not uh i don't call it as helm ctl because it is only named as helm so this helm utility also talk to the communities cluster correct .
Then only it can deploy the applications right so that is so called helm client okay so in version 2 so there is a client on a local machine and there is also server component known as tiller .
That's why we call it as helm and tiller elm client is your local client and tiller is where tiller is running in your kubernetes cluster as a pod okay so directly this helm client cannot talk to your api server in helm2 .
You talk to the tiller and tiller takes care of forwarding that request to the api server okay let's say i wanted to install a nginx application so instead of opting for yaml files i opted for a helm chart .
Then if i issue a command to deploy that helm chart so first it goes to the tiller tiller will verify whether the client is authenticated or not and then it will forward that request to the api server so this is just for the security purpose let's say tiller can .
Receive the request from any client right but it has to execute the request only from the authorized client so that's why this tiller component over here it is verifying whether the request is genuinely coming from the helm client .
Or it is from a different client right so now what this helm client will do generally so it can download the helm charts for you okay and then if you want to install if you run the helm install command at the client side so it can forward that request to the killer component .
Okay so on the helm client it can manage the charts and the it can communicate with the taylor component also known as the server component and what is a helm chart a hand chat is nothing but a simple tar file which has you know a set of aml files it is .
Nothing you take all the aml files for your application you bundle it as a tar file but helm follows a certain directory or a directory structure okay using that structure only you know it will understand only that structure if i take 100 yaml files if i .
Put it in a you know director and i name it as a tar file and if i use helm commands to install that tar file it won't work because ellen follows a specific folder structure you have to put your yaml files according to that folder structure so we'll come back to it understood guys .
Simply putting all the ammo files in a tar file and calling it as a helm chart doesn't make any sense understood and this helm client can also download the charts from the chart museum okay like uh for docker we have the docker repositories right we have the nexus .
Repository running in aws or the jfrog hosted repository or it can be docker hub itself correct similarly for helm charts also there are there are public repositories also known as chart museums so we have artifactory hub okay and also we'll have various third-party .
Uh you know repositories also from where helm client can pull that chart okay and then once helm chart has that chart over here one you once you issue the helm install command that complete chart will be sent to the tiller component now it is the tiller that will render your charts so we'll come back to what .
Is rendering okay and then deploy your applications and then it will track various applications state okay so it is the killer component now in the health tree architecture what happened is so your tiller component is completely removed and now the helm client directly .
Talks to the api server so there is no third part or the middleware that is existing between a client and the api server in the helm 3 directly helm client talks to your api server ok so this aps server can be running in .
Your aws or gcp or any in a cloud provider this element client can be in your local system so now my question is i have helm client insta installed in my local system i have a cluster running in gcp or in any public cloud and if i wanted to install some chart .
Okay i have used some help commands so tell me how does this communication happens like in from my local system i'm issuing the commands how does the command reaches the server which is running in aws or it is running in some other node or else imagine this scenario i have the .
Cubesat utility so i wanted to create a part so this cube city utility in my local pc but the cluster is running somewhere in the public cloud okay how do i create a pod in this case so what is the usual you know process i follow take a config file .
Sorry we take that uh config yeah move it to the keyboard cube ctrl always look for the cube config file right so it will be always in your uh in your user directory inside the dot cube hidden folder a file called config okay so it reads this config file .
Gets the server information so server information in the sense the server url okay so the server url now it is the aws right so it will have a public url right so that is how qctl will find the location of your server similarly when you when helm wants to talk to the api server elm also reads the same file cube config file .
Because it has to know where exactly your api server is running right so it also reads the same file if the file is not existing right your handling installation will fail and there are other ways also to give the location of the cube config file okay this is the first location right and what is the other location right so .
There is an environment variable called cubeconfig so you have to set this environment variable so let's say i've placed the you know the config file here slash time slash config let's say then my usual cubesitl will not find it .
Because it will always look for the file inside the home directory user's home directory but if you have any other directory you just you know put this as an environment variable cubeconfig so now if cubesitl uh not able to find that cubeconfig file in the home directory it will read this environment variable .
And then it will fetch the location where the queue config file is existing okay so we you know spoke about this right guys there are three ways one is the user home directory and then there is a q config environment variable or else when you are running the cube ctl .
Commands you would do like this iphone iphone queue config is equal to the location of the cube config file you know followed by the rest of the command like get parts or something understood guys yes okay let's talk about the helm components so uh helm client or help .
Both indicates the same thing so it is a command line utility used for developing your charts or you know pulling the charts from the repositories you know everything okay this is a command line utility it is from the client side and in this server we have a component called as a tiller or a tiller server .
Okay so it mainly receives the information or the request from the helm client okay so this tiller was completely removed in a helm3 okay understood so what is the use of killer it listens to the client request and then it will install upgrade delete kubernetes resources in the cluster .
Okay what is a chart so chart is nothing but your application packaging right it is a package that has all your application related yaml files okay and then what is a release a release is a runtime instance of a chart let's say i have an nginx chart okay now i wanted to release the nginx .
Application then i will use the engine x chart right so that becomes a release so i've used engine x the same engineering start and then extract to release one more application so that becomes a release too okay so the release names can be configured okay so the release are .
Nothing but the runtime instances of the chart it is like a docker image and this is like a docker container something like that understood this and what is a repository it is a place where we host all our helm charts so we can have we .
Can use nexus as the uh you know and chart repository jfrog as the chart repository okay there are plenty of open source helm repositories okay even in nexus also i can store the helm charts pull the helm charts understood this yes .
Okay so uh so this is again an important question in the interview point of view okay so the first question they will ask you what is the difference between helping three and two okay the first difference is tiller component is removed from helm3 .
Okay so why it is removed is earlier to the kubernetes 1.6 kubernetes didn't have role-based access control that means that you know anyone can access the cluster okay so in order to avoid this what helm did is from the client side there is a helm client but on the server side it has a tiller so instead of .
Everyone talking to the dealer component so only the helm clients will talk to the tiller and that too this tiller component will now verify whether it is coming from the current helm client or not okay if the tiller component is not there everyone will talk to the kubernetes cluster directly .
Okay so this tiller component is over here it is handling the authorization part for us but with q1 it is 1.6 rollback is enabled in the kubernetes so since rollback is already there so this tiller component was never needed to continue in the cluster so that's why tiller component was .
Removed in the helm tree okay so this is a major you know uh difference between helm2 and helm3 understood guys and there will be one more question what is three-way strategic merge patch okay generally watch what is a patch yes generally what is a patch .
Guys what is a patch become actually if there is a any uh update kind of thing is needed for that of any bug here yeah we have to install that correct so there is a patch needed right it's a minor change that we give to the application .
Okay so helm follows three-way strategic merge patch so we'll come back to what is three-way strategic merge patch in helm 2 helm2 uses two-way strategic merge patch that means let's say in one version okay so i have uh one instance of an application running .
For the second release what i will do is i wanted to run two instances or three instance of the application so i'll configure my helm chart to deploy three instances okay now what uh helm will do is how we will compare the uh difference between two releases so it will know that already one instance is running inside .
The cluster and now the user requested for three instances so it will deploy two more instances okay so this is a comparison between the current state which is the one and the required state required state is three .
And the current state is one okay so this is a comparison between the current state and the desired state that is a two-way patch okay comparing with the previous release but what let's say initially one replica is running .
Okay and now i wanted to run three replicas okay in the two-way merge patch there is a difference between these two right this is the required state and this is the desired state so what happens if someone goes into the cluster and they manually change this replica .
Count to let's say uh zero okay they have not done through the hand chart they have not done through the um you know they have done through the cube city led it or some in some other way and they brought the replica account .
To zero okay so in this case what happens is helm is not aware of this change so once you request for the you know replica count as three for the next release helm thinks that there is already one replica running because in the earlier instance you know the user has deployed one .
Instance so it will spin only two instances right but the desired state is three helm things that there is already one running but someone came into the cluster and then they have deploy removed the uh you know they decrease the repeat account to zero so the current state is .
Zero okay but what helm will do helm will deploy only two right understood helm is not aware of this change but in the three-way strategic merge patch what happens is so there is a three-way comparison first helm will check .
Okay the old manifest file which is one replica it will check the newer replica which is three then it decides that there are two to be rolled out but it will also see what is the current live state of the cluster whether there is actually one port running or there are .
Two parts running or there are zero ports running it will also take care of the current state if the current state is 0 if it is not matching with the earlier state then it will deploy three instances understood yes figure .
So this is called three-way strategic merge patch and this is what helm does for us okay even after really in the helm charts right you delete any resource okay during the helm roll back it will install that resource back or during the helm upgrade it will also check the current state if the current state .
Is not matching so it will you know try to bring back that current state as well okay so i'll i have a small example for that and now secrets as a default storage driver in lm3 so uh we were saying that helm managed the releases right so release one release to release three so helm knows what we have used for release one okay what dml files .
We have used what image tags we have used one what replicas we have used similarly it maintains the release information for each and every release so now if i want to roll back from release three to one so it knows what all yaml files what all changes you have made okay it already stores it .
Okay that's why i was saying you don't have to manually remember what all changes you made to the yaml files because i'm already storing these changes somewhere earlier these changes were stored as the config maps okay so it is used to store them as a config map so anyone can you know open .
That config map and see the yaml files okay for release one visual ammo files that user has used buffer helm2 which all yaml files has used so helm will store them in the config map so that it can prefer these yaml files or the config maps for roll backing understood guys .
It is like maintaining a registry of every release information but cuban what if you are going for the plain kubernetes will communities do that for you it won't do right it won't store the release information it won't it will only store your you know the resources information which are currently running .
It will not store your past resources information okay but in m3 what happened is instead of you know storing those release information config map it now stores in the secrets because secrets are harder to decode right because config maps are very easier to read so anyone can get your .
Release information but now secrets are being used as a storage uh in a storage driver okay and now we also have something known as json schema validation okay what is schema validation is let's say you want your application to have .
A tool you know for deploying your application you want the users to follow certain set of rules that means the user has to have the replica account set to more than two or you want them to create or you know mention the resources needed for each part let's say every part needs you know .
0.5 cpu or you know or anything like you know 300 mi of ram let's say okay so this uh you know resources are to be put in place so i can put the validation like if someone is not giving the replica account or if someone is not giving the .
You know a proper resource requirements or if someone is not defining the image pull policy okay so i can put all these validations to make your chart production ready because when you are going for production you want everything to be perfect right so whenever if you create the json schema right and if the users .
Are not following that schema while preparing the helm chart okay that held chart won't be deployed okay that validation also i can put so these are like the strict rules to be enforced on the helm charts under studies any door okay and now release name is also .
Required release name is also required in the sense so for when i'm installing the helm chart right helm install uh i wanted to install nginx chart but i should also give the name okay name like nginx v1 so this is the release name so with which name i'm releasing the software so earlier this release name .
You know was not required because helm used to you know define a random name and it used to release the software but now release name is made mandatory that means that you have to give a custom name yourself okay understood guys now let's understand the three-way strategic merge patch okay so in the v1 version of the .
Yaml files okay i have a set of yaml files so that set of ml files has one container okay the name of the contains end and the application is 2.0 okay now what i wanted to do is i wanted to increase the version number or the application image to 2.1 so i have one more release too .
Okay in the aml files i made the only this change 2.0.1 okay understood guys understood so that is required but after releasing the first version some user came so he has used cuba city edit or some .
Manual method he has injected one more container into that pod so there are two containers in a pot so this is a live state okay but this state is not recorded in the helm charts because helen charts only has this information but someone through manual methods he .
Has injected let's say uh you know this one more container okay or if i say that you know i have the replicas as one initially i wanted to have the replicas as three as they released two but someone came and manually they have increased the .
Replica account to two okay so what happens in the two-way strategic merge patch or helm 2 is helm will compare only the previous version and the latest version to be deployed then it will say see that okay the previous version has uh you know app 2.0 and the new version has app .
2.0.1 okay and it will take that initially there is one instance running now there are three instances needed now what it will do is it will change the image version to 2.0.1 because that is the current one current they release 0-2 but what it will do is it will ignore all the manual changes .
That means if you have created a container and you have injected into that part that container won't be available in your cluster anymore because it is only considering the previous release with the current release right but in case of a helm3 what elm3 do is it will come by the previous chart .
And the new chart it knows that there is a new version to be released then it will also take care of the live state so the live state also has extra container then it will also include that container so it will include the latest changes and it will retain the .
Previous changes including the manual changes understood guys so that is known as three-way matchpad this is the live state this is the required state and this is the old state so that's it for this video guys if you like our video kindly join our facebook .
Group and subscribe to our youtube channel the links are given in the description below you can also scan the qr codes being displayed in this video for any devops related trainings kindly join our telegram channel which is devops made easy you can also scan this qr code being displayed in this video you can also whatsapp us on the number .
Being shown or else directly email us on the email address provided
versuszone