Deployment Strategies in Kubernetes | #1 | K8s Primer | Tech Primers

in the last few videos we saw how to understand kubernetes with an architectural diagram and we saw what is a service what is a deployment we created a load balancer as a part of the service we deployed different instances of a Springwood application and we saw how to create these as a part of a llaman which we can generate out of the box in this video we are going to see the different deployment strategies inside kubernetes and we're gonna try two of them as a part of this particular video so we are going to use the kubernetes engine inside the Google cloud platform in order to apply these out let's get started [Music] press the bell icon on the YouTube app and never miss any updates from tech Shamus so I am presently logged and inside my Google cloud platform account this is a free tire account nothing complex it is just a free tire account which I created which you would have seen from the last few videos as well what I will do is I will create the cluster before we discuss what are the different deployment strategies so that we will allow Google cloud some time to create this particular cluster so the cluster name which I am going to give is tech primer cluster 1 this is the same cluster name which we have been creating right from the first few videos and I'm going to create three different nodes in the cluster so by default it provides a three node cluster with the standard cluster Edition but if you want to have only one node cluster you can still go ahead and create it so I am going to click on the create option and let's jump onto the presentation which I have created so this is the general diagram which we have been seeing in the last few videos right so this is the coconut is architecture where we see a master running master controlls the complete cluster and the deployments the green boxes are the deployments where our applications are running so we created a spring boot application Rob dump it into a docker image and we push that into a container registry which is the Google container registry it is similar to a maven repository where we host all our artifacts and while deploying into kubernetes kubernetes will directly pick these images from the container registry and kubernetes leverages them so the green boxes are the deployments where our Springwood application is running the orange one is the service so inside command is the application processes which are running inside the pods are called as deployments and the service is a intermediary layer using which you can communicate with these spots so service is basically a rust object where you can have the load balancers dns and the node ports enabled in them so this is the general architecture which we discussed in the previous videos let's simplify this and let look at the important components inside this cluster so that we can remove the unnecessary parts which we already understood so this is how it looks like right so we you have a service you have different deployments these deployments are basically same instances of applications running inside the cluster and services where you will be exposed with the external IP address or a DNS name using which you can interact with these parts or the deployments if you remember the last video where we deployed a spring boot application we created three replicas sets basically three instances of the same application running and people leveraging the service as a load balancer and we were interacting with these parts using this service we are going to take the same example and the same spring boot application how old we are going to see the different deployment strategies so last time we just created an application and deployed but we are going to update the application with a new version as a part of this deployment strategies so there are four different deployment strategies these are concepts some concepts are supported by kubernetes out of a box for example recreate and rolling update or something which cover notice provides in the platform out-of-the-box and blue green and canary two plans can be done using the about two so as a part of this particular video we will see if we create and rolling update which forms a basis for the blue green and the canary deployment so as a part of recreate we will be destroying all the instances which we have the point and we leave Li creating new instances so as the name suggests it's finally going to recreate your instances this is mostly used when you don't want to add additional headache by creating new pods because every time you create a new pod you will be charged for it right so you don't have to worry about that when you want to do a recreate so these are useful when you want to have development environments or applications and you don't want to worry about the resiliency of the application and you are just okay with destroying and recreating them that's when you will go for a recreate deployment strategy let's try doing this inside the cluster let's check out if the cluster is created and I can see the clusters up and running so there are three cluster nodes inside this and as usual I am going to open the cloud shell using the cloud shell I'm going to interact with the communities cluster I'm not going to use my command-line interface to log into the GCP so I'm leveraging the cloud shell meanwhile let's go back to the Google cloud platform and go to the Container registry to check if our images are present there so I built these images a week ago as a part of the last video we have the images here so it is inside GCR IO my project ID the spring boot and there are two versions v1 and v2 so you can also leverage the same image I'm also going to do the same and I have made this public so that you can directly connect it so let's look at the cube Doty Ammal which we created last time so the cloud shell is logged in I'll go into the spring bootie example which I already checked out here so I'm just one less I created a file called cube Toriyama last time if you remember and this is the kubernetes yeah Mel configuration for the point inside the cluster so the first part is the deployment the second part is the service in this video anyway we are not going to touch the service part because we are going to keep the services however you're going to change the deployment see that there is a v2 which we deployed last time now as a part of the deployment we are going to deploy a v1 because there is nothing in the cluster right now so we will deploy a v1 as is to understand how we can do the recreate strategy so there is again a configuration so if you look at this particular website this is nothing but the commander's documentation on the Yama definition and I'm going to go to the V 1 beta 1 which is what we are using if you look at this we are using the extensions v1 beta 1 I'm using the same I'll go to deployment inside the deployment there is something called as aspect suspec has again linked to other documentation and this has different options for example replicas selector template so we are right now using the replicas and the template and there's something called strategy here is nothing but the deployment strategy which we would like to use as a part of her cover notice part creation so the deployment strategies which we saw the recreate and the rolling update these are the pod creation techniques or the deployment strategies inside kubernetes now let's go and add the strategy so there is this new spec called strategy so we are going to do that so we'll just say strategy and we have four replica sets basically there will be four instances of the application running so if you look at this diagram we had only three here but we are going to use the fourth one as well so there will be four instances of the same application running inside the cluster now coming back to the documentation let's go inside the strategy again strategy has a sub list of things which you have to define and there's something called pipe and the type says type of deployment can be recreate or rolling update so if you related to this these other ones so it can be either recreate or rolling a bit and by default it is rolling update but we are going to use the recreate first alright so let's go back to the strategy under the strategy you will have to go to type and the type is recreate so I am going to add recreate that's it so that is what I wanted right so let me go back to the going yes and there is one more property controlling update that people have to provide only if the deployment strategy type is rolling update which we are not bother about right now because we are going to use the recreate option and that's it right so I just saved this and we are deploying v1 right so we are the point b1 right now so let me clear these since this is the first time I am deploying and logging in I need to login to my cluster so I'll use the G cloud come on so I will take it from the confluence retreated last time so I'll use the same G cloud containers cluster which is the same command to login to my cluster right now right so this will log into my cluster because I created the cluster before I launch the cloud shield so I'm walking off let's see what all things are running cubes ETL get pods keep city and get services nothing cube CD and get deployments so these are the ones which are running there is nothing right no resources found on everything and there's only a cluster IP which is present so let me do a player again now let's deploy the application so we are going to say cube CTL apply hyphen F and the cube dot Jung which we modified right now so this will deploy our application to four different plots the kubernetes now say is created and let's go and check if it is up and running I already see all these up and running let's go and see what are the different services there should be one called load balancer yeah the load balancer is up however the external IP is getting registered with the Google cloud platform so that we can access it right so this is by default linked with eg CP so that we can access it outside the cluster let's try and say cubes if you get deployment and there's only one deployment called the spring boot example and that is what we are using right now let's check if the services got created so that we can hit the rest endpoint and access it yeah it's got created I will copy this name it so the Springwood application is up and i have an endpoint called lazy which you would have seen in the last example right this is v1 so v1 has something called hello YouTube and v2 has something called hello tech primers so these are the two versions which are there inside the container registry I'm going to use these so that I can show different deployment since this is the first time we deployed we do not see any deployment strategy because it did not destroy anything which was already present now in order to apply the new change we need to add the new image right so let me open the cube dot yml we need to update this particular image [Music] so we were using v1 and right now we are using a different version of the same image so in order to upgrade our application it is the same command cube CTL apply hyphen F and cube dot gamma so this is what I am running cube CTL apply hyphen F cube document so we just upgrading it right so it and commanders will be intelligent enough to identify what's happening so let's do the cube CTF get parts and see that it's terminating all the parts and now there are four pods running right when we last time saw and see that everything is getting destroyed on creating see that now it's all running so if you compare to what we discussed so we said there were deployments before and as a part of theory create it first destroys all the running deployments and then recreates them so that's what happened has well when we did a cube city of pod there was only one part which said terminating the other parts already got terminated and when we sent QB CTL pods again we see all the four running and if I hit the same restraint point it should work and it returns hello tech primers so this is the new version which we deployed and it works perfectly as expected this is how we can do a recreate strategy inside kubernetes now let's look at what is the rolling update rolling update is when you want to deploy a new version of your deployment without having any downtime to your application so we will be deploying a new version of this particular deployment a new pod will be created and once the new part is up and running and it is ready to be soaked the old one will be destroyed that's how rolling update happens once a pod is good the same thing happens for all replicate instance inside the deployment so this is how a rolling update is done so I'll just summarize once again so when we deploy a new instance of the application a new part will be created and the existing part will be destroyed after the new part is up and ready to be sold and this happens for every replica set so it doesn't destroy anything directly it just creates a new instance and once a new instance is up and running the link gets changed new instant and then the old instance gets destroyed that's how a rolling update happens now let's try doing a rolling update inside our cluster so we already have four instances running so let me open the cube Toriyama again here we added the strategy type as recreate now we have to add the strategy type as rolling update so we can go to the documentation and see what is the value rolling update you camps update and we need to add one more section called as rolling update so let's add it and under that obviously it is again our list under this there is something called max unavailable the maximum number of parts that can be unavailable during the deployment so I don't want anything to be going down I will say as zero you can have zero this make sure that nothing goes down so new mode will be created and the existing part will be retained however if let's say you want to have a resource constraint and you want to reuse an existing part then if you make one as unavailable that that basically destroys the part similar to how we did the recreate however only a subset will be impacted so in my case I don't want to have any node any downtime so I want to have a no time kind deployment so I just say zero and Max urges the maximum number of parts that can be scheduled above the desired number of parts basically how many instances of the new parts can be created so we already have four I don't want to have more than one so I'll just say max so just one so this will make sure that utter time that can be only five pots running so that's what we are going to do so let me save this and let's try deploying it now already we deployed v2 in the new case I'm going to deploy a v1 back again I don't want to deploy a v3 but let me revert it back because last time and we deployed we had the hello tech primers right now if Ida for the v1 it should return hello YouTube now let me avoid cube CTN apply - f cubed or Yama now let's do the cube city I'll get pods this will now show that each and every part is getting created one by one so see that now we have like 4 plus 3 plus 3 6 because 1 is getting destroyed and 1 is getting created and see that this is happening one by one see that now there are only four pods running at a time all right now let me go back to this URL and hit it should say hello YouTube yeah I can see this is returning hello YouTube now I don't know how this happened so this happened very quickly because I couldn't even see how it happened so now what I'm going to do is I'm going to add some delay for the Cuban artists cluster to validate if it is up or not so right now by default it is making sure my cluster is up and running so there is a section inside template where we can leverage that particular property to say check my new pod after a particular period of time so let's look at that particular property let me go to the template section here let's go to deployment under deployment there is a SPECT under the spec there should be a template so under the template there is something called spec so inside the spec we have something called containers right so where is it so inside the spec we have containers for a specific container I can delay the health check endpoint and I can also give the head second point so right now it's not having a health check endpoint so what's happening is kubernetes creates a part and immediately as I means it but I'd want to make sure my application is up and then only it should validate right so let me go to containers and inside containers there are different arguments right so let's go to something called as the readiness Pro this is a property using which you can identify whether the application inside that particular pod is up or not so let's add this particular property so here I am going to add the readiness probe and the containers so I'll paste it so under the readiness book probe again it is a list right so if I click on the v1 register probe so there is something called HTTP GET HTTP GET will have to be the health check endpoint or the URL with this guy needs to validate so in in our case our health check end point will be slash lazy right because we have an endpoint called slash lazy right so the kubernetes instance will hit that particular endpoint to check whether our application is up or not so again if you see internationally picket there is an equal path and then the port I think we have to add it inside the path not inside the HTTP GET similar to say and then there is a port so by default our port is the 8080 so I am going to use the same port 8080 so average should EP request has been added now let's come back to the container section so inside the probe section we need a delay so she which is what we wanted right we wanted an initial delay so that we can check how it is going so I am going to add an initial delay of like let's say five seconds so that we can see what's happening inside the cluster so there is something on timeout the number of seconds after which the probes times out but by default it's one second so I'm not going to have any timeout right now but there's something called periods so periods is that how often you need to perform the probe by default is 10 second and then we can have like let's say 5 seconds right so we can have a period of let's say 5 seconds now coming back there is something called success they're shown the minimum consecutive success for the probe to be considered successful default by default it is one so I am going to retain the same like so I'm not going to add any success criteria so I have modified my probe container details saying okay this is my health and point this is my port and these are the delays which I want to introduce so that I can go and check right so this is basically the health second point and it is going to delay after every 5 seconds so let's try what is the question right now it's version one again we need a product apply a new one right so let me go to version two so I need to deploy a new version of the application so that I can check right how the deployment happens now I have created a script in this tab I have created a script called Coldwater search right let me open the color of the search so this is going to indefinitely hold my URL so this is my you are no external IP address is different so what this will do is this will indefinitely pull this particular URL to check if there is any downtime so we are going to see that so that is to make sure that we don't have any downtime right because I want to show you that there is no downtime for this application so this is going to indefinitely hit their end point every one second so we will see what's happening so such cold water search this is going to indirectly hole mindsets in the background see that it's it's polling let's now go to our main one and then main tab and deploy our application so cube CTL apply - f and cube dot yeah Mel so this is going to now deploy the new code which we should have the tech primers hello tech primers right now let's hit it okay so this has some validation error in the cube Yaman let me go I think I might have done some mistakes okay the readiness probe should be under the name I think I missed it here because these all should be under the same name bread for each container so I just missed that now let's apply the deployment and we should be able to see meanwhile I will also type cube CTL get pods yeah this is going to give me the parts and this is going to show me how one by one the pods are getting deployed see that there is only one new pot right now and let me check if there is any down pain no response is all like 200 right to the QC t get pods again see that a new pod got created and it's waiting for five seconds until it hits the hint point and then it's gonna create a new pod in permanent they exist among see that's what is happening once the new pod got created and it's all good the existing one is getting terminated right that's what is happening and see at a time there is one more pod which is up I can see that again the new reprimands are happening and there are two more pods which needs to be created because these are all new parts if you see these two are like completely new these are something which we deploy few minutes back so let's see what's happening I think it's all good right the deployment got completed so everything is all like within one a minute so this is how a rolling update happens a rolling update I just summarized what a rolling update is so rolling update is when you don't want to have a downtime to your application when you want to deploy new instances of your deployments and kubernetes provides rolling update as a strategy inside the configuration itself and how do we do it by deploying a new instance of the deployment and then once the new deployment is successful then we destroy the existing one and that's how we do it for every part this is how a rolling update is created insider kubernetes cluster so I will add this particular quantification file into my coconut as an example so that you guys can take a look at it so it's a existing repo I'll just add these configuration files in the same readme documentation so you can take it from there I hope you guys got an idea of what are the different deployment strategies recreate on the rolling a bit and we saw how we can do that in the kubernetes cluster in the next video we will see how to do blue green and canopy airplanes however we will be reusing these rolling update and recreate as a part of the blue greens and the cannery diplomats as always if you liked the video go ahead and like it if you haven't subscribed to the channel go ahead and subscribe to it meet you again in the next video thank you very much [Music]

Channel: Tech Primers

Views: 11,389

Keywords: techprimers, tech primers, k8s deployment strategies, kubernetes deployment strategies, k8s example strategies, k8s deployment strategy, kubernetes deployment examples, k8s deployment probe, k8s readiness probe example, k8s deployment, understanding k8s deployment, how to deploy in k8s, how to deploy in kubernetes

Id: 4AUnI58ZI6M

Length: 24min 53sec (1493 seconds)

Published: Sun May 12 2019