Міграція сервісів у кластері Kubernetes на основі прогнозування навантаження

Abstract

У статті розглянуто проблему масштабування мікросервісів у кластері Kubernetes, підходи до масштабування мікросервісної архітектури та запропоновано підхід до масштабування із міграцією частини компонентів. На відміну від найпоширеніших підходів горизонтального та вертикального масштабування, для здійснення яких необхідно виділяти додаткові ресурси, суть запропонованого підходу полягає в міграції частини компонентів, які не є критично важливими для кінцевого користувача системи, на інший Kubernetes кластер. Запропонований підхід дає змогу звільнити ресурси на кластері, в якому збільшується навантаження, без необхідності залучення додаткових ресурсів. Це, своєю чергою, зменшує вартість обслуговування системи. Також здійснено порівняння реактивного та проактивного підходів до прийняття системою рішення про масштабування. Вибрано проактивний підхід до прийняття рішення, оскільки, на відміну від реактивного підходу, за яким масштабу- вання відбувається як реакція на збільшення навантаження в системі, в проактивному підході рішення про масштабування приймають на основі прогнозованих даних, ще до того, як реальне навантаження на систему почне зростати, що дасть змогу зберегти показник якості обслуговування QOS на хорошому рівні. Для вибору найоптимальнішого способу прогнозування навантаження розглянуто відомі моделі прогнозування та здійснено практичне порівняння моделей прогнозування ARIMA, Prophet, LSTM. У результаті порівняння вибрано ARIMA як модель для реалізації запропонованого підходу, реалізовано запропонований підхід у вигляді docker контейнера з python застосунком всередині. Цей застосунок отримує дані про систему з Prometheus бази даних та здійснює прогнозування, після чого змінює конфігураційні файли із описанням розгортання для ArgoCD та зберігає зміни в Git репозиторії. Після того як змінені конфігураційні файли потрапляють у Git репозиторій, ArgoCD отримує оновлену конфігурацію та порівнює її із поточним розгортанням. Якщо оновлена конфігурація відрізняється від наявного розгортання, ArgoCD автоматично переводить інфраструктуру до заданого стану.The article delves into the intricate challenge of scaling microservices within a Kubernetes cluster, thoroughly examining existing methodologies for scaling microservice architectures, and presenting a novel approach that involves migrating specific components. Unlike the conventional horizontal and vertical scaling strategies, which require additional resources, this proposed method focuses on migrating non-critical components to another Kubernetes cluster. This migration effectively frees up resources in the cluster experiencing increased load without necessitating extra resources, thus significantly reducing maintenance costs through lower server rental expenses. Furthermore, a detailed comparative analysis of reactive and proactive decision-making approaches for system scaling was conducted, with a preference shown for the proactive approach. Unlike the reactive method, where scaling is a response to an increase in load, the proactive approach relies on forecasted data to make scaling decisions before the actual load rises, thereby maintaining a high quality of service (QoS). To identify the most optimal load forecasting method, various models were reviewed and practically compared, including ARIMA, Prophet, and LSTM models. ARIMA was ultimately selected for implementing the proposed approach, realized as a Docker container with a Python application. This application retrieves system data from the Prometheus database and utilizes the ARIMA model for forecasting. Post-forecasting, it updates the deployment configuration files for ArgoCD and commits the changes to a Git repository. Once the updated configuration files are pushed to the Git repository, ArgoCD fetches the new configuration, compares it with the current deployment, and if there are discrepancies, automatically adjusts the infrastructure to the desired state. This approach not only optimizes resource usage within the Kubernetes cluster but also maintains high performance without incurring additional costs.