# Towards a Novel Vertical Scaling Approach for Bursty Workloads in Kubernetes

Miguel de Lima, Luan Teylo, Lucia Drummond

► To cite this version:

Miguel de Lima, Luan Teylo, Lucia Drummond. Towards a Novel Vertical Scaling Approach for Bursty Workloads in Kubernetes. UCC 2025 - 18th IEEE/ACM International Conference on Utility and Cloud Computing, Dec 2025, Nantes, France. pp.1-6, 10.1145/3773274.3774699 . hal-05466865

HAL Id: hal-05466865

https://inria.hal.science/hal-05466865v1

Submitted on 20 Jan 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Towards a Novel Vertical Scaling Approach for Bursty Workloads in Kubernetes

Miguel de Lima**

Federal Fluminense University

Niterói, Brazil

miguel_flj@id.uff.br

Luan Teylo*

INRIA

Bordeaux, France

luan.teylo@inria.fr

Lúcia Drummond*

Federal Fluminense University

Niterói, Brazil

lucia@ic.uff.br

## Abstract

Traditional static computational resource allocation in cloud or on-premises clusters often results in inefficient overprovisioning. Users frequently lack precise knowledge of the memory and processors their applications require, leading them to request excess resources. This causes wasted capacity, higher costs, and, in shared environments, longer queue waiting times. Dynamic resource allocation through autoscaling addresses this issue by adjusting resources at runtime. Kubernetes, a widely used container orchestration platform, supports autoscaling via Horizontal and Vertical Pod Autoscalers. However, its default restart-based scaling can disrupt stateful, long-running workloads without checkpointing. This work leverages Kubernetes' new in-place scaling, which resizes resources without restarts, to propose the Dynamic Resizing Strategy (DRS), a novel autoscaling approach that proactively manages contention by temporarily throttling co-located pods to prioritize a bursting application. We evaluate it with NAS Parallel Benchmarks and synthetic workloads in co-execution scenarios, showing improved efficiency and stability, increasing success rates and reducing global average wait time by over 18% compared to the Burstable QoS class.

## Keywords

Kubernetes, Vertical Scaling, In-place Autoscaling, Containerized Workloads

## ACM Reference Format:

