Skip to content
Conference

KubeTwin 2.0: Demonstrating the Impact of Scheduling Strategies in Kubernetes

Jun 2026 · IEEE Conference on Network Softwarization · pp. 348-350 · 0 citations · 7 references
Computer Science

Abstract

Modern cloud-native applications increasingly rely on Kubernetes to orchestrate large-scale, heterogeneous workloads. However, experimenting with its cluster-level mechanisms in a scalable way, such as its diverse scheduling policies, remains difficult in production environments due to operational costs and limited observability. This demonstration showcases KubeTwin, a practical framework that creates and maintains a live Digital Twin of a Kubernetes cluster. KubeTwin enables the modeling of multi-cluster infrastructures, including edge and cloud nodes, heterogeneous resource capacities, and network latencies, allowing for safe experimentation, debugging, and what-if analysis without disrupting production workloads. Through an interactive demonstration, we show how researchers and developers can leverage KubeTwin to (i) assess the performance of workloads under diverse traffic patterns and (ii) evaluate diverse scheduling strategies under different infrastructure scenarios. The demo highlights how Kubernetes Digital Twins can bridge the gap between simulation and real-world experimentation, providing a powerful tool for both operational decision-making and research prototyping.

View source

Similar papers

Conference Jun 2026

Unveiling the Impact of Scheduling Strategies in Kubernetes with the KubeTwin Platform

Efficient workload scheduling is central to the performance, scalability, and cost-effectiveness of modern clouds. In the most popular cloud platform today, Kubernetes (K8s), the scheduler can be extended with multiple scheduling plugins, enabling fine-grained control over scheduling decisions. However, cloud providers often lack clear insights into the trade-offs of individual placement strategies and resort to combining multiple plugins without a clear rationale. This uncertainty creates a gap in understanding which scheduling configuration yields optimal results for a given application or traffic pattern under specific infrastructure conditions. Thus, this paper investigates the implications of different scheduling strategies in K8s by leveraging KubeTwin (KT), a high-fidelity simulator for the K8s platform designed for reproducible experimentation. This work extended KT with advanced scheduling capabilities to evaluate the impact of single and combined scheduling plugins across diverse workloads and infrastructure conditions, focusing on key aspects such as performance, fairness, and resource utilization. The results highlight that Node-affinity and Diktyo single-purpose plugins consistently outperform multi-objective scheduling combinations, achieving the lowest deployment costs (below 50 price/day), shortest queue times (under 50 ms), and fastest response times (below 200 ms). In contrast, combined strategies, such as Balanced, result in significantly higher costs and higher latency. This study shows that combining multiple optimization criteria within a single scheduling strategy often degrades performance, whereas targeted, single-objective plugins deliver robust and predictable behavior across heterogeneous infrastructures and workload patterns.

José Santos, D. Borsatti, Walter Cerroni et al. · 1 citation
Review Open access Jul 2026

Enhancing the Kubernetes Scheduler: A State-of-the-Art Review from Cloud to Edge

A comprehensive review of Kubernetes scheduling strategies published between January 2023 and January 2026 is presented and a multi-dimensional taxonomy is established that categorizes scheduling approaches based on common objectives, modification methods, optimization methodologies, targeted workloads, evaluation methods, scheduling scopes, and performance metrics.

Mohammed Alhakimi, R. Latip · 0 citations
Conference Jun 2026

An Experimental Evaluation of VPA and in-Place Resource Resizing in Kubernetes Under Dynamic Workloads

Efficient resource management remains a main challenge in Kubernetes, where scaling plays a key role in ensuring that resource provisioning adapts to workload variability. Vertical Pod Autoscaler (VPA) is the default mechanism in Kubernetes for vertical scaling, but its reliance on evicting pods to apply new resource values often disrupts applications. To address this, Kubernetes introduced In-Place Resource Resizing (IRR), which allows CPU and memory requests to be updated directly on running pods without eviction. In this paper, we experimentally evaluate VPA combined with IRR under dynamic and longrunning workloads. We designed and implemented a trafficdriven ns-3 workload to generate realistic CPU and memory variations over time, and developed a controller that bridges VPA recommendations with IRR to enable automated, eviction-free vertical scaling while considering QoS-related constraints defined by Kubernetes. Our evaluation analyzes the stability and responsiveness of IRR under different workload intensities, and extends the analysis to power consumption. The results show that eviction-free vertical scaling with IRR provides more stable resource and power behavior compared to the traditional VPA.

Hadil Bouasker, Massinissa Ait Aba, Abdenour Yasser Brahmi et al. · 0 citations
Preprint Aug 2026

A Kubernetes Scheduler Plugin for Cluster-Wide Placement Optimisation

