 We have quite a sleepy audience and then I actually do help in sleeping so one of the things that I really liked about this I need to do anything okay so one of the things that I really liked about this root corp is that there is a rope lying there I'm not really sure why there's a big rope bundle I don't know what they're planning to do with it but I thought that it's nice to point it out. Alright so I'm going to talk about Kubernetes today and we are going to look at deploying deployment strategies some very common deployment strategies a little bit about me I am a systems engineer and DevOps since 2011 and I led systems engineering team at Browserstack before this currently I am running my own system engineering and DevOps consultancy called DevOps Nexus I am a contributor to open source projects including Kubernetes and Fedora project and I have been an author a public starter and speaker at various conferences including root con, Fostom, Flock and Fossasia that being said I actually liked where I told you that I'm going to talk to you about you know deployment strategies that was my ploy to get into the schedule because they were not letting me inside so I thought that if I put deployment they will allow me so that was a very clever way to fool the editors right so what I'm going to do is I'm going to talk about certain concepts of Kubernetes that will help you in deployment they'll help you in designing your own deployment strategies so and by understanding these concepts like you know labels and labels and schedules and all those things I want to learn deployment as a byproduct right before we go ahead we need to have some sort of initial setup I will basically need Kubernetes cluster setup and I need an image with which I will demonstrate how this will work now I'm going to use the nginx image because that's pretty much very common thing to use I request you not to follow the demo right now because that will screw the internet and consequently my demo will not work that nice so please don't you know try to download the nginx image right away so with that I would probably want to introduce you to labels how many of you here are familiar with Kubernetes or at least have heard what Kubernetes is right how many of you have used any cloud provider out there any one of them right quite a few in any cloud provider there's a way to identify resources and the most common way to identify resources is to use something called label or tag depending upon what your cloud provider is calling them right so Kubernetes has some has a similar thing known as labels basically you pick any artifact like a pod or a deployment or a service and then you assign a label to it and then subsequently you can identify that particular resource using that label now we are going to use this to our advantage so basically when we want to do anything of the sort of deployment or routing traffic or whatever we need to make sure that we have right labels in place so I'm going to use a quite a few labels here most common ones I've written down like we have a label for environment for application for service the color label is something which I will talk a bit more about later but yeah that's another label second thing I want you to realize is to imagine how your traffic flows from a client's machine to the service that you want so we start at the very beginning somebody sends a gate request or something like that and it hits the load balancer right now what happens the traffic at the load balancer load balancer basically acts as a central brain it tries to understand that where should I direct this traffic to right and the load balancer or the router or the service that is supposed to find out the resource for which the request is meant and then send the traffic there and then that resource or that particular server is supposed to take care of the processing of the request now this entire thing is quite standard we have all have been doing this if you have worked with any of the cloud provider be it AWS, GCP, Digital Ocean all of them have their own load balancers and or if you have used HAProxy all of them work on and almost the same principle now now that we know we have this key concept in mind that we can actually tweak the routing of our traffic let's now start with the deployment strategy that we want okay so this is the pretty much this is pretty much standard so before I go ahead let me bring up the initial cluster which I'm going to use so I have two machines with me this one if you if you notice this is the Kubernetes master on that side is Kubernetes node okay I'll keep on toggling between two but I'll make sure that the one which I'm writing to is maximized however you can always see that master is written here and node is written there Kubernetes if those who are not familiar it's a very standard client server architecture there is a master which passes which against which you pass commands and there's a node which actually processes the commands in the sense that it is the one which is responsible to run the containers just to get a hang of it let's see I have one node ready with me all right now if you look at the initial setup we have a two-node setup one master and one node and I'm going to use nginx 179 for this demo so I'm going to create a deployment and a service a deployment basically will create the Docker containers on to the node all right and a service is responsible to route the traffic from the from the user to one of these two containers that will be created so let's quickly look at the things that we have here I have a initial deployment with me right so I'm basically starting two replicas of nginx 179 now interesting as a note here is that I have applied certain labels to it there's an app label there's an environment label and there's a color label please ignore the color label for now we'll come to it later but most interesting label here is the environment in the app right now so let's go ahead and create the container and just to make sure that we don't have any residual things running here if I do a Docker PS yeah there's nothing running here so I'll just create the initial deployment it's created let me also show you the service that we have here right so this is my service now if you if you realize that we actually tagged our resource right I'm going to use the same tag environment production and what this service is going to do for me is that it's going to receive the traffic on port 80 and it'll direct it to any resource that has this particular tag to it right so all the pods that I have all the containers that I have with this particular production and blue tag they're going to receive the traffic so I'll just create it quickly when I once I create the service I get a endpoint basically just going to copy this and so I am getting served with in the next 179 here this is my initial setup right now I've not done any deployments this is my you know the first stage now going back to presentation the most common thing that you do once when you start playing with any application or when you want to do an upgrade is to test right before deployment you always test and one of the most common ways to test is to do a canary deployment not canary deployment means that you basically route a very small portion of your traffic to a canary I mean very small portion of a traffic production traffic to something which you want to update to so what we are going to do is we are going to route a part of traffic now can anyone suggest a way to do that like I have we have discussed that there are ways to route our traffic using labels right so can anyone here tell me a very good way to probably route the traffic easily but not the entire traffic only a portion of the traffic to a different machine or to a different container any ideas is it too early in the morning okay too early in the morning I guess then okay so what I'm going to do is I'm going to create another deployment just like I created in genetics 179 deployment but I'm going to make sure that I use the same tags I use the same labels what will happen because of that is the selector which I which my services use if this if the label is same then it's going to route a proportionate amount of traffic to the new set of machine as well right so let's say if you have a cluster of probably 10 or 100 nodes if you just want a canary of one node then have a deployment a single deployment a deployment of single node where you can basically do this is it visible right was the font small good morning I increase the form before coming but I didn't realize that it'll be still smaller is it visible now I'll move it up it is it visible now all right so now what I'm trying to do is I'm basically going to run a canary deployment with one replica now for me it's 33% of my infrastructure because I already have to I'll add one more that's 33% but if you want to do a real canary in production kind of setup then probably make it less than 5% I'm going to update the image I was using engine x1 7 9 now I'm going to make it 1 9 1 thing you need to notice here is that I have I have added a few tags here like type is added but remember the selectors that the service had service had two selectors and that was environment production and color blue service does not care what part it's sending traffic to as long as the selectors and labels match so you should take advantage of that concept and basically route a part of your traffic here before I do that wait let me just show you I'm just going to fire about a thousand requests to see what happens right it's all engine x1 7 9 now I'm going to create the canary right so my canary is created it'll take about a second to get created if I fire the request now I should actually see certain occurrences of 191 right can you observe that in fact we can probably go a bit ahead it's gonna fire the request in background and then put a count that 328 which is approximately 33% of what we were doing right so this will give you a very good way to do canary deployments and test out the release before actually putting it production wide right so this is what we do we just realize that services realize where the labels are and then send the traffic across now once you are done with this the next step is rolling deployment but basically deploying to the entire cluster and that is slightly easier because Kubernetes supports rolling deployment out of box so you don't need to play a lot around with labels and all so I'm just gonna quickly show you that but to show you that to show you the rolling deployment concept I need to upgrade the size of my cluster because right now we just have two or three machines running which might not be very helpful someone just want to increase the size of my cluster to six right now I have a lot of machines running and what I'm gonna do next is just set the image to the newer one that I want all right as soon as I do that the rollout will happen and the rollout is like this so if you look at it not everything is replaced right now right only four of them were replaced first one got replaced now it's trying to terminate some of the older ones so it's it basically rolls to ensure that your your users will not see a downtime not entire cluster will be taken out in one shot it'll be rolled so while your users will not see a downtime you have to understand that there might be some latency issues there so when you actually do this keep that in mind that your users will not see a downtime but might see slightly degraded performance so best is to either increase your cluster size like I did before doing rolling deployment or do it at a time when you know that the customers are you know you have very few customers around so a rolling deployment will not actually hurt their experience rolling deployment actually has a lot more things around which I quickly wanted to show for example if you want to check out the revision history now there is a open bug because of which this is none but what you can do here is that you can actually go ahead and check the revision history by revision number if you do that you'll actually see that there was a previous version with 179 deployed okay and if you think that you know things are not working your way and you want to roll over you want to go to a previous version then that's easy as well because what you need to do is just do a rollout undo and that's going to put you on a previous version so instead of getting 191 here you will get a 179 back okay so that's basically rolling deployment now lastly I want to talk to you about blue green deployment this is this is a different case which doesn't fall into rolling what you do in blue green is that you maintain two sets of separate clusters one is blue one is green that's why I use the labels color if you notice what happens with them is that you say that my traffic is going to go to blue but as soon as you are you want to update you set a new cluster called green and when you're satisfied your tests are done on green you basically route your entire traffic to green now this is also very helpful if you are into immutable architectures where you don't want to you know change what has been done once so in that case you probably create a new cluster do your test on that and just start the traffic so what I'm going to do is I'm going to right now we are on 179 so let me I'm just going to delete the canary you don't need it anymore once I delete the canary I am going to create a green deployment now green is basically 191 so if you look here whenever you hit this you're going to get 179 because that is what the default is right now that's what we that's the blue and that's where our traffic is going so now to get our traffic to the greens green cluster what do we need to do any ideas basically we need to edit our services instead of the instead of selector blue will use the selector green and that should do the trick now Kubernetes give you facility to edit a live artifact so now I'm going to do just that I'm going to edit it live which means that I'm just going to go here these are the selectors that we have been using color environment I'm going to set it to green now and as soon as I save this my traffic will start going to green so there is the mouse all right now if I go here I should see 191 yeah all right so my traffic is now going to the green cluster I can take down the blue cluster as in when the pending requests are served I can do that so with that being said that's all I have on clustering and labels and Kubernetes do you guys have any questions no yeah yeah so while changing the from blue to green as we are humans what if you make a mistake is there a way to handle in Kubernetes like no if you make a mistake then yes your it's generally a bad idea to make them okay what I did here manually is probably something that you should not do manually okay this is done for the demo but ideally you should probably fire command so for example if you notice when I fired when I change the set image to 191 while doing rollout deploy I could have done that using edit also I could have changed it live and it would have if I would have made a mistake it would have failed so using a continuous integration solution like probably Jenkins or something and having those commands in place rather than firing it manually that usually helps and I do not recommend you to while I'm saying that it's possible doing it live I do not certainly recommend doing it like this this is a demo and this is just a way to showcase the features but yes ideally you should use a continuous integration or a system like Jenkins to make these changes or a deployment suit to make these changes that's slightly peculiar because okay what container is basically it's an it's a see is the same process running in a different namespace and you know with its own isolation it doesn't really that's actually an interesting use case I did not realize that happened but have you tried using Java restrictors like xmx and all those things so I was not honoring that as well has to be looked I'm not entirely sure how that will hey my name is Satish suppose actually we have actually deployed here here yes suppose if we deployed actually microservices and multiple containers instead of actually routing actually these microservices they want to talk internally how we can actually make sure that it's not hitting the load balancer so that containers can talk each other in the Kubernetes world you're saying that you want containers to talk to each other without involving any sort of service or load balancer yes I would probably not recommend I will tell you how but I would not recommend that I would want you to use something like Kubernetes services because that is helpful in case you're one of your containers decide to fail on you that being said if you really want to do that pick any overlay network that you like like slannel is very useful in that because in that case I mean you have to pick a overlay as well as you have to pick a DNS add add on because if you pick just the overlay network then you will have to you know memorize IP addresses your applications need to know the IP addresses which is not always advisable because IP addresses change if you pick overlay along with the DNS add on then you just need to know the name and your and the container should be able to hit each other directly so even actually I have a presentation layer which is actually separated from my microservices does it mean actually my presentation will always talk to the load balancing and get the services ideally it should I'm not sure how your system is set up but ideally see load balancer something like service is actually very lightweight it's mostly by default it's based on IP tables so basically you're just routing the traffic using IP tables and it normally works very well with very minimum over it there is I I've never seen a delay of even like 2-3 milliseconds something that doesn't even add a couple of milliseconds is I think a worthy option it if it increase the reliability of your application thank you I can yeah okay cool it it does okay so blue green means that you actually I mean if you talk about the normal the defined the by book definition blue green then you have to have enough capacity that you can run two clusters parallel now I know for most of the organization it's a waste of money for me it's a waste of money if you are on a provider like AWS or Google Cloud or digital ocean or something like that then it's usually not a problem because you basically just pay extra for like nr or something like that whatever the bill you for and that's not a big cost but if you are with the data center provider if you have your own physical hardware that you're managing then it becomes a cost issue and yes then it will be a problem rolling blue green or a hybrid of rolling and blue green that helps but technically speaking that's not exactly blue green because at some point in time your capacity will be compromised when you are basically in the transition state compromise in the sense it'll be reduced when you are in the process of rolling out either you have to reduce the capacity or you have to make sure that both of them that the users are getting served from both of them simultaneously so you have to handle either that situation or reduce capacity situation it's your pick what do you want to handle last question you're very okay right right yes yes yes it can handle it to some extent if you're if you are hitting your CPU then Kubernetes can scale automatically there are auto scalers available which work out of the box inbuilt in Kubernetes that's one way I personally have found it to be limited because it does not cater to all the parameters that I want to auto scale it on so I sometime back for a client I ended up writing a custom solution which will hook to graphite and then scale because scaling is just a command by the there are Kubernetes APIs so you can use the API rest API as well and hit it directly instead of using command line so what I would probably recommend you if you are just looking for very very basic scaling just CPU based scaling then you have Kubernetes auto scaling group you can look at that if you want something more advanced if you have more parameters to consider then you'll have to get a little bit of hands-on with the code and API it's it's not too difficult just have your data shop to graphite or whatever a graphing engine you have where you realize that these minutes are being received or so on and based on that you can call the Kubernetes API to scale up and down whenever you want so usually it's it takes a little time to understand but coding it is it's not very difficult you can do that oh you if you are on if you are on data center then I mean you are not on a cloud provider you're on a data center okay the reason why cloud provider came in picture and gain popularity was because of this because scaling with the hosting product is very difficult and I don't think Kubernetes or any other tool will scale hardware for you for hardware you have to do a capacity planner you know it'll it'll direct the request your application will time out is the standard thing it forget Kubernetes or forget any containerization or anything like that if you have a process running and if you bombard it with if you have a website running if you bombarded the request at some point of time it's going to time out for you or for whatever customers it might be a serving a partial partial number of records but obviously for certain customers it'll time out that's not a Kubernetes thing that's your application there that's your application thing alright so lights are on means that I'm shoot off from the stage okay thank you everyone before we break for our morning a beverage break which is coming up just next I'd like to take a moment to talk about something that we may not think about very often in our jobs we're always very focused on using the computer and technology and DevOps as a as an occupation can be very stressful we sometimes don't stop to think about our own physical health as well and has geek has earlier this year had a conference called kilter where we're thinking about physical health and fitness and today as well we're offering some activities for people who may want to step outside of their brain and more into their body this afternoon at 3 30 in the lawns outside there would be yoga and slack lining for something completely different turn around 180 degrees and and try something else so if that sounds interesting or if you you need to move your body please by all means have a look at that and also this evening we'll be having a talk at the banquet on sleep and its effects on the brain so for anyone who's interested in knowing more about this I encourage you to make sure you don't miss the talk so thanks everyone enjoy your coffee and chai