Miguel de Lima, Luan Teylo, and Lúcia Drummond. 2025. Towards a Novel Vertical Scaling Approach for Bursty Workloads in Kubernetes. In *2025 IEEE/ACM 18th International Conference on Utility and Cloud Computing (UCC '25), December 1-4, 2025, France, France*. ACM, New York, NY, USA, 6 pages. https://doi.org/10.1145/3773274.3774699

## 1 Introduction

When running applications in the cloud or on on-premises clusters, the allocation of computational resources is managed and provisioned by an orchestrator, such as Kubernetes, or a job scheduler, such as Slurm. In these environments, users must specify their application requirements (number of nodes, memory size, and core count) so that the orchestrator can allocate the requested resources. In most platforms, this allocation is static: a fixed set of resources is assigned at the start of execution and released only when the application finishes. While this approach is effective when resource availability is not a concern, it presents notable drawbacks, particularly when the system is under heavy utilization.

A primary limitation of static resource allocation is that users often lack precise knowledge of their application's actual needs, leading to overprovisioning. This overestimation reduces overall system utilization, as some applications occupy more resources than necessary while others remain stuck in waiting queues. Furthermore, since many applications have distinct execution phases with varying resource demands, static allocation wastes resources during lighter phases and can limit performance or even cause disruptions due to Out of Memory (OOM) errors when resources are underprovisioned during more intensive phases.

In the past, malleable jobs, i.e., applications capable of dynamically adapting their CPU cores or processes at runtime, have been explored as a solution to this problem. However, their adoption has been limited, as they require extensive changes to the software stack and, in many cases, modifications to the application code itself. This makes them impractical for legacy or commercial applications that cannot easily be rewritten.

Containerization provides a promising alternative for managing applications, as it simplifies deployment and improves portability across different environments. Kubernetes has emerged as the leading platform for orchestrating containerized workloads, offering mechanisms for autoscaling resources at runtime. However, the traditional autoscaling mechanism in Kubernetes relies on restarting containers to adjust their allocated resources. While this approach works well for stateless services, it can be highly disruptive for long-running or stateful workloads, introducing costly restarts and requiring frequent checkpointing to preserve state.

To address these limitations, Kubernetes recently introduced in-place autoscaling, a feature that allows container resources to be adjusted at runtime without restarting the application. This eliminates the overhead of restarts and enables faster, more responsive adaptation to changing resource demands. In this work, we evaluate Kubernetes' in-place autoscaling in the context of bursty workloads, i.e., applications characterized by alternating phases of low and high resource usage [10]. We first analyze how different Quality of Service (QoS) strategies influence scheduling decisions and application execution. Building on this analysis, we propose the Dynamic Resizing Strategy (DRS), an autotuning approach that dynamically adjusts container resource limits during execution. Our experiments using the NAS Parallel Benchmarks and synthetic workloads demonstrate that this strategy improves both system

<footnote>*All authors contributed equally to this research.</footnote>

<footnote>Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.</footnote>

<footnote>UCC '25, France, France</footnote>

<footnote>© 2025 Copyright held by the owner/author(s). Publication rights licensed to ACM.</footnote>

<footnote>ACM ISBN 979-8-4007-2285-1/2025/12</footnote>

<footnote>https://doi.org/10.1145/3773274.3774699</footnote>
efficiency and stability, increasing the application success rate compared to the default Kubernetes QoS classes and reducing the global average waiting time (i.e., the sum of all application waiting times) by more than 18% when compared to the Burstable QoS class. The main contributions of this paper are: i) the proposal of DRS, a novel autoscaling approach that leverages in-place scaling to dynamically adjust container resources without restarts, and ii) a systematic evaluation of how different Kubernetes' QoS classes behave under bursty workloads.

The remainder of this paper is organized as follows. Section 2 provides background on Kubernetes resource management and reviews related work on vertical autoscaling. Section 3 introduces the proposed DRS approach, followed by Section 4, which describes the experimental methodology. Section 5 then presents and analyzes the results, examining the behavior of different QoS strategies and assessing the effectiveness of our autoscaling solution. Finally, Section 6 summarizes our findings and outlines directions for future work.

## 2 Background & Related Work

Efficient resource management is fundamental to achieving high throughput and utilization in containerized environments. This section reviews the standard resource management mechanisms in Kubernetes and discusses recent research in vertical autoscaling.

Kubernetes manages applications through pods, which encapsulate containers and are scheduled across worker nodes under the supervision of the control plane [7]. Resource allocation is defined via requests, which represent the minimum guaranteed resources used by the scheduler, and limits, which specify the maximum consumption a container can reach [9].

Based on resource requests and limits, Kubernetes assign each pod a QoS class that determines its scheduling and eviction priority [8]. Guaranteed pods, where requests equal limits, provide predictable performance but often lead to resource underutilization. Burstable pods, with requests lower than limits, increase overall cluster utilization but offer weaker performance guarantees. BestEffort pods, with no defined resource values, are the most flexible but also the first to be evicted under resource pressure. For workloads with dynamic demands, selecting the appropriate class is challenging, as misconfiguration can waste resources, degrade performance, or interrupt execution (see Section 5).

To address the limitations of fixed resource definitions, Kubernetes provides the Vertical Pod Autoscaler (VPA). The VPA automates the process of setting resource requests and limits by continuously monitoring a pod's resource usage and dynamically recommending updated values during execution [6]. It can also leverage historical data from previous runs of the same pod to improve the accuracy of its recommendations. However, applying these new configurations requires a pod restart, which is highly disruptive for stateful applications that are not designed to handle failures. This makes the standard VPA unsuitable for long-running jobs that lack checkpointing mechanisms to preserve their progress.

