Handling of a Pod Restart to Re-scale Its Resource Requests During Vertical Pod Autoscaler in Kubernetes

dc.contributor.advisorDr.-Ing. Frezewd Lemma
dc.contributor.authorMuluken, Mannaye
dc.date.accessioned2025-12-17T10:54:29Z
dc.date.issued2023-02
dc.description.abstractThe cloud computing paradigm is being transformed by container technology. Running containerized applications creates an abstraction layer that handles cluster management from the perspective of a cloud service provider. The dominant container orchestration platforms for providing container-based infrastructure with automatic deployment, scaling, and operation of containers on the underlying cluster are Docker Swarm and Google Kubernetes. Currently, changing container resource requests in Kubernetes requires restarting the pod. This restart can be undesirable for certain stateful applications, as moving or copying existing state information could be expensive or unfeasible depending on the underlying implementation. Service state information may become temporarily inaccessible, and users trying to access the service may encounter non-trivial delays before getting back to expected performance. Also, excessive scaling might generate excessive load on Kubernetes components that are responsible for handling the pod restart. We implemented parameters that can limit the frequency of re-scaling and avoid unnecessary restarts. We think by tuning these parameters, it might be potentially possible to optimize the algorithms for the constraints on re-scaling frequency. We made this study on kubernetes and docker containers followed by proposing a vertical scaling solution that can add or remove compute resources like cpu and memory to the containerized application. For testing, two container deployment scenarios were taken into consideration, one of which ran a single instance of the container and the other of which ran two replicas of the container. Apache Jmeter generates the http workload from a hardware local work area to the web service running on Kubernetes on EC2. When the web server is undergoing load testing and the performance parameters of the application are being watched, vertical scaling is done. In order to visualize latency, throughput, and the number of active threads over time, Apache Jmeter custom plugins were employed. Latency and connect times were the analyzed performance metrics of the containerized application. From the obtained results, it was concluded that vertical scaling has no significant impact on the performance of a containerized application in terms of latency and connect times.en_US
dc.description.sponsorshipASTUen_US
dc.identifier.urihttp://10.240.1.28:4000/handle/123456789/1621
dc.language.isoen_USen_US
dc.publisherASTUen_US
dc.subjectcloud, Docker, Kubernetesen_US
dc.titleHandling of a Pod Restart to Re-scale Its Resource Requests During Vertical Pod Autoscaler in Kubernetesen_US
dc.typeThesisen_US

Files

Original bundle

Now showing 1 - 1 of 1
Loading...
Thumbnail Image
Name:
Muluken Mannaye.pdf
Size:
2.6 MB
Format:
Adobe Portable Document Format

License bundle

Now showing 1 - 1 of 1
Loading...
Thumbnail Image
Name:
license.txt
Size:
1.71 KB
Format:
Plain Text
Description:

Collections