 Okay, so today we're going to talk about KEDA, as everybody, this is a conference of Kubernetes. We'll be only talking about Kubernetes mostly, right? So I'll not get into what is Kubernetes and all that stuff. We'll just move forward. So I'll just tell you what I'm from. I'm basically a Microsoft MVP and I have an experience of around 12 to 14 years. And then in cloud, it's around 78 years. I've been working in cloud for a very long time. And I have worked from, say, VM to a normal computer engine and then to Kubernetes. Okay, so there's a serverless and Kubernetes. We came into that. So we had a very huge project, which we are where we have run some machine learning workload. We have really two OCR, some of the documents around five rows. So that was very challenging one. If you started using any other serverless entity, there was some problem with timeouts and other scaling problems because even the serverless wasn't helping us and the cost also was a problem there. What we did was we started working on Kubernetes then. That's the first time we started working on Kubernetes and we thought, okay, let's go and check out what we can do with Kubernetes and how we can use the serverless and also the serverless scaling and also have more control over what compute engine it should run on. Because in the case of serverless, you cannot choose the compute, meaning the GPUs and CPUs and the RAM. It is some pre-configured information that comes with that compute and then we only have to use whatever that serverless gives you. So KDA gives you the flexibility to, I mean, Kubernetes gives you the flexibility to run those compute engines and also KDA helps you out and acts as a package manager for you and then Virtual Cubelets will help you to pay only for what you use. So these are the three things which we actually figured out when we were trying to run a huge machine-running workload which when you calculated it was coming around 25 lakhs and then when you used KDA and Elm and Virtual Cubelets, it came around somewhere around three and a half to four lakhs where one lakh went on rating logs. So the logs that are written by the Kubernetes took a lot more than the actual thing. It is because of certain things we did not disable it, so that is why it is there, but still that's something we just learned after spending a lakh. So agenda is basically a simple agenda. We will talk about what is autospelling, we will talk about what is HPA, which is horizontal part autoscaler and why we choose KDA and what is KDA and also the actual Virtual Cubelets and basically the Elm charts and demo. So autoscaler, so basically autoscaler, why we need autoscaler? Cloud by itself is an autoscaling entity. We go to cloud because it can scale a huge amount where we will be able to stop ours. We cannot even stop ourselves sometimes. The scale is so high, a small mistake we make, the screws up the whole building. That is one of the disadvantages of using autoscaler. What is autoscaler is nothing to ability to add computing power to the instance based on the demand. So that's a huge thing. So initially when we started our career, we used to have, we used to send an email whenever the project comes up saying that, you know what, we need this GB of RAM, say 4 GB of RAM and say 20 GB of artist, that's the server we used to use. And then it will take at least for them to procure a long time. Once our clients started using the app, then we need to actually make sure that we have to buy more compute and add more CPUs and RAMs to the already existing server racks. So it used to be a problem because it will always be a problem where we think of giving them more specs and the project might not go that much or we might end up the other way where we will give them enough specs but still the project will be more than what we thought about. Or some bugs in the code that is actually taking more RAMs and GPUs. That also happens. So the autoscaler is a huge gift for us from the cloud where it based on the needed compute power has increased and it's basically a smooth handling. You will not even see the actual compute is being added to the system. There is zero configuration we need to do whenever there is a scaling needs or the traffic is very high. So this is the HPA I want to talk about. So Kubernetes does autoscaling very good, very, very well and it also does every 30 seconds there is some metrics API that goes in and then the replica count can be increased. The parts can be increased, the number of nodes can be increased and all the other details that with respect to CPU, RAM, node these all can be increased based on the demand. The only problem with HPA is if there is a load increase based on the say number of requests or number of say Q that they have added to the system you cannot do it with HPA. Meaning once the CPU or the RAM reaches certain level the node actually increases to say I may add one or more nodes to the Kubernetes. It will not be based on the actual load that is coming in meaning say I am getting a 10,000 request and I want to be very 4C and then push that once I get 10,000 request I want to deploy say 100 parts before even it is getting to 10,000 and 20,000. Only when the actual Kubernetes nodes reaches that 60% say 80% then it will scale to any other metrics that is based on whatever we have configured that is configurable. So we will reduce that to 60 so that we actually see it or once it reaches 20,000 it might become 80 then we will go to one more part. So it is not based on the load that comes in it is based on the CPU and the metrics that is being used. So that is the problem with HPA. How is that problem being solved by Keda? Keda uses the HPA and makes sure that it counts the events and then uses the HPA to increase the number of parts. So basically Keda and HPA works together. The metrics all they need to check the HPA will be added to the Keda's parts. The Keda by itself is one part which acts as checking the events and then the event will be added to the HPA. So the HPA will probably increase the parts based on the load that comes in. So if you see the diagram here so whenever there is a matrix Keda takes care of the matrix using Prometheus and another parts where whenever there is an increase in the load that comes in based on number of requests based on the actual Q that's Q data that comes in or in Kafka or in any other platform there are multiple Keda's or Keda's that supported. There are n number of Kela's that is something like Azure Function Scalar, Apache Scalar, Service Bus Scalar, HTTP Request Scalar. So there are multiple scalars that Keda supports. Once that scalar, once that scalar knows for that particular scalar if there is huge load it will talk to the horizontal part of the scalar to increase the number of parts. So for example I have a IBM MQ, say I have a Rabbit Q and then I know when it reaches 10,000 Q I want to spin 100 more parts. That can be actually configured in Keda. So Keda will take care of that configuration to increase the parts to 10,000. So any system that needs a runtime scaling or even driven scaling you need to use Keda and the Keda will take care of the actual parts that come up. So Keda is basically an even driven auto scalar where the HPA or the horizontal part scalar cannot do because horizontal part scalar takes care only with respect to the matrix of CPU and RAM but if you want to increase the matrix or increase your parts based on any events then you go for Keda. So this is Virtual Cubelet another concept that is you are looking into that basically this is in Azure and any other AWS but I am not sure about the GCP platform. So how it works is this Cubelet is another pluggable architecture which is implemented using Cubelet to connect to Kubernetes for other APIs. So it also uses the HPA and it takes care of increasing the nodes. So Virtual Cubelet is nothing but an abstract layer over the nodes where those nodes are only run whenever there is a need for it. So when you take Kubernetes you would have seen in Kubernetes you need to have at least one master node and then you can add nodes to it based on your needs. You can just keep one node and then based on auto scale you can actually add nodes. The problem with nodes is the CPU metrics it will come down based on some CPU metrics only. So and then you have to pay for that corresponding time the node was up but in case of Virtual Cubelet you don't have to pay for the node you have to pay for the amount of the speakers facing some issues in this network. So we'll be resuming shortly just stay in there and if you have any questions on so whatever has been covered so far please feel free to post it on the chat we'll definitely take it up. Hey, Karthik and you are on mute if you're talking. We can see you. Yeah, it's perfect. You can resume. When it got cut, you have any idea? Okay, not really but yeah I can resume maybe you know I think the audience are eager to hear you so it doesn't matter even if you repeat the content we are happy to hear you. Yeah, probably can start sharing. Okay, so okay I have no idea which side I stopped is it? Not really. Okay, fine. Okay, so I'll go with Virtual Cubelet itself so I was talking about Kubernetes and then I was talking about is there anyone capable of the audience can tell me? Hey guys, yeah you can post it on the chat so if you remember that would be really great. Let's see. Somebody asked half a minute ago, Nagaprasad, what are the required countries when it starts with K, it's just with three nodes. Yeah, when it got stopped, where did you, it got stopped when the virtual node cubelets were previously? Yeah, so Ravi is saying that it's virtual cubelet. I thought virtual cubelet, yeah. That's fine, I didn't lose it. Okay, so I'll just repeat what virtual cubelets are virtual cubelets is nothing but a node you, okay, thanks Sachin. So virtual cubelet is nothing, okay, for example, I have a Kubernetes and then in Kubernetes I'm scaling based on my metrics, CPU metrics and it's going to, if it is 80%, I'll be adding, so I'll be adding one more node, okay, so when I add one more node say it's a one CPU or two CPU node and then I'm using it for one hour and then scaling down because the metrics has come down to 60% or 80%, less than 80%. But I'll be paying for what, one node, one hour and say 4GB RAM rate, but with virtual cubelet rate if I'm going to use, say, scale in virtual cubelet and I have 10 parts say every part takes, say 0.1 so I'll be paying for, not 0.1, 0.01 I'll be paying for only 0.1 nodes and say using 0.1 memory of 1GB of my RAM so I'll be paying only for 1GB of RAM so it is like 0.1 CPU and 1GB of RAM so I'll be paying, say if this node costs 100 bucks, I'll be paying only 10 bucks so it is like huge cost saving, right because most of the time when I scale multiple nodes you will not be using the complete node you'll be using only say 60% or 40% of the node and others might be free based on, at least the last node will be free the last node will be at least 30%, 40% free so we'll actually saving lots of cost and then we'll be actually using the cost for more business value ads so we'll see how virtual cubelet works basically virtual cubelet sits next to the node it will be an abstract layer of node and it has its own containers, operating system, pods, basically a more deployment you do that is almost like a node which sits on the master node and it will call the whenever it needs a node if underlying, right, so underlying in Azure I don't know about other cloud friends basically underlying virtual cubelets basically ACI, it's Azure Container Instance it's basically serverless it's hybrid of serverless and Kubernetes without even having a Kubernetes so basically I can tell you ACI is basically a serverless Kubernetes, virtual cubelet will connect to an ACI and starts pulling those nodes and you'll be paying only for the whatever you actually used so what we thought is until now we saw what is KDA, right basically what KDA is something to scale your Kubernetes based on the workload meaning event rather than the matrix CPU or RAM, okay and then virtual cubelet is nothing but it's basically a cubelet implements the pod and container where you will not be using the complete node or you will not be paying for the complete node you'll be just paying for actual usage of the compute 0.1 compute and say 0.1 GB of RAM so the virtual cubelet will access it Hey Karthik, we don't see your screen if you're sharing Yeah, I am scaring, okay because of the repress I think got imposed Yes, yep, perfect so we saw what is KDA and we saw what is a cubelet and this is Elm chart Elm chart is nothing but a package manager for Kubernetes it's basically on terms of infrastructure as code whenever you want to have your infrastructure as a code Elm is the best way to work in Kubernetes most of the people will be knowing about Elm and all charts and other stuff I'll just touch base the Elm and also talk about KDA also virtual cubelet so you'll have an understanding of what is all about okay, fine let's go for a demo, that's better so you know how to create a Kubernetes, that should be okay I'm just going to show the Azure version of creating Kubernetes it's basically a click of multiple clicks that you need to do what I'm showing this demo is just to make make sure you know so this is all you select some sponsorship and all that group resource group normal things, blah blah stuff you need to do okay, so main concept here is the node pools so whenever you come to node pools you need to enable the virtual nodes if you don't enable this and create Kubernetes you need to run multiple CLIs to see the to get your virtual nodes up guys will have the host joining us shortly I think there are some issues again so just stay with us so yeah, meanwhile I think you can probably bring in your questions, that would be really great okay, so Pavitra how much time do I have? yeah, Karthik and you are good to go, you have 15 more minutes okay, so that's the thing so once the Kubernetes is created probably, yeah so the Kubernetes is created, I'm going to just talk about the code hopefully you can see my code so you can still see my screen, right Pavitra no, it got disconnected fine, so let's go to the chart version okay, so I'll just show you the chart here so this is the YAML file for a brevity purpose I'm going to show the scaled object here and then this is just leave it all alone so it's basically a service deployment and a service secret and a scaled object which you already know about the Helmshark the main point here you have to know is the node selector okay, so you need to make sure that you select a node that is of virtual cubelet to make sure that it runs in the Azure functions okay, let's take a step back so what I have done is I have created a Azure functions which runs on the Kubernetes after dockerizing it, so it's a very simple Azure function where you just pass a queue item and then you should be able to print the queue item okay, so I'm going to run this in the Kubernetes and then show you how it works fine, so once that is done so I'll dockerize that and if you can see here so main thing you need to know is this node selector where you have to make sure that it's basically a type of virtual cubelet and also the toleration and the taint should be on a virtual cubelet whenever there is a virtual place I provide if it exists it should be actually moving your compute to that whatever you know, computation I'll show you I'll show you what I meant so when you see here so in the node right you can see two nodes here okay, so one is the normal master node that you have to any which ways pay for it for default and this virtual node ACI will not be a it's basically an abstract layer it just shows you there is a node but you will not be paying even a single penny it will be just sitting there only when once you run a workload it will work I mean it will actually start spinning the okay let me go and connect in your one of my I'm going to queue up my some data let me queue it up I'm just going to queue this up okay so this is here right so all I have to go and see is I have to see I'm trying to wait for my pods to pick up I have queued one it will take at least the initial part it will take some time so you can see here right so now until now there was no pods zero pods was there now it is actually pulling it now it's creating it it's running in virtual cubelet so you will not be paying any more go check here you can still see the data the first pod takes some time once it gets created it will be extremely faster it surely doesn't take this long I will see okay now it's running so you will pick up so once you start pushing lots of messages it will span across so it keeps on picking up and then the pod gets so this is the same way and we have used virtual cubelet we can see here the virtual cubelet yeah so the virtual cubelet is still there that's based on Linux VM okay you can even create a windows virtual cubelet and then run the same Kubernetes which I've already run so those are the flexibility you have where you can handle one App Engine or one engine that's basically from the Kubernetes so that's the good one to go so that's all from my end the demo is done so what I've done is I've actually created an Elm chart and then I have deployed that into the YAML and I have replaced pushed content into the queue and that is picked by the KDA and then virtual cubelet runs the data and then it has processed it so it's a very simple demo meaning all you need to know understand from this is the event driven architecture platform to increase your compute based on the number of that event comes in because the horizontal pod scale pod scaler does not scale anything based on any other events it will be based on the matrix the KDA helps us to scale it so that we can use the power of HPA to scale our work needs okay I think that's it from my end one thing I want to just add to it is just so this is my basically I'm an architect right so I have written a book that is available in Amazon it's called developers road ahead I'll just give you two minutes overview of what it is so this is my book it's right now available in Amazon so when I wanted to move from my senior developer to architect right I went and asked multiple people there was but there was not one place where people told me okay these are things you need to do become an architect and I did lots of googling to understand spoke to many people but there wasn't one place where it is somebody some people told go and read solid principles some said learn more about design patterns some people said you have to know more about new new technology that comes in but there are certain things which we need to do before even learning new technology or understanding those things and it's basically 30 to 40% technical and other 60% is all communication skill positioning your resume how to talk to your stakeholders how to get convincing your stakeholders to implement new technologies so those are the main things rather than technical because we got after 6 years you almost get very sound with technical things but you don't know which how to make it more sound understand the basics what are the basics you should know so these are the things that comes up came up for me to become an architect so I thought okay I was actually doing I started mentoring multiple people to become an architect and then somebody said why can't you take a seminar out of it so I did a seminar some 60 members came then they asked so is it okay if you can write a book then I realized okay if you write a book more people can learn from it so that is the reason I just wrote this book I don't get much out of this book probably some 80 bucks or something out of the 600 you pay all that things goes otherwise but there is one seller who sells it for 500 that is okay you can check it out if you are interested you can check out that book it's pretty nice make sure that you give me a you can call you can call me you can follow me in the twitter it's Karthik3030 and give me a feedback if you have any details to become an architect on how to become an architect please to contact me I'm in LinkedIn also you just go and search for Karthike in VK you should be able to see me I guess it will be the first name I guess yeah still minus the first name yeah it's in LinkedIn so you can just take out in my LinkedIn profile anything you want any details you want to become an architect or you're struggling to become an architect or understanding how to become an architect please to bring me bring me I'll be happy to help you okay thank you guys for any question I can answer hey thanks a lot Karthik again I think that was really insightful session and we have a couple of questions that we can start with so the first one is how is virtual Cubelet implemented in non-cloud Kubernetes environment okay super it's a very nice question basically you need to run some QBCTL commands so you can run these QBCTL commands to get your virtual Cubelets installed in your Kubernetes these are the commands so I told you right whenever you create a cloud you can either select enable virtual Cubelet or install it later so that's the same thing you have to do it in on-prem but I'm not sure how on-prem will be that much disadvantageable because any which ways you have already bought the so we'll see I mean I don't see a point where virtual Cubelet will be useful in on-prem after testing through yeah yes thanks Karthik again for taking the tab we have one more question can these nodes be distributed across your locations yes yes yes you can do that but it's based on the configuration you need to know you need to do some more configurations in virtual Cubelet and then it is possible okay awesome yeah I think we have covered all the questions that we had and thank you guys for joining and thanks a lot Karthik and for this awesome session for any further questions that you wanted to ask Karthik again you can ping on CNC of Slack channel please feel free to connect me through LinkedIn also any questions you can ask me with respect to Kubernetes or become an architect I am happy to help you that's great Karthik and I think you'll have a lot of people like you so yeah it was such a great session thank you thanks a lot for your time Karthik bye bye alright I think we are done with this session so folks will be resuming the next session shortly so stay tuned so further can I drop right yes yes yeah okay so I just need to because I am not a host anymore yeah you can close the close okay perfect thank you hey all I am hoping that you have enjoyed the session by Karthik and so the next session is going to be on understanding the cube scheduler simulator by Pravar Agarwal and Pravar is a DevOps engineer with six years of experience in cloud automation