Several studies have addressed auto-scaling in Kubernetes, typically focusing on improving resource management to prevent application disruptions from resource scarcity or disruptive scaling events [3-5].

Focusing on memory elasticity, Vertical Elasticity Management of Containers (VEMOC) implements fine-grained control by monitoring page-level statistics to predict memory demand [4]. To prevent OOM failures in contended environments, VEMOC employs actions beyond simple resizing, such as forcing containers to swap inactive memory pages or preemptively pausing lower-priority workloads.

To address the VPA's disruptive restarts, the Resource Utilization Based Autoscaling System (RUBAS) was proposed [5]. Instead of terminating a pod, RUBAS uses Checkpoint/Restore in Userspace (CRIU) to save its state and migrate it to another node with sufficient resources, enabling non-disruptive scaling for stateful jobs. Additionally, RUBAS uses a more robust estimation model based on the median and standard deviation of recent usage, making it less susceptible to transient spikes than the VPA's peak-based approach. Although checkpointing-based migration offers several advantages over typical Kubernetes autoscaling, it still incurs significant overhead, especially during migration.

The Adaptive Resource Controller - Vertical (ARC-V) is a policy designed specifically for workloads with variable memory demands [3]. ARC-V classifies an application's behavior as Growing, Stable, or Dynamic and applies a tailored, reactive scaling policy for each phase. By adjusting memory limits in-place without restarts, it adapts to different computational stages, saving memory and preventing OOM errors.

While these systems offer powerful custom solutions, they often rely on complex external controllers or mechanisms like checkpointing, which can introduce overhead. In contrast, our work leverages the recently introduced native in-place scaling capability in Kubernetes. Instead of proposing another external controller, we evaluate how this built-in feature interacts with the standard QoS framework. Our contribution is an auto-tuning approach that works with, rather than replacing, Kubernetes' native mechanisms to efficiently manage bursty workloads.

## 3 Dynamic Resizing Strategy

To overcome the limitations of Kubernetes' static QoS strategies, we propose an autotuning approach called the Dynamic Resizing Strategy (DRS). This methodology is designed to proactively manage resource contention in co-execution environments for bursty workloads by combining prior knowledge of application behavior with real-time monitoring. DRS leverages Kubernetes' in-place scaling feature to dynamically adjust container resources without requiring restarts.

The core logic of DRS is a preventive quarantine mechanism. Instead of conservatively allocating resources for the peak utilization of all applications, which leads to low system utilization, as seen in the Guaranteed scenario, DRS allows applications to run with more flexible resource allocations for most of their execution time. Intervention occurs only when an imminent risk of memory saturation is detected.

The operation of DRS is orchestrated by a controller that continuously monitors the memory usage of running pods. For each application, it is assumed that its usage profile is known, with its average memory consumption defined in the pod's request field and its peak consumption defined in the limit field. Based on these
values, a memory alert threshold ($M_{alert}$) is dynamically calculated, as shown in Equation 1:

$$M_{alert} = M_{request} + (M_{limit} - M_{request}) \times F_{trigger} \quad (1)$$

Where:

* $M_{request}$ is the value defined in the pod's memory request, representing its expected average consumption.

* $M_{limit}$ is the value defined in the memory limit, representing its peak consumption.

* $F_{trigger}$ is a configurable trigger factor (set to 0.5 in our experiments), which represents how close to the peak the memory usage must get to trigger the preventive action.

