HORIZONTAL AND VERTICAL AUTOSCALING SYSTEM ON KUBERNETES WITH VERTICAL SCALING PRIORITY

Scaling on Kubernetes is a feature that could change the resources from an application to fulfill the needs of the application. At this time there are two types of autoscaling, which is horizontally and vertically. Both scaling types are not recommended to be used simultaneously by Kubernetes bec...

Full description

Saved in:
Bibliographic Details
Main Author: Nathaniel Wijaya, Kevin
Format: Final Project
Language:Indonesia
Online Access:https://digilib.itb.ac.id/gdl/view/55955
Tags: Add Tag
No Tags, Be the first to tag this record!
Institution: Institut Teknologi Bandung
Language: Indonesia
Description
Summary:Scaling on Kubernetes is a feature that could change the resources from an application to fulfill the needs of the application. At this time there are two types of autoscaling, which is horizontally and vertically. Both scaling types are not recommended to be used simultaneously by Kubernetes because of the possible race condition that can happen in changing the resource of an application. This paper suggests implementing a system that combines both scaling types to utilize the benefits and reduce the disadvantages. The system implemented combines both scaling types with vertical scaling priority which is using horizontal scaling to handle sudden load and using vertical scaling after a certain interval to reduce overhead and overprovisioning. The system uses CPU and memory metrics from Metrics API for each Pod in a Deployment from Kubernetes to calculate recommendations and update the Deployment in Kubernetes. The system is tested and compared with the available horizontal and vertical scaling provided by Kubernetes with stable load scenario, unstable load scenario, and on-and-off load scenario. The results show that the system can handle an increase in load by horizontal scaling and use vertical scaling to decrease overhead and overprovisioning, seen on the stable load scenario which changes once in a while. The system can ensure the resource usage reach the utilization target by scaling, but have a deficiency when tested by the unstable and on-and-off scenario because of the reactive nature of the recommendation and the scaling interval that needs adjusting. The system is also disruptive because of the limitations of Kubernetes which forces a Pod to be evicted and recreated when the resource is changed.