Proactive automatic up-scaling for Kubernetes
Modern challenges in microservice architecture requires autoscaling (upscaling and down-scaling). As an example Black Friday can be considered when load to system increases significantly and obviously more computing capabilities are need to serve it. Automatic up-scaling can allow devops team work a...
| Main Authors: | , |
|---|---|
| Format: | Article |
| Language: | English |
| Published: |
Igor Sikorsky Kyiv Polytechnic Institute
2023-05-01
|
| Series: | Adaptivni Sistemi Avtomatičnogo Upravlinnâ |
| Subjects: | |
| Online Access: | http://asac.kpi.ua/article/view/278925 |
| _version_ | 1827378582839623680 |
|---|---|
| author | D. Gutman O. Syrota |
| author_facet | D. Gutman O. Syrota |
| author_sort | D. Gutman |
| collection | DOAJ |
| description | Modern challenges in microservice architecture requires autoscaling (upscaling and down-scaling). As an example Black Friday can be considered when load to system increases significantly and obviously more computing capabilities are need to serve it. Automatic up-scaling can allow devops team work as normal even in situations of extreme load to the system. Up-scaling and spinning up of new instance can take a while and make user wait for better system’s performance until new instance is be up and running. That is why up-scaling activities should be started as early as possible. The only solution is to use prediction on load and start up-scaling earlier having prediction of future load trend. In this article automatic up-scaling is for Kubernetes in focus as Kubernetes is defacto a standard for container orchestration. Authors propose solution, providing git-reference to source code. Solution is implemented as Java-based application which uses time-series database (InfluxDB in this case) to understand microservice load. Solution utilizes two prediction models - Exponential Smoothing (ES) and Double Exponential Smoothing (DES). Two models are used to compare with each other. Performance tests are conducted to analyze two main use-cases – use case of slow load growth and case of rapid load growth. Based on experiments it is found that for all cases pro-active up-scaling works better than reactive one. Value from pro-active approach is more visible for case of rapid load growth. If to compare ES and DES between each other, in both cases DES showed better results. Future improvement of the solution could be to make a solution as extension to Kubernetes eco-system for easy plugging-in to Kubernetes infrastructure. Also one of the improvement could be supporting of Prometheus as timeseries database.
Ref. 20, pic. 3, tabl. 2 |
| first_indexed | 2024-03-08T12:59:04Z |
| format | Article |
| id | doaj.art-1e323589892443e7b2dc179cd1c44fa4 |
| institution | Directory Open Access Journal |
| issn | 1560-8956 2522-9575 |
| language | English |
| last_indexed | 2024-03-08T12:59:04Z |
| publishDate | 2023-05-01 |
| publisher | Igor Sikorsky Kyiv Polytechnic Institute |
| record_format | Article |
| series | Adaptivni Sistemi Avtomatičnogo Upravlinnâ |
| spelling | doaj.art-1e323589892443e7b2dc179cd1c44fa42024-01-19T12:06:18ZengIgor Sikorsky Kyiv Polytechnic InstituteAdaptivni Sistemi Avtomatičnogo Upravlinnâ1560-89562522-95752023-05-01142323810.20535/1560-8956.42.2023.278925317121Proactive automatic up-scaling for KubernetesD. Gutman0O. Syrota1Igor Sikorsky Kyiv Polytechnic InstituteIgor Sikorsky Kyiv Polytechnic InstituteModern challenges in microservice architecture requires autoscaling (upscaling and down-scaling). As an example Black Friday can be considered when load to system increases significantly and obviously more computing capabilities are need to serve it. Automatic up-scaling can allow devops team work as normal even in situations of extreme load to the system. Up-scaling and spinning up of new instance can take a while and make user wait for better system’s performance until new instance is be up and running. That is why up-scaling activities should be started as early as possible. The only solution is to use prediction on load and start up-scaling earlier having prediction of future load trend. In this article automatic up-scaling is for Kubernetes in focus as Kubernetes is defacto a standard for container orchestration. Authors propose solution, providing git-reference to source code. Solution is implemented as Java-based application which uses time-series database (InfluxDB in this case) to understand microservice load. Solution utilizes two prediction models - Exponential Smoothing (ES) and Double Exponential Smoothing (DES). Two models are used to compare with each other. Performance tests are conducted to analyze two main use-cases – use case of slow load growth and case of rapid load growth. Based on experiments it is found that for all cases pro-active up-scaling works better than reactive one. Value from pro-active approach is more visible for case of rapid load growth. If to compare ES and DES between each other, in both cases DES showed better results. Future improvement of the solution could be to make a solution as extension to Kubernetes eco-system for easy plugging-in to Kubernetes infrastructure. Also one of the improvement could be supporting of Prometheus as timeseries database. Ref. 20, pic. 3, tabl. 2http://asac.kpi.ua/article/view/278925autoscalingcloud computingkubernetesproactive scalingreactive scaling |
| spellingShingle | D. Gutman O. Syrota Proactive automatic up-scaling for Kubernetes Adaptivni Sistemi Avtomatičnogo Upravlinnâ autoscaling cloud computing kubernetes proactive scaling reactive scaling |
| title | Proactive automatic up-scaling for Kubernetes |
| title_full | Proactive automatic up-scaling for Kubernetes |
| title_fullStr | Proactive automatic up-scaling for Kubernetes |
| title_full_unstemmed | Proactive automatic up-scaling for Kubernetes |
| title_short | Proactive automatic up-scaling for Kubernetes |
| title_sort | proactive automatic up scaling for kubernetes |
| topic | autoscaling cloud computing kubernetes proactive scaling reactive scaling |
| url | http://asac.kpi.ua/article/view/278925 |
| work_keys_str_mv | AT dgutman proactiveautomaticupscalingforkubernetes AT osyrota proactiveautomaticupscalingforkubernetes |