The DRS control process begins with continuous monitoring of memory usage across all running pods at regular intervals. When the memory consumption of any pod surpasses its calculated $M_{alert}$ threshold, DRS identifies this pod as *prioritized*, indicating it is undergoing a memory burst. This detection immediately triggers a *quarantine mode*. In this mode, the prioritized pod's resources remain unchanged to allow it to continue its intensive phase without disruption. Concurrently, DRS applies a restrictive policy to all other co-located pods by leveraging in-place scaling to update their CPU requests and limits to a minimal value, 1 millicore. This action reduces their computational activity to a minimal level, preventing them from also initiating high-consumption phases that could lead to node saturation and OOM events. The system remains in quarantine, continuously monitoring the prioritized pod, until its memory usage returns to a level below the alert threshold. Once this occurs, the quarantine mode is deactivated, and the CPU resources of all previously throttled pods are restored to their original values, allowing them to resume normal execution. By prioritizing the application demanding more memory and temporarily pausing others, DRS avoids memory-related failures, enhances system stability, without incurring the long queue times characteristic of the Guaranteed strategy.

# 4 Methodology

This section describes the methodology used to investigate the impact of resource bursting on the performance of applications managed by Kubernetes. The experimental procedure was designed to first characterize the behavior of individual applications and then evaluate their performance under different resource allocation policies in a co-execution environment.<fnref n="1" />

## 4.1 Experimental Environment & Workloads

Experiments were conducted on a single-node Kubernetes cluster (v1.33.2) to isolate and control application behavior. The worker node is equipped with 32 CPU cores, 64 GB of RAM, and runs Ubuntu 22.04 LTS with containerd v1.7.27. Real-time CPU and memory usage were collected via the Kubernetes Metric Server through the standard Kubernetes API.

We evaluated two types of workloads: a set of CPU- and memory-intensive applications from the well-known NAS Parallel Benchmarks (NPB) [2]; and a suite of synthetic applications based on the template proposed in [1].

**NPB applications.** NPB workloads (class D) were selected to be used as a performance baseline for steady-state applications, allowing for the evaluation of the impact of autoscaling dynamic workloads co-located on the same node. The chosen applications exhibit relatively stable resource usage patterns (for both CPU and memory), showing little variation over time and offering virtually no margin for effective autoscaling.

* CG: a kernel that performs a conjugate gradient operation and exhibits irregular memory access.

* EP: an embarrassingly parallel kernel with a low memory footprint and high CPU utilization.

* MG: a multi-grid solver on a sequence of meshes, which is memory-intensive.

* BT and SP: pseudo-applications representing a Block Tri-diagonal solver and a Scalar Penta-diagonal, respectively. Both are memory- and computationally intensive.

**Synthetic Applications.** To represent workloads with significant variability in CPU and memory requirements, we constructed a suite of synthetic applications based on the C++ driver proposed in [1]. This driver defines three core execution phases: *Memory* (allocating or releasing memory), *CPU* (performing computations), and *Sleep* (pausing). In our modification, we separated these phases into independent kernels, creating an interface that allows complex applications to be built by sequencing them in different ways. The code below shows an example of how a synthetic application can be built using our modified C++ driver:

```
./synthetic_app --name=example \
--phase type=mem,abs=22.1G \
--phase type=cpu,threads=28,util=0.88,duration=315s \
--phase type=mem,delta=+16.5G \
--phase type=sleep,duration=19s \
--phase type=mem,delta=-12.4G \
--phase type=cpu,threads=16,util=0.5,duration=200s
```

In this example, the application has six phases: it starts by allocating a 22.1 GiB memory block, then enters a computational phase where 28 threads execute for 315 seconds at 88% CPU utilization (parameter util). Next, it increases the memory footprint by 16.5 GiB and performs a 19-second sleep while holding the allocated memory. Then, it releases 12.4 GiB of memory and finally runs a computational phase with 16 threads at 50% CPU utilization for 200 seconds. By combining these phases, we model a variety of behaviors commonly observed in applications from different domains while maintaining precise control over timing and resource intensity. We focus on behaviors that exhibit variability in both CPU and memory usage, and define four synthetic applications, each representing a distinct behavior pattern:

* SIM-Staircase: gradual memory increases in steps, short holds, and partial releases with intermittent CPU bursts.

