Hello everyone, I'm Karan and today I will be taking you on a journey into the world of serverless. With Kubernetes we will be diving deep into what is serverless, what is knative and how we can leverage this tool to create serverless applications right within a Kubernetes setup. Before getting into what is a native and how we can leverage this tool to create our very own serverless infrastructure. I would first like to cover what is serverless in the first place, but before getting into that we first need to understand what is the with server architecture. In the traditional with server architecture you first have to set up a virtual machine on whatever cloud provider you may be using. Then once that is set up, you have to deal with the configuration of that virtual machine, whether it is fitting your needs and requirements or not. Once that is done, you have to set up your application and not to mention that you have to install all the necessary tools, the configuration required for that application to run. And once it is up and running, your job is not done. You still have to maintain this entire setup. So over time if you start seeing more users using your application, you have to deal with the scaling of this application as well. So these are some of the problems that are associated with the with server architecture and these problems are addressed by the serverless architecture. Contrary to popular belief, serverless is actually a misnomer. So it's not like a server is not involved, it is, but it is involved behind the scenes. So whatever cloud provider you may be using and if they offer any serverless functionality, then basically they are dealing with all the problems that I mentioned in the previous slide. And you as a developer just have to deal with the business logic, the coding aspect of building applications. So that makes it very easy to maintain and scale in the long run. Because you are not dealing with the configuration the cloud provider is dealing with, that you are only dealing with the business aspect of development. These are some of the cloud providers and their serverless offerings. So you have lambda for AWS, cloud functions for GCP, and serverless functions for Versaille and Azure. These are just some of the cloud providers that I wanted to mention. So you are familiar with the offerings that are out there. I'm sure there are a lot more other offerings, but these are just a few that I wanted to mention. All right, so next I wanted to cover some of the basic concepts of kubernetes. I am sure that in this conference a lot of great folks will be covering the introduction to Kubernetes fundamentals of kubernetes the core components and all that jazz. I will not be going deep into the entire Kubernetes architecture. I will just be covering some of the core building blocks that we would be using in the demo part of this talk. So stick around till the end, because towards the end we will be exploring how to use knative and how we can create our very own serverless infrastructure right within a Kubernetes cluster. So just some high level overview for the components or the building blocks that we would be using or working with in the later part of this talk for Kubernetes. So first I would like to cover what is a node. So node is basically a virtual machine. You can think of it as a physical server located somewhere where your applications are hosted and managed by kubernetes. Then next comes the deployment. So deployment is, you can say a configuration that is related to your pods. So it has a lot of things you can configure. I won't be getting too much into that. Then next comes the pod itself. So pod is the smallest unit of abstraction that is created by kubernetes. Basically you can host one or multiple containers within a pod that is related to your application. Then next comes the replica set. This is also managed by the deployment, and replica set is nothing but a unit which ensures that you have n number of pods, whatever you may have defined up and running at all times. Then last but not the least, service. So service is you can think of it as a logical interface which exposes your pods to the outside world. So there are a lot of different types of services which I won't be diving deep into. I'm sure there are a lot of great folks who would be talking about all this in depth in this conference. So I won't be diving deep into that. These are some of the concepts that I wanted to cover so that it's easier for you to keep up with me in the later part of this talk where we would be covering the demo of knative. All right, so it's finally time. We would now be looking at the knative tool. What are some of the features provided by this tool, what are the core components and why? In some cases using this tool may be better for you than using a serverless offering provided by your cloud provider. So yeah, we would be diving deep into what is knative now. So knative is an open source serverless computing platform written in Go for kubernetes. Essentially you can create your very own serverless infrastructure right within your Kubernetes setup and by using this tool, you get the advantage of having the control over the configuration of how your serverless infrastructure should work. So earlier on in this talk, I discussed that why a serverless offering may be beneficial because you don't have to deal with the configuration that is associated with managing an application, you just have to deal with the business logic. But in some cases that may be a disadvantage because you don't have the control over how it works, and sometimes it can get out of hand. So if you want the control over your serverless configuration, this is the tool to go ahead with. So knative has two different offerings for managing modern serverless workloads. One is the serving component and another is the eventing component. So in the scope of this talk, we would only be covering the serving component and not the eventing component. So knative comes with various features. Some of them are first and foremost the scale down to zero, which is the flagship feature of knative. Basically, if your deployment does not have to deal with any messages or requests, then it can scale down to zero, and then again scale back up from zero. If there are any messages later down the line, then next comes yaml based configuration. So similarly, how you define objects in Kubernetes, you can define objects for knative as well using YAmL files itself. Then next comes the rollout strategies. So similar to how you can define different types of rollout strategies for your deployment in Kubernetes, you can define those same rollout strategies for a knative deployment as well. Then last but not the least, easy integration with tools and services. So like service meshes, monitoring tools, tracing tools, logging tools, knative is very easy to integrate with. Knative provides two components to work with in order to create serverless infrastructures. One is serving and another is eventing. In this talk, I will not be covering the eventing aspect of knative, I will only be covering the serving aspect. If you want me to cover eventing in the future, you can let me know and reach out to me through my social media platforms. I will be mentioning those at the end of this talk. So in this talk we will be covering only the serving aspect. So in serving there is a service, there is a revision and a route associated to that service, and a URL that points to that route which allows us to communicate with the service. And revisions are basically a version of your application. So essentially you can have multiple revisions of your application as well if you want. So you can split the traffic between those revisions, let's say 80% to revision one and 20% traffic to revision two. So it is very easy to create sort of an A B test environment with knative as well. All right, so I have covered all the theoretical aspects of knative and now it is time to jump into the demo. Before we do that, I would like to mention some of the prerequisites that are required for this demo. So first is Docker, then the next tool required is kind, which is basically Kubernetes in Docker. And the last tool that is required is the knative client. I'll be going over the installation instructions for the knative client in the demo part for a macOS operating system. But if you are on a different system, I have provided a QR code on the slide right now. So you can scan the QR code. You will be directed to a GitHub repository. In this repository you can find all the files that I would be working within the demo and the instructions associated to the demo. So you can find everything over there and yeah, let's get started. Okay, so we are in the demo part of the talk, I would say the most exciting part and we are inside the terminal, the home for every DevOps engineer. So earlier, as I mentioned, we would need three tools. One is Docker, second is kind, and third is knative client. So I hope you already have Docker and kind installed on your system. I'll be going over how you can install the knative client on Mac operating system. Don't worry if you are on a different system. As I mentioned earlier, the QR code that I provided, if you go to the link provided in that you can get the installation links and those links will direct you to a page where you can install the knative client for your particular operating system. So for Mac you can use the brew command. So brew install knative client kn so I won't be going ahead and running this command because I already have the knative client installed on my system, but we are not done yet. We can also install a quick start plugin that the knative client has offered. So basically in production, if you want to set up knative, you would manually have to install various tools and custom resource definitions for knative to work in your Kubernetes cluster. So we don't have to do that. There is a quick start plugin that we can use and get started with using knative quickly. So again I won't be running this command because I already have the plugin installed. Once both of these commands have successfully executed on your system, you can run the following command which is kn quickstart kind. So I'll go ahead and run this. This is a command that takes a few minutes to complete its execution, so I won't be making you wait for this command to complete. I'll cut straight to where it has finished execution. All right, so it seems like the command has finished its execution and this is the type of output you may also be seeing on your screen if you are following along. So let's go over what this quick start command has done. So first it installed the Kubernetes version 1.25.3. Essentially it installed the entire Kubernetes control plane in a single docker container. Then once kind was installed, the knative serving component was installed, so you can see all the steps related to that. Then next the courier networking layer was installed. So courier is nothing but a lightweight service mesh which was adopted by Knative in the recent years. Service mesh this particular service mesh is used for exposing the service that we would be creating as a serverless application to expose that to the outside world, outside of the Kubernetes network. Then it went ahead and installed the knative eventing component, which we won't be going over in this talk. And yeah, it finished its execution and seems like it has successfully installed knative on our kind cluster. Just to see what cluster has been created by the knative client in the previous command we can run this command kind get clusters. So as you can see it has created this cluster called knative. So usually what I like to do is run the Kubectx command. Basically this just ensures that I am on the correct context. For those of you who aren't familiar with Kubectx, this is a very helpful tool that enables you to switch between different contexts that you may be working with in Kubernetes. So yeah, that's what I did. I just ensured that I am on the correct context. I am sure that the command that we ran earlier, the quick start command, switches to this context, but it never hurts to run the command again. So yeah, now that we are sure we are on the correct context, the first thing that I like to do in order to see what all has been installed in my cluster is to get all the namespaces. So we can do that by kget namespaces. K is just an alias that I have set in my system for the Kubectl command. These are the namespaces present in our kubernetes cluster and I believe default kubernetes, lease cube, public cube system and local path storage are the namespaces that come out of the box with the kind cluster, but these are the three namespaces that I can see which has been installed by the knative client. So eventing, serving and courier system, as I'd mentioned earlier, we would only be going over the serving component. So this is the namespace that I would first like to look at. So the next thing that I'll do is get the resources present in the knative serving namespace. So this command that I ran, kget all namespace, knative serving basically gets all the resources present inside this particular namespace. And as you can see there is a lot of information on the screen. Not to worry, we are just going over what all has been installed in our cluster. So as we can see there are a bunch of pods, bunch of services associated to those pods, deployments for those pods and replica sets. So these are the pods which help knitting manage all the serverless workloads. And you can see that there are a few horizontal pod auto scalers as well. So yeah, these are the resources that have been installed in our Kubernetes cluster and now we can jump into installing our first serverless application. So yeah, let's get into that. All right, so we are in vs code now, this is the id of my preference, and here is a Yaml file that I have named as hello World Yaml. And this is using the API version serving knative dev v one. So this is a custom resource definition that was installed by the knative client which we would be leveraging to create our very first serverless application. So the name for the application would be hello. And here are a few annotations that I have mentioned. I won't be covering this right now, I'll get into this later. Then we have the spec containers image provided for the container, the container port and env variable that we have mentioned with the value world. So as you can see that this Yaml file seems very familiar, right? This is a very similar file that we would be creating for normal Kubernetes applications. So yeah, essentially you create your serverless applications using YAML files itself and it's very similar to Kubernetes. So let's jump back to the terminal and apply this yaml file. Before applying any YAml files, I like to first do a diff on that Yaml file. So we can do that by running k diff hello world Yaml. Yes, so as you can see it is going to be creating a service named hello and it has a few annotations defined. It is creating the image that we had mentioned, and also it is specifying some of the default values that we did not mention in the YAml file, like the readiness probe, the traffic with the latest revision and the percentage split between those revisions. So 100% because we are going to be creating our first revision. As I had mentioned earlier, you have the ability to create multiple revisions in knative and split the traffic between those revisions. So yeah, this file seems good to me. Let's go ahead and apply hello world Yaml. Okay, so it seems like the command ran without any errors. So what we can do next is get the pods in the default namespace. Because we did not specify any namespace, it would be created in the default namespace. As you can see, there is a pod named hello and it is in the running state. So if I run the command again, instead of running it again and again, we can go in the watch mode. So let's wait for a few seconds, and as you can see, it has started terminating the pod. The reason for that is because of the scale to zero functionality provided by knative. So essentially right now this pod is not serving any traffic or any messages. So knative is smart enough to understand that and scale the deployment down to zero. So that is what it is doing. Right now it is terminating the multiple containers. We'll go into that later. As to why there are two containers instead of one, because we specified only one container. We'll get into that later, but for now understand that if I run the command again, there are no resources present, although it was present before. So it has scaled the deployment down to zero. Next command that we can run is the KgetksVC command. Basically KSVC is short for knative service. It is a custom resource definition created by the knative client. And as you can see, this is the service that we created. So hello, it has a URL, and this URL points to the route which points to the revision of our service. So this is a URL that is created by the courier networking layer, basically exposing the knative service from the Kubernetes network outside and exposing it to us on our local network. So if you may know that Kubernetes runs its own network and our local network is different from the Kubernetes network. So this essentially allows us to communicate with the services present in the Kubernetes network. So the knative Quickstart command has set all of this up for us very nicely. We don't have to deal with the configuration. So I'll just copy this link and run a simple curl on this. I got a response. Hello world. If I get the pods again, you can see that there was a deployment, there was a pod created. So essentially what it did was it scaled back from zero to one to serve our request. So this is how the knative serving platform works and this is how the scale to zero functionality works. So the next thing that I would like to go over is how you can load test your serverless application. So there is this neat tool called as hay, and this tool essentially allows you to load test any application for that matter. So this is the command, I will run this. Basically what it is doing is it will load test our application for roughly 10 seconds and it will concurrently try to send 100 requests at a time on the URL, which would be the URL of our service. So the URL that we ran the curl command on, that is what it will be getting through this. And once it has finished its execution, it will run the get pods command. So as we can see, it ran successfully. And these were the pods at the end of this lotus. And this was the report generated by the hay command. So it ran for about 10 seconds roughly. Slowest request was 1.6 seconds, fastest was for this long, average was this much. And in total it was able to run 4390 requests per second. So yeah, the next thing that I will be covering is how we can specify a minimum number of pod for our serverless application in order to avoid the cold start problem. So if you are familiar with this problem, basically what happens is that if there are sudden requests that come into your serverless application, so it takes some time to scale up from zero. So the first request or the first few requests can take some time to be responded to rather than having a consistent experience. So this is a well known problem in the serverless ecosystem and how we can solve this problem using the inative client. We'll look at that by jumping into the vs code id again. So we are back into the vs code id and as you can see this is a different file, minscale Yaml. But it is pretty similar to the hello world Yaml file that we saw earlier with a few differences here I have defined a few more annotations for this particular service. So here we are mentioning a target of ten. Essentially this tells knative that a single pod should be handling ten concurrent requests at a time, then target utilization percentage, so 80%. So if the target utilization of the pod has reached 80%, which would be eight in this case, then scale up to the next pod. So that we can specify. And next is min scale. So min scale we have set to two. So keep a minimum of two pods running at all times. So don't scale down to zero, basically. And next, we have defined a panic window percentage and a panic threshold percentage just in case if things go wrong. So this is how you can customize your knative service. There are a lot more things you can do, and I just wanted to show you how you can customize your serverless application. So let's jump back to the terminal again and apply this new Yaml file before applying any new Yaml file. As always, I like to do a diff on that first. So get the diff. Minscale Yaml. And since we did not change the service name in the new Yaml file as well, we have kept it to hello itself. So it is going to be making changes to the original service that we created through hello World Yaml file. So as you can see, it is only making a few additions, which were the annotations that we had provided in the min scale Yaml file. So everything good looks good to me. Let's go ahead and apply so we can do that. Minscale Yaml seems like the command ran successfully without running into any errors. And we can get the pods now. Kubectl get pods. And as you can see that this is revision two and there are two pods running. Let me tell you that there will always be two pods running at a time because we have set the min scale to two, and essentially it won't scale back down to zero. So now that we have two pods running, I want to do a describe on one particular pod. I'll do it on this pod. I just want to show you as to why we have two containers running for each pod. So one is the container that we created which knative specifies as user container. This is the image that we had mentioned. And if we scroll down a bit, you can see that there is another container called qproxy. So this is a sidecar container that knative installs in every pod so that it can communicate with the outside world. So yes, let's run the load testing command again and see if there are any changes, since we now have minimum of two pods running at all times. So I'll paste the same command that we ran before. Again, it will run for roughly 10 seconds, send about 100 concurrent requests at a time, and send those requests to the service URL that we have created. So yes, it has finished its execution and given us this report. So as you can see, it roughly ran for about 10 seconds. Slowest was this much. You can see that the slowest request time has been reduced drastically because now we have minimum of two pods running. So essentially we have solved the cold start problem and the fastest I believe is about the same average. Also I think got reduced by a bit because of the cold start problem. And average requests per second has also improved. So yes, this was it. These were all the things that I wanted to cover. And yeah, this is the end of the demo and we can now jump back into the slides. All right, so we are towards the end of this talk. Before we conclude, I would like to recap all the things that we covered in this talk. So initially we started off with learning about the with server architecture and the problems associated with it. Next we looked at the serverless architecture and how those problems can be addressed. Next we looked at the conceptual overview of Kubernetes and the building blocks that were required for the demo presented in this talk. Then next we saw what is knative, the features of knative and the components that are provided by knative. And lastly, we jumped into the demo where we saw knative in action and how we can create our very own serverless infrastructure right within our Kubernetes cluster. So yes, these were the points that we covered. Before ending this talk, I would like to mention my social media profiles so that you can reach out to me if you stuck around till this point. I would like to thank you and I hope that you learned something new today. If you want to reach out to me, if you have any questions, if you want to discuss anything related to DevOps or anything related to tech in general, you can do so by reaching out to me through the links provided on the slide here. There are two QR codes. Also I have provided for your convenience. So the first QR code will take you to a page where all of my links would be present, and the second QR code will take you to a GitHub repository where the file that I worked with, instructions, the commands that I karan, installation procedures, everything is mentioned in that GitHub repository. And I would like to thank Conf 42 for having me here and giving me this platform to talk about the things I love. So yes, thank you. Thanks a lot.