Implementation and evaluation of custom schedulers in the Kubernetes cluster

Octobor 2023- February 2024

• In this project, I have worked on scheduling algorithms and the way resources are being provisioned on Kubernetes clusters.
• Approximately, I have worked on this topic for about 4 months, from Octobor 2023 to February 2024, under the supervision of Dr. Zali.
• I have gained hands-on experience working with different tools in DevOps and cloud computing areas. I have learned the Kubernetes concepts and architecture, which is the most popular container orchestration platform. I have also learned Docker and microservice concepts.
• In Kubernetes, the smallest computational unit is Pod. Kubernetes has a worker-slave architecture. So it has one master and several workers. When users or system admins want to deploy an application inside the cluster, there is a process which is called scheduling, that begins to manage the process of deploying these pods on the best nodes it can find.
• This process is handled by the kube-scheduler component in the master node. We can deploy our scheduler to Kubernetes and change the configurations and algorithms of how this default scheduler works on Kubernetes.
• As a result, in my project, I created a new scheduler plugin that scores nodes based on their current network traffic and available memory.
• So, the more the network traffic is on a node, the lower its score will be and the higher the available memory, the higher the node’s score will be. I have implemented and evaluated my solution on different Kubernetes clusters.
• I used two popular ways of creating my clusters. The first one is using the Vagrant file which is an infrastructure as a code solution. It means we write all the configurations and requirements of our desired cluster, like having 3GB of RAM and 2 virtual CPUs, and then we can create our cluster with virtual machines.
• The second way is through a kind cluster. Kind is a lightweight cluster that uses containers as nodes instead of creating actual virtual machines.
• I evaluated my new schedulers on these two clusters and tested two different scenarios.
• When we have a server-based application that generates lots of traffic, the default scheduler in Kubernetes, which does not consider network metrics, deploys this server on a node that might have the highest network traffic on it. Whereas, my scheduler will choose the node with the lowest network traffic.
• The results for the second scheduler which scores nodes based on their available memory were also interesting. The default scheduler in Kubernetes only considers the resource request written in the specification of pods and doesn’t consider the real-time available memory of nodes. My custom scheduler could collect the real-time available memory and score nodes based on these data.
• This situation matters especially when we are providing services and servers to our users and the accessibility and availability of our app to the end-users have a high priority to use.
• Furthermore, I am working on my scheduler to consider more metrics in addition to network and memory metrics. In more detail, I want to create an optimization problem for my scheduler which chooses the best metric in a combination of metrics.
• Poster Link