* SIM-Spikes: low baseline with brief but intense memory spikes, followed by aggressive releases and high CPU utilization.

<footnote n="1">¹All scripts and source code supporting this study are publicly available at https://github.com/migueluff/Kube-DRM.</footnote>
<table><caption>**Table 1: Parameters and resource profiles of the synthetic application behaviors used in the experiments**</caption><thead><tr><th rowspan="2">Behavior<br>α<sub>base</sub></th><th colspan="2">Memory</th><th colspan="2">CPU</th><th colspan="3">Number of Phases</th></tr><tr><th>α<sub>peak</sub></th><th>ΔM<br>(GiB)</th><th>Threads</th><th>u</th><th>Mem</th><th>CPU</th><th>Sleep</th></tr></thead><tbody><tr><td>SIM- 0.22<br>Staircase</td><td>0.59</td><td>23.5</td><td>18–28</td><td>0.62–0.91</td><td>6</td><td>4</td><td>4</td></tr><tr><td>SIM- 0.13<br>Spikes</td><td>0.53</td><td>26.0</td><td>12–30</td><td>0.48–0.93</td><td>6</td><td>5</td><td>4</td></tr><tr><td>SIM- 0.38<br>Sawtooth</td><td>0.88</td><td>32.0</td><td>10–30</td><td>0.40–0.92</td><td>6</td><td>5</td><td>4</td></tr><tr><td>SIM- 0.19<br>Epochs</td><td>0.69</td><td>32.0</td><td>12–28</td><td>0.45–0.90</td><td>8</td><td>6</td><td>6</td></tr></tbody></table>

* SIM-Sawtooth: repeated cycles of rapid memory growth, partial drops, and regrowth, with alternating high and moderate CPU phases.

* SIM-Epochs: repeated per-epoch allocations and releases, mimicking iterative algorithms with temporary buffer usage.

All synthetic workloads respect the node's limits ($C_{cpu} = 32$, $C_{mem} = 64$ GiB). Parameters were chosen to create significant scaling opportunities: memory baselines range from 8–24 GiB with peaks between 34–58 GiB, and sharp increments ($ΔM$) up to 32 GiB. CPU usage was also varied (thread count and utilization $u$) to simulate a range of compute-bound behaviors. The memory footprint is characterized by the baseline fraction $α_{base}$ and the peak fraction $α_{peak}$ defined in Equation 2.

$$ 
\begin{aligned}
M_0 &= \alpha_{\text{base}} \times C_{\text{mem}} \\
M_p &= \alpha_{\text{peak}} \times C_{\text{mem}} \\
\Delta M &= M_p - M_0
\end{aligned} 
\qquad (2) 
$$

where $M_0$ is the steady-state allocation, $M_p$ the maximum footprint, and $ΔM$ the growth during a spike. Table 1 summarizes the configuration parameters for each case. Note that the maximum memory footprint of all applications exceeds the available resources of our worker node. This setup was intentionally designed to study Kubernetes QoS strategies under high pressure, as discussed in Section 5.

## 4.2 Experimental Design

The experiment was divided into two phases:

*Application Characterization and Profiling.* First, we profiled each application individually by running it with low resource requests and high limits. This allowed us to establish performance baselines and characterize its dynamic CPU and memory demands. We collected time-series usage data, VPA recommendations (average and peak), and total runtime to inform the co-execution scenarios in Phase 2.

*Co-execution Experiments.* Next, we execute all applications in the same node to evaluate the impact of resource contention. The primary goal was to compare the performance of standard Kubernetes QoS configurations against our proposed dynamic autoscaling strategy in a competitive environment. We defined three

static configuration scenarios to evaluate Kubernetes scheduling under different assumptions about resource knowledge. We compare these common Burstable and Guaranteed QoS strategies against our dynamic autoscaling approach (DRS) to contrast static versus adaptive resource management.

