Introduction to Helm | Kubernetes Tutorial | Beginners Guide

[Music] so you've just started out with kubernetes and you're new and you're learning about all these yaml files all these yaml files that you have to maintain if you've been learning about kubernetes and how to run applications on top of kubernetes you've probably come across a tool called helm in kubernetes we describe everything we do with yaml files these yaml files represent objects such as deployments pods services config maps secrets and more well the beauty about kubernetes is that it's declarative what does declarative mean declarative is rather than writing scripts we tell kubernetes exactly what we want and kubernetes makes it happen if an application goes down or the server underneath goes down kubernetes scheduler will move that application to another machine it does this by taking the desired state of what we want and monitors the actual state and it makes sure that the desired state matches the actual state the desired state is defined by these yaml files and that's what makes these yaml files important but managing all these yaml files can sometimes become a little complicated to demonstrate this a system in kubernetes can have multiple yaml files now if we take a look at my github repo for example and we go into the kubernetes folder we can see i have a deployment folder with a deployment.yaml this describes to kubernetes how to deploy my application we tell it how many replicas we want what container image we want to deploy the ports to expose and the resource limits but my application needs more than that so we also have a secrets folder with a secret.yaml where we have a secret definition of a secret that my application might need we also have a config map so we take a look at the config map folder there's a config map yaml so my application also needs some form of configuration now my application needs to be exposed to other services so i have a services folder with a service dot yaml that tells kubernetes how to expose my application and here we describe that we want a load balancer and we want to expose port 80. now there's more than that maybe i need some storage so i have a persistent volume folder with a persistent volume describing some storage that my application might need and there are many other types of kubernetes yaml files as well so it doesn't end here so it's important to notice that all these yaml files make up my application and its infrastructure and it's important to notice here that it's not reusable now if i want to build another application to reuse this yaml i would have to copy paste all of these files and then change what's needed and as i build more applications i may end up with a lot of yaml files and a lot of duplication and over time these yaml files may become hard to manage and this is where helm comes in helm is a package manager for kubernetes it allows us to bring all of these yaml files together in what's called a chart a chart can have a name a description and a version a chart groups all these yaml files together in a templates folder to make this chart reusable we have the ability to inject values as parameters so i can deploy this chart and inject the name that i can use in my deployment for example app1 i can then reuse this chart and deploy it somewhere else with a different name like app2 so now once we have this chart we can effectively reuse the yaml files by injecting parameters into it this gives us greater flexibility as we can reuse these charts among many applications and micro services but injecting all these parameters into our chart over the command line can make the command line very long and we don't necessarily want to change everything inside of the template over the command line now injecting these parameters over the command line is one way of doing things but helm also allow us to pass the values as a file so we can place all the values we want to inject in a file and we can call that file app1 we can also place values in another file and call that app2 so when we deploy our chart we can simply supply the values for f1 or app2 depending what we want to deploy helm will inject the values into the chart and render the final yaml for either app one or two these files are called values files injecting a values file to our chart makes our chart generic so if you take a look at my github repo i have a kubernetes folder and in that folder i have a helm folder with a readme and this readme shows the introduction to helm with all the steps i'm going to be showing you guys today so be sure to check out the link to the source code down below so you can follow along [Music] so the first thing we're going to need is a kubernetes cluster now to create a kubernetes cluster i'd like to use a utility called kind this allows me to create disposable kubernetes clusters that i can use for testing so to create a cluster we're just going to say kind create cluster we're going to call it helm and we're going to run kubernetes 1.19.1 so i go ahead and copy this i paste it to the terminal and that will go ahead and create a single node kubernetes cluster within a container and once that is done we can see it's gone ahead and created our cluster i can verify this by saying cubectl getnodes and we can see we have our onenote kubernetes cluster up and running ready to go so next up what i'm going to do is create a small lightweight linux container and then i'm going to install the helm command line and take it for a spin so to run a small container as a test environment i'm gonna say docker run minus it and i'm gonna mount in my home directory because that's where my cube config file live so i can access my kubernetes cluster and then i'm gonna mount in my working directory which is this entire github repo i'm going to mount it into a folder called slash work i'm going to give it host level networking and i'm going to run a small alpine container now copy this paste it to the terminal and we'll get a small container that we can use next up i'm going to install curl so i can download cubectl and nano which is a lightweight text editor go ahead and run that that'll do the install and now i can install cubectl by saying curl and i can fetch the latest version of cubectl i can give it execution right move it to user local bin so i go ahead and copy this paste it to the terminal and that will download cube ctl for us i also set my default kubernetes editor to nano and to test cluster access i can say cube ctl get nodes and we can see we can now access our cluster so we're good to go so there's a few ways you can go about installing helm but the easiest way i find is go over to the github repo and go to their releases page and then look for the stable version that you want to deploy and you can scroll down and when you go to assets you can see all the binaries to deploy and the binaries for windows and linux are all here so i'm going to go ahead and download the binary for linux and extract it so this is very easy i just say curl and i call the binary i want you can see helm also has a get.helm.sh url and you can ask any version of helm that you want so i go ahead and copy that and that'll download the binary to my local machine once that's downloaded i can run tar and i can extract that binary so i go ahead and extract it now i can also say rm i can remove the zip file because i no longer need it and i can move the helm binary to user local bin and then last but not least i have to give it execution rights as well and we're good to go so now if i type helm and i press enter we can see the helm command line is installed if you need helm cli on windows feel free to download the zip file instead extract it and put the exe on your path so now that we have the helm command line installed let's see what it takes to create our first helm chart now a helm chart is basically a unit of deployment it's made up with a set of yaml files we can have a chart for a micro service or any software like redis mysql prometheus and more a chart has a name it has an information file and it has a template folder that contains all your yaml it also has a values file containing the parameters and values we want to inject into the chart and this can also be the default configuration values so to create a new chart the first thing i'm going to do is change directory into the kubernetes helm folder which is currently empty only containing our readme file so i say cd kubernetes helm and inside this helm directory let's create a temp folder where i can go ahead and craft our first chart so i say make directory temp and change directory so we've got this empty temp folder and to create our first helm chart we're going to run helm create and we're gonna pass in the name of our chart so i say helm create and i call my chart example dash app you can call your chart anything you'd like so when i do this we can see it creates our example app we can look in our tim folder on the left and we see it's created our chart in here in its own folder now if you go to the helm documentation they have documentation around a chart and what a chart is and what it looks like if you scroll down they also have a section on the chart file structure of what makes up a charts and if we take a look at the left here we can see a similar folder structure as what they're describing over here so firstly we have this empty folder called charts and that folder allows us to embed more charts that this chart may depend on so if you want to nest charts that allows you to do so then we have a templates directory inside of the chart folder which is basically all the yaml you would like to bundle up to form a chart and this can be your existing microservice yaml that you have currently it can also be yaml that you've downloaded off the internet you can craft your own chart by adding the yaml inside the templates folder and then we have the chart.yaml and if you look to the side here this is the yaml file containing information about our chart so things like chart name version number description and information that tells us what the chart is meant to do and then we have values.yaml this is basically the default configuration values for this chart so the values file is where we can inject parameters we can basically store stuff like overriding the image tag we can add labels and we can override the existing chart to make our chart generic now the values file that you see here would be the default configuration but it allows us to create multiple values files so you can have a values file per microservice or application so you could have like values.dev.yaml values.prod.yaml it's entirely up to you so once you've created your first chart with the helm create command feel free to browse and explore the templates folder to see what examples there are helm deploys a default application in the templates directory with a couple of examples of what you can do so to convert this into a helm chart that we can actually use let's go ahead and clean up the stuff that we don't need so the charts folder is empty so that's okay in the templates folder i'm going to go ahead and delete the test directory i'm going to delete everything in this folder except for the helpers template file so i go ahead and clean that templates folder up so if we take a look at the chart.yaml we have the name of the chart a description we have the type as application we can give it a version and we can put version of the application that we want to deploy as well so our chart can have a version number as well as the underlying application you're deploying something like redis or something you can give the right version down here and if we take a look at the values it comes pre-filled with some existing value so what i'm going to do is i'm just going to ctrl a select everything i'm going to clean this file up so we can use it so just to recap i said helm create created a basic chart deleted everything i don't need so we have an empty subcharts folder we have a templates folder with just a helper template inside here we have helm ignore we have char.yaml and values.yaml now converting a pre-existing application into a helm chart is pretty straightforward now that we have an empty chart all we need to do is take our existing yaml and copy paste it into this templates directory and we can use it as is so we simply have to take our existing yaml that we have and this can be your existing yaml or your applications or microservices and copy it into the templates directory of the chart so i have examples here in my documentation i'm going to go over to the kubernetes folder i have a deployments folder with a deployment.yaml i'm simply going to right click this guy i'm going to copy it and i'm going to copy him to my templates directory so now i have my deployment.yaml inside of the templates folder i also know my application needs a secret and a config map so i'm going to go to config maps take the configmap.yaml copy that go to the templates directory and paste it there i'm going to go to the secrets take the secret.yaml copy that go to the templates directory paste that in as well and finally i'm going to do the same thing with services i'm going to copy the services yaml go to the templates folder and paste it there so now i have a helm chart with a deployment a config map a secret and a service so what makes it really easy to start off with is we don't need to change any of our yaml we can simply lift and shift it into a templates directory and create our first chart so once you've created your first chart the first thing you'd want to do is test whether it renders correctly so to do that we can simply run the helm template command and that command takes in a name of a chart and the chart directory as well so if i say ls we can see we have our chart directory here so i can say helm template the name of my chart which is called example app and the name of the chart folder which is also called exampleapp i can copy paste this to the terminal and we can see helm generates all the yaml so we can see it's created a secret yaml it's created a config map yaml created our service yaml as well as our deployment yaml so the helm template command is a really powerful command that allows us to test our template by spitting out the raw kubernetes yaml so we can make sure it's okay if there's anything wrong with the yaml file the helm template command would render an error so now that we have our very first basic helm chart let's see what helm allows us to do with it so to go ahead and install our chart we can simply say helm install and then we pass in the name of our chart and the folder where the chart is located so if i run that command helm will go ahead and install everything that's part of that chart into our kubernetes cluster we can see here that it deploys to the default namespace this is the revision number and the dates of the deployment i can then go ahead and list the releases every time you deploy a helm chart helm will create a release where it tracks the revision so i say helm list and we can see we have our name of our helm chart the namespace we deployed it to the revision number the updated date and the status we can also see things like the app version and the chart name and version and we can get a full list of everything that's been deployed so if i say cube ctl get all we can see we have two example deployment applications we have our kubernetes service we have our deployment and i can say cube ctl get cm to get the config map we can see that exists and we can make sure our secret is deployed by saying cube ctl get secret and we can see it's been deployed and created so at the moment our helm chart is very basic and it's not really reusable since we're not injecting any values and if you have a cicd system you might want to inject like a build number and rotate the docker image tag and you'll remember earlier that i spoke about the concept of a values file as well as parameters so the values file and the parameter injection allows us to inject values into our chart making it reusable so let's inject the name of the docker image and the tag into our yaml file with this concept you can structure your yaml file any way you like so one example is we can simply take the deployment image and tag and add it to our values file and then inject that into our chart so in our chart i have the kubernetes folder in the helm in this temp directory uh we have our helm chart and inside there we have the values.gamil which is currently empty so let's go ahead and add some fields to this values file so what something that i can do is i can say deployment and under the deployment i can have an image with my image name as well as a tag with the tag of the image so the values file is where i can put anything that i want to override in the chart and to inject that into the chart what i need to do is go over to my deployment.gaml and add this style of syntax so you can see there's a templating syntax that we can use so i go over to my chart in the templates folder i have a deployment.yaml and when i open this deployment.yaml we can look for the values that we want to replace in this case i want to replace the image that i've hard coded here so one thing we want to replace is the actual image name so this image name we want to replace so what i can do is grab this portion over here and that will replace the image name so we use the syntax dot values dot values.deployment.image and then we can replace the tag like so so we can replace this 1.0.4 with the actual values syntax so this is the syntax that helm uses which is basically go templating so now instead of hard coding the image name and tag in our chart we now allow the user to override it at the time of deployment so to show you how to inject your custom values file we can basically say helm upgrade so let's upgrade our release so i say helm upgrade the name of the chart as well as the folder of the chart so this is exactly the same as the helm install command and then i pass the values using the dash dash values flag and i pass the path of the values file so when i run this in the terminal helm will go and upgrade our release so we can see now we have our name of our release the deployment date the namespace the status and the revision which is now two and to see the revision i can say helm list and we can see the revision over here if you don't want to use a values file and you simply want to override one or two values over the command line you can also use the sets flag so you can say helm upgrade the name of the chart the chart location and you can say dash dash set and here you can see i've set deployment.tag to 1.0.4 that basically allows me to set this value automatically when i pass it in over the command line instead of using a values file so that's another option so you can use this templating engine and notations to replace pretty much anything you like making your chart more generic for example you can create a chart to allow your teams to deploy their microservices and share the same chart among many services if you create like some form of generic microservice chart or if you want to deploy more complex software like redis or rabbitmq clusters you may want to create a gold stamp vetted pump chart for your organization that you can use to roll out this type of software so let's go ahead and make our helm chart even more generic so one thing we can do to make our charts a little bit more generic and reusable is to inject a custom name for all the objects in the yaml file so as an example here we can go through all these objects and we can insert values.name as the name of each of the objects this will make sure that none of the objects clash and every time we want to deploy the chart we can supply a specific values file for that application so to show you an example i'm going to go to my values file and i'm going to add a name to this values file so you can see i have name and this is the name of my application that i want to deploy so this could be the name of the microservice and then what i can do is i can go to mydeployment.yaml and i can go ahead and find replace all the names and replace it so firstly i don't want to call it example deploy i'll do something like this so i say values.name as the name of the deployment and then i'll go ahead and replace all of these names so i'll hover over that i'll say find and replace it with that so we'll replace the label we'll replace the selector we'll replace the label of that guy we'll replace the container name and that's done and we'll do the same for secrets and config so let's go to the config map replace this name with a more generic name replace this name with our values go over to secret we'll do the same thing over there we'll go to service and we'll replace the name as well with this guy and we'll change the labels as well as the selector go ahead and save so now that our helm chart is super generic we can deploy multiple instances using this chart so i can go to my values file i can create a copy of it and i can rename this copy to exampleapp-2.values.yaml and in this yaml i can give this guy a different name so i can create another service with another docker image name and tag and call this one example app2 and then to reuse that chart and deploy example app 2 of our application i can say helm install example app 2 and pointer to that same chart and i can apply the values file of example app2.yaml and when i run that we can see that we've now created a new release called example app2 and it's on revision 1. we can say helm list and we should see two applications deployed side by side so these two applications are deployed with the same chart if i do cube ctl git deploy we can see we have two applications deployed and the same thing with service i have two services deployed i also have now example app two as a secret and i have the config map for example app2 so you can see this makes our chart super generic we can reuse it across multiple applications i can take this even further by creating another copy of this yaml file and this time calling it example app3 i can change the value to 3 and then i can say helm install example app 3 using the example app chart pass in the values file for example app 3 and we can see we now have a new release for that guy and if i say helm list we can see we now have example app 1 2 and three so as you can see helm has really powerful template generation capability and another feature to showcase the power of this capability is to automatically roll out new pods when a config map changes by default in kubernetes when a config map changes pods are not automatically restarted and some applications might need a restart to pick up the new config files so when a config map changes with a new config file value the pods and kubernetes won't automatically restart to pick up this config we can use helm's powerful template generation capability to overcome this issue and it allows us to forcefully roll new pods when a config map changes now when we change a config map what we can do with the template generation is we can trigger a change on the deployment that'll tell kubernetes to forcefully roll out new pods and they'll pick up the new config map so to make kubernetes roll out new pods we have to trigger a change on the deployment and to do so we need to detect a change on a config map so what we can do if we take a look at this example we can update an annotation on our deployment object and part of this we can basically add an annotation that creates a checksum value of the configmap.yaml so whenever the config map changes the encoding of this statement will be different so you can see we basically use an include function and we print the contents of the script and we pipe it to a checksum function so every time the config map changes this checksum function result will be different so it will basically create a unique annotation on this deployment which will forcefully trigger a change in kubernetes so to do this change i can go over to my templates folder go to my deployment.yaml and we go to the deployment spec template metadata and we add an annotations field to the metadata and under annotations we add this guide so we add the checksum config and we do this function so to keep my values file consistent with the others i'm just going to rename it and i'm just going to call it example app dash one dot value so to trigger that change we're gonna say helm upgrade the name of our application name of the chart file we're gonna pass in our values file for app one and that'll go ahead and roll a new deployment and when i do cube ctrl get pods really quickly we can see the old pods are now terminating and new pods have started up now for more complex style template generation helm also allows us to do control flow so we can have f and else statements to generate more complex yaml based on the values we pass in and it also allows us to set defaults so let's say we want to enforce things like cpu and memory requests and limits we can do things like allow the user to set their own resource requests and limits or fall back to defaults if they are not supplied or we can allow users to simply set requests but not limits that's entirely up to us to allow this capability we can use if and else statements in helm which are really straightforward so to demonstrate helm chart control flows i've got this basic resource requests and limits using if statements so you can see i have a bunch of if and else statements here to demonstrate control flows and helm and you can use this with anything in this example let's see what i've done so in this example we want to set some resource requests and limits if the user have supplied them otherwise default them so you can see what i do is i say if values.deployment contains resources start generating the resource block if the values.deployment.resource.request is supplied start generating the request block and then i can add values for memory and cpu and what i can do is if the user has supplied deployment resource request memory then use that value otherwise defaulted to 50 megabytes and also ensure that there's quotes around it so we can use the quote function to do so the same thing for cpu i can say if the cpu request values have been supplied i can use them otherwise default to 10 millicourse and then i can also enforce quotes around that too if the user has not supplied any request blocks we can have an else statement generating a request block for them so this would generate just a basic request for memory and cpu and then in here i show you the exact same example but this time using resource limits so if the user supplies limits for memory and cpu we go ahead and use them otherwise we default and we ensure there's quotes around them if the user hasn't supplied any blocks for this we go ahead and we set the entire block if the user has completely left out the resources block we can go ahead and generate a default block for them so this allows the user granular capability to override requests and maybe not limit or overwrite everything or leave it blank and this demonstrates how you can use if-else statements within your held chart so to use this i can go ahead and grab this yaml over here and i can go to mydeployment.yaml and i can replace this resource request and limits block that i have here with the actual values that i paste in now be very careful with yaml when you paste you can see my text editor here has injected spaces automatically so you've got to be very aware of line indentations when working with yaml which is the pane of yaml files if i go ahead and hover over that i just need to make sure that i move it so the indentation is correct i then go ahead and roll out this change saying helm upgrade name of the application and chart file and then i pass in the values for application 1 dot values and when i do this we can see revision 6 has now been rolled out and we can see our old application is terminating and the new one has started up and if i do cube ctl get deploy for that deployment that i've just created we can see our resource requests and limits have already been set and this is because i did not supply it in my values file so the helm template generation has created the defaults for us so that's the basic of helm templating but be sure to check out the helm documentation for more advanced template functions and pipelines so hopefully this was a useful and subtle introduction to helm and helm charts if you're looking for an alternative to helm that's maybe a little bit less complex be sure to check out my link below to my customize video customize is an alternative to helm which allows you to do very similar things and let me know in the comments below what sort of videos and topics you'd like me to cover in the future and remember to like and subscribe and hit the bell and also check out the link below in the description to my community page and if you want to support the channel even further be sure to click the join button down below and become a member and as always thanks for watching and until next time [Music] peace

Channel: That DevOps Guy

Views: 38,444

Rating: 4.9786811 out of 5

Keywords: devops, infrastructure, code, aks, kubernetes, k8s, cloud, training, course, cloudnative, github, development, deployment, containers, docker, amazon, web, services, helm, tutorial, beginners, guide

Id: 5_J7RWLLVeQ

Length: 27min 32sec (1652 seconds)

Published: Tue Nov 24 2020