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...
Saved in:
Main Author: | |
---|---|
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 |
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. |
---|