In the first scenario, called Extreme, all applications are submitted by defining a minimal value for CPU and memory in the request and the maximum possible values in the limit. The idea is to emulate a case where the user has no prior knowledge of the application's resource utilization. In this scenario, all applications belong to Kubernetes' Burstable QoS class. For the request, we define 100 millicores (100m) of CPU and 128 mebibytes (128Mi) of memory, while for the limit we use the maximum available resources of the worker nodes (32 CPU cores and 62.5 gibibytes (Gi) of memory).

The second scenario, called Guaranteed, represents the case where prior knowledge of application resource utilization is available, and the user decides to be conservative by not allowing any application to burst. This corresponds to Kubernetes' Guaranteed QoS class, where both the CPU request and limit are set to the same value. In our tests, these values are defined per application, and we use the peak utilization observed for CPU and memory (Table 2 shows these values).

The third scenario, called Clairvoyant, assumes knowledge of both the average and peak resource utilization. In this case, we set the CPU and memory request values to the measured averages of each application, and the limit values to the corresponding peaks (see Table 2). Note that only applications where the average utilization is lower than the peak will be treated by Kubernetes as belonging to the Burstable QoS class.

# 5 Experimental Results

This section presents the empirical evaluation of three co-execution scenarios: Guaranteed, DRS, Clairvoyant, and Extreme. The objective of this evaluation is to quantify the impact of each strategy on system stability, application performance, and scheduling efficiency.

## 5.1 Application Execution in Isolation

To establish a performance baseline, we first profiled each application individually in five independent executions, observing minimal variance between runs. This analysis captures the resource consumption of each application in isolation. Table 2 summarizes these results, reporting the average and peak metrics for both CPU usage (mCores, the smallest unit of CPU allocation in Kubernetes, where 1000 mCores correspond to one full CPU core) and memory usage (MiB). The data reveal the heterogeneity of the workload: while some applications, such as SIM-Epochs, exhibit substantial differences between average and peak consumption, others, such as NAS-BT, present a much more stable profile.

To further illustrate the dynamic nature of resource consumption, Figure 1 shows the CPU usage profiles over time for two representative applications. These plots contrast the actual usage of resources with the recommendations generated by the VPA. The divergence between observed behavior and VPA estimates highlights the variability that the scheduler must accommodate and underscores the challenges faced by different QoS strategies.
<table><caption>Table 2: CPU and Memory Usage Statistics by Application</caption><thead><tr><th rowspan="2">Application</th><th colspan="2">CPU Usage (mCores)</th><th colspan="2">Memory Usage (MiB)</th></tr><tr><th>Average</th><th>Peak</th><th>Average</th><th>Peak</th></tr></thead><tbody><tr><td>NAS-BT</td><td>28,836</td><td>29,713</td><td>10,958</td><td>10,958</td></tr><tr><td>NAS-CG</td><td>27,675</td><td>29,316</td><td>16,741</td><td>16,742</td></tr><tr><td>NAS-EP</td><td>31,023</td><td>31,899</td><td>34</td><td>35</td></tr><tr><td>NAS-MG</td><td>28,223</td><td>28,473</td><td>27,149</td><td>27,149</td></tr><tr><td>NAS-SP</td><td>28,532</td><td>29,136</td><td>11,469</td><td>11,469</td></tr><tr><td>SIM-Epochs</td><td>14,541</td><td>25,016</td><td>16,391</td><td>45,145</td></tr><tr><td>SIM-Spikes</td><td>13,855</td><td>27,114</td><td>16,484</td><td>34,885</td></tr><tr><td>SIM-Sawtooth</td><td>17,355</td><td>26,367</td><td>30,943</td><td>57,457</td></tr><tr><td>SIM-Staircase</td><td>17,253</td><td>25,302</td><td>24,762</td><td>33,348</td></tr></tbody></table>

