Machine Learning-Based Scaling Management for Kubernetes Edge Clusters

Toka, László; Dobreff, Gergely; Fodor, Balazs; Sonkoly, Balázs

doi:10.1109/tnsm.2021.3052837

Cited by 92 publications

(44 citation statements)

References 28 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This approach improves the automation of HPA and optimizes the application performance based on the load fluctuation. L.Toka et al [26] proposed HPA+, which provides proactive autoscaling to improve the quality of application services by exploiting the multi-forecast machine learning models. HPA+ applies the best prediction result from these forecasting models as the custom metric if their accuracy proves to equal that of the custom metric; otherwise, HPA+ uses CPU metrics to make scaling decisions.…”

Section: Related Workmentioning

confidence: 99%

“…HPA+ applies the best prediction result from these forecasting models as the custom metric if their accuracy proves to equal that of the custom metric; otherwise, HPA+ uses CPU metrics to make scaling decisions. However, despite efforts such as mixing both vertical and horizontal scaling mechanisms [24] and applying the machine learning to KHPA [25], [26], the quality of application services can be reduced if the network delay between worker nodes in an edge computing environment is high.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Traffic-Aware Horizontal Pod Autoscaler in Kubernetes-Based Edge Computing Infrastructure

2022

View full text Add to dashboard Cite

Container-based Internet of Things (IoT) applications in an edge computing environment require autoscaling to dynamically adapt to fluctuations in IoT device requests. Although Kubernetes' horizontal pod autoscaler provides the resource autoscaling feature by monitoring the resource status of nodes and then making pod adjustments if necessary, it evenly allocates pods to worker nodes without considering the imbalance of resource demand between nodes in an edge computing environment. This paper proposes the traffic-aware horizontal pod autoscaler (THPA), which operates on top of Kubernetes to enable real-time traffic-aware resource autoscaling for IoT applications in an edge computing environment. THPA performs upscaling and downscaling actions based on network traffic information from nodes to improve the quality of IoT services in the edge computing infrastructure. Experimental results show that Kubernetes with THPA improves the average response time and throughput of IoT applications by approximately 150% compared to Kubernetes with the horizontal pod autoscaler. This indicates that it is important to provide proper resource scaling according to the network traffic distribution to maximize IoT applications performance in an edge computing environment.INDEX TERMS Kubernetes, horizontal pod autoscaler, network-aware resource provisioning, IoT.

show abstract

Section: Related Workmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Traffic-Aware Horizontal Pod Autoscaler in Kubernetes-Based Edge Computing Infrastructure

2022

View full text Add to dashboard Cite

show abstract

“…The integration of placement methods with the auto-scaling capabilities of widely used platforms, e.g., Kubernetes [195], [196], or with reliability measures [166] necessary in an edge infrastructure that is prone to errors and downtimes, might be a challenging research avenue. Indeed, the optimization problem is rendered to be highly complex by integrating the dynamics of the deployed services and the actions the platform takes in turn.…”

Section: Temporal Placement Policies For Auto-scaling Edge Applicationsmentioning

confidence: 99%

Survey on Placement Methods in the Edge and Beyond

Sonkoly

Czentye

Szalay

et al. 2021

IEEE Commun. Surv. Tutorials

Self Cite

View full text Add to dashboard Cite

Edge computing is a (r)evolutionary extension of traditional cloud computing. It expands central cloud infrastructure with execution environments close to the users in terms of latency in order to enable a new generation of cloud applications. This paradigm shift has opened the door for telecommunications operators, mobile and fixed network vendors: they have joined the cloud ecosystem as essential stakeholders considerably influencing the future success of the technology. A key problem in edge computing is the optimal placement of computational units (virtual machines, containers, tasks or functions) of novel distributed applications. These components are deployed to a geographically distributed virtualized infrastructure and heterogeneous networking technologies are invoked to connect them while respecting quality requirements. The optimal hosting environment should be selected based on multiple criteria by novel scheduler algorithms which can cope with the new challenges of distributed cloud architecture where networking aspects cannot be ignored. The research community has dedicated significant efforts to this topic during recent years and a vast number of theoretical results have been published addressing different variants of the related mathematical problems. However, a comprehensive survey focusing on the technical and analytical aspects of the placement problem in various edge architectures is still missing. This survey provides a comprehensive summary and a structured taxonomy of the vast research on placement of computational entities in emerging edge infrastructures. Following the given taxonomy, the research papers are analyzed and categorized according to several dimensions, such as the capabilities of the underlying platforms, the structure of the supported services, the problem formulation, the applied mathematical methods, the objectives and constraints incorporated in the optimization problems, and the complexity of the proposed methods. We summarize the gained insights and important lessons learned, and finally, we reveal some important research gaps in the current literature.

show abstract

“…First, the MLFO solves the PDL using the constraints, resulting in a mapping between the ML functions and the datacenters, and the connectivity and the deployment plan is computed. A list of iterations is generated that includes the communication of the MLFO with the VIO (e.g., Kubernetes) for the deployment of the ML functions (e.g., encapsulated into containers [5] ), and with the SDN controller for managing the connectivity among the ML functions. The list iterations include: i) the namespace creation (3); ii) the configuration of an image repository storing the different computing images that are retrieved when a new ML function instance is deployed (4); iii) the configuration of the ML pipeline network that entails creating the VLAN (5) and pairing it "namespace": "mla2-v1", "renderdata": { "gw": "192.168.30.73", "name": "ovs-vlan-600", "subnet": "192.168.30.72/29", "vlan": 600}, "type": "ovs_network" } 5 { "namespace": "mla2-v1", "renderdata": { "configs": [{"name": "push-url", "value":"http://192.168.30.74/reg"}], "filename": "servers.yaml", "name": "dynamic-config-2"}, "type": "yamlfileconfig" } 7 { "datacenter": "Metro DC-1", "renderdata": { "name": "VLAN_600_to_TUNNEL_200", "tunnelid": 200, "vlanid": 600}, "type": "vlantotunnel" } 6 Fig.…”

Section: Proposed Architecture and Workflowsmentioning

confidence: 99%