The default scheduler of Kubernetes, the state-of-the-art container orchestrator, uses fast, local placement decisions. Unfortunately, this design leads to resource fragmentation, reduced cluster usage, and overprovisioning. External solvers can compute global placement plans, but enforcing these plans in upstream clusters is hard. Kubernetes provides no native cross-node preemption, uncoordinated concurrent scheduling leads to inconsistencies, and replacing the default scheduler would sever deployments from upstream cycles. We present OPSche, an open-source Kubernetes Scheduling Framework plugin where external solvers can drive cluster-wide placement decisions in concert with the default scheduler. OPSche atomically validates and enforces solver-produced plans through coordinated framework hooks and supports three trigger modes: scheduling-failure, periodic, and stable-queue -- resp. triggered when a workload cannot be placed, at fixed time intervals, when the set of pending workloads stabilises. Each mode has a blocking variant for a finer tuning of placement quality, latency, and disruption. We pair OPSche with a constraint-based optimisation solver, showing its feasibility across a broad set of cluster configurations and reporting improvements of resource usage by up to 3.0% and scheduling latency by more than a second.

Henrik Christensen, S. Giallorenzo, J. Mauro · 0 citations
Conference Jul 2026

Implementation of the Fremer Model to Optimize Kubernetes Configuration in Concert Ticketing Application Deployment

As digital services evolve, the need for scalable and robust cloud-native applications increases. Kubernetes has become one of the most widely used container orchestration platforms. However, Kubernetes takes a while to react to unexpected surges in workload because its built-in autoscaling method is still reactive. This has been identified as one of the challenges for extreme traffic applications, such as selling concert tickets, which can generate millions of requests within seconds. This research work presents the implementation of the Fremer model, which is a lightweight frequency domain transformer that can be used to predict workloads and support proactive autoscaling for environments using Kubernetes. A dummy concert ticketing application was used on Google Cloud Kubernetes Engine and was monitored using Prometheus for Central Processing Unit (CPU) usage. A user behavior survey was conducted to determine realistic workload patterns in the concert ticket sales application. To create a dataset with realistic workload patterns, JMeter-based stress tests were run using the obtained survey data. The collected dataset was used to train the Fremer model to predict CPU usage ahead of time and provide early scaling decisions. Experimental results show that this model can capture general CPU usage trends and predict spikes well in advance of actual spikes. This allows for proactive provisioning of pods before peak load occurs. Although performance degrades under highly volatile spike conditions, the results show that Fremer can improve predictive autoscaling for moderately volatile scenarios. Overall, the implementation shows that Fremer can improve the efficiency and responsiveness of Kubernetes resources by shifting autoscaling from reactive to predictive.

Ziven Ferdinand, Gladys Jessica Ruslim, Tristan Aaron Hidajat et al. · 0 citations
Open access Jul 2026

Evaluating Kubernetes Progressive Delivery in Constrained Environments Flagger vs. Argo Rollouts

Cloud‑native progressive delivery orchestrators reduce deployment risk by automating canary deployment rollback procedures, dramatically reducing mean time to recover from deployment failures. However, existing research predominantly evaluates these tools in hyperscale environments, masking the transient computational overhead they introduce in resource‑constrained edge deployments. This study empirically evaluates and compares the automated incident mitigation latency and computational resource volatility of Flagger and Argo Rollouts within a strictly resource‑constrained Kubernetes environment. A low virtual central processing unit Kubernetes testbed was provisioned using Talos Linux with strict hypervisor‑level central processing unit pinning, simulating edge computing conditions. Deterministic fault injection spanning four fault classes, two workload runtimes, and two network topology configurations was executed across thirty trials. A Shapiro-Wilk normality assessment, Welch t-test, Mann-Whitney U test, Cohen's d, and 95% confidence intervals were applied to compare temporal and computational metrics. Memory utilization remained statically bounded, averaging 24.01 megabytes for Flagger and 35.47 megabytes for Argo Rollouts. Under standard fault conditions, neither orchestrator demonstrated a consistent temporal advantage. However, under memory exhaustion progressing to CrashLoopBackOff, Argo Rollouts recovered in a mean of 29.67 seconds against Flagger's 166.79 seconds, a statistically significant 5.6-fold degradation with a large effect size. Argo Rollouts sustained transient central processing unit surges of 159 to 168 millicpu against Flagger's bounded ceiling of 17 to 18 millicpu. Progressive delivery automation introduces non‑negligible and fault-type-dependent computational overhead in resource‑constrained environments. Flagger is recommended for strict resource predictability in threshold-breach environments, while Argo Rollouts is recommended where broader fault-type resilience is operationally critical.

Gagah Syuja Saka Abdullah, Rama Aria Megantara · 0 citations