<figure><img src="image_2.png" /><figcaption>Figure 1: CPU usage profile and VPA recommendation for representative applications (Top: The stable profile of NAS-BT. Bottom: The bursty profile of SIM-Spikes)</figcaption></figure>

Next, we use the resource utilization values obtained from this characterization to define the co-execution scenarios.

## 5.2 Evaluation of the co-execution Scenarios

We compare the DRS strategy against the three native Kubernetes QoS scenarios across the key metrics of stability, performance, and average wait time.

The first metric is system stability, measured by the number of applications that successfully completed execution. Application failures, defined as non-completion, are caused by Out of Memory (OOM) errors. These occur when multiple applications enter a high-consumption phase simultaneously, exceeding node capacity, particularly in the Clairvoyant and Extreme scenarios. Figure 2 compares this metric across scenarios. The Guaranteed strategy establishes the baseline with a 100% success rate, ensuring the execution of all nine submitted applications. The DRS strategy demonstrates improvements in reliability over burstable approaches, successfully completing seven of the nine applications. This result positions it as a robust alternative, approaching the stability of the

Guaranteed baseline while surpassing the Clairvoyant scenario, which experienced four failures. The Extreme scenario performed worst, with only three successful completions, an expected outcome given its lack of resource guarantees.

<figure><img src="image_3.png" /><figcaption>Figure 2: Successfully Executed Applications per Scenario</figcaption></figure>

Beyond stability, we evaluated the performance impact on completed applications using the slowdown metric, defined as the ratio between an application's execution time under co-execution and its execution time in isolation. As shown in Figure 3, applications in the Guaranteed scenario (Figure 3a) consistently exhibited slowdown values close to 1.0, confirming strong performance isolation. In contrast, the DRS approach introduces a measurable performance cost for its dynamic flexibility; applications engaged in bursting activity experienced a slowdown reaching up to 1.7x (Figure 3b). However, this performance trade-off is well-contained and demonstrates improvements over the less stable scenarios. Surviving applications in the Clairvoyant and Extreme strategies (Figures 3c and 3d) suffered from more severe and uncontrolled degradation, with slowdowns reaching up to 1.8x and nearly 4.0x, respectively. This shows that DRS effectively mitigates the worst-case performance penalties inherent in overcommitment strategies.

Finally, we examined the trade-off between the stability ensured by the Guaranteed strategy and its impact on scheduling efficiency. Figure 4 illustrates this cost by reporting the average wait time across scenarios. The Guaranteed strategy incurred the longest delays, with an average wait time of 3157.88s, compared to 1742.16s for Clairvoyant and only 1.40s for Extreme. Our DRS strategy substantially mitigates this scheduling cost, reducing the average wait times by more than 18% to 2581.01s without significantly compromising application stability. The longer delays in the Guaranteed case arise because the scheduler must locate a node capable of fully satisfying the requested resources without overcommitment. By contrast, the flexibility of overcommitment in the other scenarios enables much faster pod placement.

These results reveal a clear trade-off among the native Kubernetes QoS strategies. The Guaranteed strategy delivers maximum stability at the cost of high scheduling latency. Conversely, Clairvoyant and Extreme prioritize speed at the expense of reliability. Our DRS strategy emerges as a superior solution, effectively navigating this trade-off. It achieves a success rate second only to the rigid Guaranteed strategy while significantly reducing queue times. By dynamically adapting resource allocations, DRS balances efficiency, performance, and reliability, proving to be a more suitable approach for managing dynamic workloads in shared environments than the static native QoS classes.
<figure><img src="image_4.png" /><figcaption>(a) Guaranteed scenario</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>(b) DRS scenario</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>(c) Clairvoyant scenario</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>(d) Extreme scenario</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Figure 4: Average Application Wait Time by Scenario</figcaption></figure>

# 6 Conclusion

This study addressed the challenge of executing bursty workloads on Kubernetes and exposed a clear trade-off across native QoS-based scenarios. The Guaranteed scenario provides stability but at the cost of prohibitive scheduling delays, whereas Clairvoyant and Extreme prioritize speed at the expense of higher failure rates and severe performance degradation. These results confirm that static configurations are fundamentally inadequate for bursty workloads.

To bridge this gap, we proposed and evaluated DRS, a dynamic strategy that leverages in-place scaling to adapt to real-time demand.

Our experiments show that DRS navigates the trade-offs among the QoS-based scenarios: it achieves a high success rate, approaching the reliability of Guaranteed, while reducing average wait times by more than 18%. Although it introduces a controlled slowdown, DRS prevents failures and avoids the severe performance degradation observed in the other scenarios.

This work demonstrates that an adaptive approach like DRS provides an effective path for running bursty workloads on Kubernetes. By prioritizing job completion while mitigating scheduling bottlenecks, it achieves a balanced trade-off between reliability and system throughput. Future work includes improving the reliability of DRS, extending Kubernetes' scheduling to better account for bursty behavior, and expanding the evaluation to encompass a wider range of applications and multi-node environments. Additionally, we plan to incorporate monetary cost considerations to optimize throughput while minimizing expenses in cloud-based environments through efficient co-execution within shared VMs. Future work includes improving DRS under high event rates, evaluating controller overhead, and extending experiments to multi-node deployments with heterogeneous nodes and latency-sensitive applications. We also plan to study scheduler interactions, consider CPU contention alongside memory pressure, and incorporate monetary cost factors to optimize throughput while reducing cloud expenses.

# Acknowledgments

This work was conducted in the context of the DecoHPC joint team https://team.inria.fr/decohpc/.

# References

[1] Maicon Melo Alves and Lúcia Maria de Assumpção Drummond. 2017. A multi-variate and quantitative model for predicting cross-application interference in virtual environments. *Journal of Systems and Software* 128 (2017), 150-163.

[2] Seyedeh Sheida Hosseini, Andrew M Chuen, and William M Chan. 2024. Computational aerodynamics study of the lift+ cruise vtol concept vehicle components. In *Transformative Vertical Flight (TVF) Meeting*.

[3] Daniel Medeiros, Jeremy J. Williams, Jacob Wahlgren, Leonardo Saud Maia Leite, and Ivy Peng. [n. d.]. ARC-V: Vertical Resource Adaptivity for HPC Workloads in Containerized Environments. ([n. d.]).

[4] Carlos H.Z. Nicodemus, Cristina Boeres, and Vinod E.F. Rebello. 2020. Managing Vertical Memory Elasticity in Containers. In *2020 IEEE/ACM 13th International Conference on Utility and Cloud Computing (UCC)*. 132-142. doi:10.1109/UCC48980.2020.00032

[5] Gourav Rattihalli, Madhusudhan Govindaraju, Hui Lu, and Devesh Tiwari. 2019. Exploring Potential for Non-Disruptive Vertical Auto Scaling and Resource Estimation in Kubernetes. In *2019 IEEE 12th International Conference on Cloud Computing (CLOUD)*. 33-40. doi:10.1109/CLOUD.2019.00018

[6] The Kubernetes Authors. 2025. Kubernetes Autoscaler: Vertical Pod Autoscaler. https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler. Accessed: August 13, 2025.

[7] The Kubernetes Authors. 2025. Kubernetes Documentation. https://kubernetes.io/docs/Accessed: 2025-08-14.

[8] The Kubernetes Authors (QoS Guide). 2025. Configure Quality of Service for Pods. https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/. Accessed: August 13, 2025.

[9] The Kubernetes Authors (Resources Guide). 2025. Resource Management for Pods and Containers. https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/. Accessed: August 13, 2025.

[10] Jianwei Yin, Xingjian Lu, Hanwei Chen, Xinkui Zhao, and Neal N Xiong. 2014. System resource utilization analysis and prediction for cloud based applications under bursty workloads. *Information Sciences* 279 (2014), 338-357.