{"id":"4b6f302c-10fd-4fa4-844d-1e56628e2a5c","arxiv_id":"2506.05693","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"Adding a disruption-detection layer to Smart HPA cuts CPU overutilization by up to 57.2% under simulated resource losses, but the experiments compare only with the authors' own baseline.","lead":"SecureSmart HPA is a Kubernetes auto-scaling extension that adds a layer to detect resource loss, such as pods going down, and then redistributes CPU capacity among microservices. In tests on the Online Boutique benchmark with simulated losses of 25%, 50%, and 75% of capacity, it reports cutting CPU overutilization by up to 57.2% and increasing allocated CPU by 51.1% relative to the authors' earlier Smart HPA.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Disruption injection as described cannot yield the claimed wastage: deleted pods are recreated by Kubernetes, and the reported High-severity Supply CPU (2002.5 mCPU) exceeds the stated remaining capacity (1587.5 mCPU).","rationale":"The reader's weakest assumption identifies the same load-bearing issue: the paper does not explain how deleting pods creates a sustained resource loss in Kubernetes. My reading confirms and sharpens this concern. Algorithm 2's detection logic depends on the current pod count remaining below the initial pod count; if the ReplicaSet controller recreates deleted pods, the disruption is transient and the measured behavior is not the claimed disruption scenario. Additionally, the reported numbers contain an internal inconsistency that reinforces the concern: at 75% wastage the remaining resource capacity is only 1587.5 mCPU, while Fig. 4(a) reports a High-severity Supply CPU of 2002.5 mCPU. Since Supply CPU is defined as allocated CPU to current replicas, this exceeds what the described pod deletions could leave available, independent of any convention about HPA design. This is a correctness risk internal to the paper's own setup, not merely a disagreement with existing practice. I do not see a flaw in the algorithmic architecture itself; the problem is that the central empirical claim is not backed by a reproducible and internally consistent disruption-injection procedure. The reader's CONDITIONAL verdict is therefore appropriate: the paper should not be accepted without a clear account of how persistent resource loss was achieved and without reconciling the High-severity supply number with the stated remaining capacity.","tokens_in":899,"tokens_out":809,"duration_ms":236913,"concrete_test":"Re-run the High-severity scenario using the exact protocol of Section IV-A6 while logging `kubectl get pods` (or deployment replica counts) every second from the 5.5-minute mark for 10 minutes. If the total running pods return to their pre-deletion count, or if the sum of CPU requests of running pods exceeds 1587.5 mCPU at any point after injection, the claimed 75% persistent wastage was not realized and the reported Supply CPU cannot be correct.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section IV-A6 states that disruptions are injected by \"randomly delete microservice pods\" to reach 25%, 50%, and 75% resource wastage, and Algorithm 2 infers disruption from a difference between initial capacity (sum ResReq_i × maxRi_i) and current capacity (sum ResReq_i × podi). In a standard Kubernetes Deployment, the ReplicaSet controller recreates deleted pods within seconds, so podi — and hence current resource capacity — returns to its pre-deletion value; the paper nowhere states that replica counts were scaled down, that a quota or node drain was used, or that pod recreation was otherwise blocked. Without a persistent reduction in podi, the \"resource wastage\" levels in Table II are not sustained, and the 9.5-minute post-disruption observation window measures normal operation rather than disruption. There is also an internal arithmetic inconsistency: with 75% wastage the remaining capacity is 1587.5 mCPU, yet Fig. 4(a) reports SecureSmart Supply CPU of 2002.5 mCPU at High severity. Since Supply CPU is defined as CPU resources allocated to current replicas, it cannot exceed the total requests of the remaining pods unless the described wastage was not actually applied. The headline improvements over Smart HPA therefore rest on an unspecified and internally inconsistent disruption-injection mechanism.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes SecureSmart HPA, a three-layered hierarchical auto-scaler for Kubernetes microservice architectures that extends the authors' prior Smart HPA with a disruption-detection and capacity-adjustment layer. The manuscript describes algorithms for microservice-level scaling (Algorithm 1), disruption detection and severity estimation (Algorithm 2), and resource redistribution among overprovisioned and underprovisioned services (Algorithm 3). The evaluation uses the Online Boutique benchmark on AWS EKS under three injected disruption severities (25%, 50%, and 75% resource wastage) and reports that SecureSmart HPA reduces CPU overutilization by up to 57.2% and increases resource allocation by up to 51.1% compared with Smart HPA. The central claim is that a disruption-aware HPA can maintain microservices closer to their CPU target after resource loss and allocate usable CPU more effectively than a disruption-blind but resource-exchanging baseline.","tokens_in":15185,"tokens_out":5730,"duration_ms":61812,"significance":"If the empirical claims hold, the paper makes a useful contribution: it identifies a real limitation of Kubernetes-style HPAs (their blindness to resource loss caused by faults, attacks, or maintenance) and proposes a concrete, clearly specified architectural extension with a heuristic resource-redistribution mechanism. A strength of the manuscript is that the algorithms are described with enough precision to be reimplemented, and the evaluation repeats each load test 10 times. However, the experimental validity currently rests on an underspecified and internally inconsistent disruption-injection procedure. The paper's contribution is therefore conditional on a sound experimental demonstration; as written, the headline improvements are not supported by the reported data.","major_comments":[{"comment":"The disruption-injection procedure as described cannot sustain the claimed wastage levels. The text states that disruptions are injected by deleting microservice pods to achieve 25%, 50%, and 75% resource wastage. In a standard Kubernetes Deployment, the ReplicaSet controller recreates deleted pods within seconds, so \"podi\" and hence the Current Resource Capacity calculated in Algorithm 2 would return to the pre-deletion values. The paper does not state that replica counts were scaled down, that a resource quota or node drain was used, or that pod recreation was otherwise prevented. Without a persistent reduction in \"podi\", the severity scenarios in Table II do not hold for the 9.5-minute post-injection observation window, and the evaluation would measure normal operation rather than disrupted operation. Please specify the actual mechanism used and provide evidence that \"podi\" remained reduced throughout the observation window.","section":"Section IV-A6 and Algorithm 2"},{"comment":"The reported Supply CPU at High severity is internally inconsistent with the stated remaining capacity. Table II fixes the remaining resource at High severity at 1587.5 mCPU (25% of the 6350 mCPU total), and Table I defines Supply CPU as the CPU resources allocated to the current replicas. Yet Fig. 4(a) reports SecureSmart HPA Supply CPU of 2002.50 mCPU at High severity. Since the current replicas' total requests cannot exceed the remaining capacity, this value should be at most 1587.5 mCPU unless the resource-exchange mechanism creates physical CPU resources, which it cannot. Please reconcile the metric definitions, the wastage arithmetic, and the reported values; the same inconsistency also affects the interpretation of the Medium and High severity comparisons in Fig. 6.","section":"Section IV-B1, Fig. 4(a), and Table II"},{"comment":"The performance comparisons supporting the abstract's headline claims (57.2% reduction in CPU overutilization and 51.1% increase in resource allocation) are reported without any measure of variability. Section IV-B states that each load test was repeated 10 times and average results were computed, but no error bars, standard deviations, confidence intervals, or significance tests are provided. Because the claims are relative improvements over a baseline in a public-cloud environment, the absence of dispersion information makes it impossible to assess whether the observed differences are robust. Please report per-trial distributions or statistical tests for the key metrics in Figs. 4 and 6.","section":"Section IV-B and Fig. 6"}],"minor_comments":[{"comment":"The random deletion procedure is underspecified: no random seed is given, and no algorithm is described for ensuring that the randomly selected microservices and replica counts sum exactly to the target wastage levels of 25%, 50%, and 75%. Without this, the severity labels may be approximate.","section":"Section IV-A6"},{"comment":"The sentence 'The final 741.00 mCPU represents the residual resource just before the 5.5-minute mark' is at odds with the surrounding paragraph, which describes post-disruption behavior; please clarify the time window over which each evaluation metric is averaged.","section":"Section IV-B1"},{"comment":"The notation \"podi\" is introduced in the algorithm header, but the prose refers to 'the total number of available pods for each microservice in real-time'; please clarify whether this is an instantaneous count or an average over the observation window.","section":"Algorithm 2"},{"comment":"The threats-to-validity section states that Smart HPA outperforms the Kubernetes baseline HPA, but this paper makes no direct comparison with the Kubernetes default HPA; please clarify that the baseline for the claimed improvements is the authors' own Smart HPA, and consider adding a direct default-HPA comparison or explicitly motivating its omission.","section":"Section V"}],"recommendation":"major_revision","confidential_remarks":"The central idea is reasonable and the algorithmic contribution is clearly presented, but the experimental evaluation must be substantially revised to be convincing. In particular, the authors need to specify a disruption-injection mechanism that actually produces persistent resource loss in Kubernetes, and they need to reconcile the Supply CPU values with the stated remaining capacities. If these issues are addressed with corrected experiments and statistics, the paper could become publishable; I do not see evidence of misconduct, only a currently invalid experimental description and internally inconsistent numbers."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper proposes SecureSmart HPA, a third layer on top of the authors' Smart HPA to detect resource loss and reallocate capacity during disruptions. That is a sensible idea, and the MAPE-K architecture is clearly laid out. The algorithms are readable, and the paper is honest about several limitations in Section V. Credit where due: the resource-redistribution heuristic is a natural extension, and the presentation is clean.\n\nThe problem is the experiment. The authors say they \"randomly delete microservice pods\" to create 25/50/75% resource wastage and that the system keeps running for another 9.5 minutes. In standard Kubernetes, a Deployment's ReplicaSet recreates deleted pods within seconds. Nothing in the paper says replica counts were scaled down, quotas imposed, or pod recreation blocked. So the described procedure would not yield a persistent resource loss. The current capacity (sum of ResReq_i * pod_i) would return to the initial value, and the disruption detector would see no loss.\n\nThis is not a minor gap. The headline numbers rest on it. There is also a concrete internal inconsistency: with 75% wastage (remaining capacity 1587.5 mCPU), Figure 4 reports Supply CPU of 2002.5 mCPU. Since Supply CPU is defined as the CPU allocated to current replicas, it cannot exceed the total requests of the remaining pods. Either the wastage was not applied as claimed, or the pods were recreated—both undermine the experiment.\n\nThe comparison against Smart HPA is also narrow: it is their own prior system, and the added detection layer is exactly the variable being tested. No error bars or significance tests are reported, and no code or data is shipped. These are secondary issues but would matter even after fixing the injection.\n\nWho gets value from this? Someone working on disruption-aware auto-scaling might find the architecture a useful starting point, but only as a design sketch. As an empirical claim, the paper currently does not support its own conclusions.\n\nRecommendation: send it to peer review, but with the expectation of major revision. The idea is worth engaging with; the current experimental validation is not. An editor should ask for a correct disruption-injection mechanism, a baseline that includes the standard Kubernetes HPA, and a check that reported Supply CPU never exceeds remaining capacity.","headline":"A sensible architectural extension undermined by a load-bearing experimental flaw: the described pod-deletion procedure cannot produce persistent resource loss, and the reported Supply CPU numbers contradict the stated remaining capacity.","tokens_in":15681,"tokens_out":4186,"would_cite":false,"duration_ms":39645,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A disruption-aware auto-scaler detects lost pods and reallocates CPU capacity, reducing overutilization by up to 57.2% and increasing allocated CPU by up to 51.1% versus the disruption-blind Smart HPA.","keywords":["microservices","horizontal pod auto-scaling","Kubernetes","resource disruptions","resource allocation","self-adaptive systems","CPU overutilization","resilience"],"falsifier":"Record the live pod count of each microservice for the ten minutes after the disruption is injected; if the counts return to their pre-deletion values within seconds, the claimed 25%, 50%, and 75% wastage levels did not persist, and the measured overutilization reductions cannot be attributed to the simulated disruptions.","tokens_in":14731,"feed_emoji":"☁️","tokens_out":7425,"duration_ms":69446,"temperature":0.7,"pith_summary":"SecureSmart HPA is a proposed extension of a Kubernetes horizontal pod auto-scaler (HPA) that makes scaling decisions aware of resource loss caused by faults, attacks, or maintenance. The paper's central claim is that by detecting when live pods are missing, updating each service's capacity to match reality, and moving unused capacity from overprovisioned to underprovisioned services, an auto-scaler can keep CPU use closer to its target after a disruption. In load tests on an 11-service e-commerce benchmark microservice application run on Kubernetes, the authors report that SecureSmart HPA outperforms its disruption-blind predecessor Smart HPA at 25%, 50%, and 75% simulated resource wastage, with up to a 57.2% reduction in CPU overutilization and a 51.1% increase in CPU allocation. If true, this would matter because real microservice deployments face faults and attacks that currently leave auto-scalers planning against capacities they no longer have.","feed_headline":"Disruption-aware auto-scaler cuts CPU overuse by 57 percent","feed_subtitle":"SecureSmart HPA detects lost pods and reallocates capacity, beating the disruption-blind baseline in Kubernetes tests.","key_machinery":"The load-bearing mechanism is the resource-loss detection and reallocation loop carried by the Application Capacity Manager and Application Resource Manager. The capacity manager computes resource loss as $\\text{IRC} - \\text{CRC}$, where $\\text{IRC} = \\sum_i \\text{ResReq}_i \\times \\max R_i$ and $\\text{CRC} = \\sum_i \\text{ResReq}_i \\times \\text{pod}_i$, converts the loss to a severity percentage, and updates each microservice's maximum replicas to its live pod count. The resource manager then sorts underprovisioned services by unmet demand and overprovisioned services by surplus, transfers capacity from the most overprovisioned to the most underprovisioned, and issues scaled replica counts within the updated capacities. This loop is what lets scaling decisions track actual available resources after a disruption.","core_discovery":"The central claim is that an HPA can be made resilient to resource disruptions by adding a dedicated capacity-management layer between per-service scaling and application-level resource redistribution. The new layer compares each microservice's initial capacity (maximum replicas times per-replica CPU request) with its current capacity (live pods times request); any positive difference is treated as a disruption, and every service's maximum replica count is capped at its current live-pod count. A centralized resource manager then collects the deficits of underprovisioned services and the surplus of overprovisioned ones, sorts both lists by size, and transfers capacity from the largest surplus to the largest deficit. The authors report that this mechanism reduces CPU overutilization by up to 57.2% and increases CPU supply by up to 51.1% relative to Smart HPA across low, medium, and high disruption severities.","pith_inferences":["Beyond the paper, the same detector could be extended to classify the cause of a pod shortfall, such as attack, fault, or routine scale-down, since the current logic treats any positive capacity gap as a disruption.","Beyond the paper, the greedy largest-deficit/largest-surplus matching in Algorithm 3 could be compared against other allocation policies to separate the benefit of capacity correction from the benefit of the matching rule.","Beyond the paper, publishing the raw pod-count or capacity traces after disruption would let readers verify that the simulated wastage persisted and would make the replication of the results direct."],"forward_implications":["If the measured gains hold, an HPA that corrects capacities after pod loss can keep CPU utilization closer to its threshold after disruptions at every tested severity.","At medium severity, the corrected capacities let the application use about half again as much CPU as the baseline, showing that disruption awareness prevents scaling attempts into unavailable resources.","Because the heuristics operate on resource demand and capacity rather than service-specific logic, they can be paired with other scaling policies and metrics such as response time.","At high severity, the system still stabilizes CPU utilization above the threshold but avoids the near-200% overutilization seen with the baseline."],"supporting_citations":[{"why":"Defines Smart HPA, the prior auto-scaler that SecureSmart HPA extends and the baseline in every comparison.","marker":"[12]"},{"why":"Describes Kubernetes Horizontal Pod Autoscaling, the standard mechanism SecureSmart HPA modifies.","marker":"[9]"},{"why":"Motivates hierarchical scaling architectures for Kubernetes microservices, the design pattern SecureSmart HPA adopts.","marker":"[8]"},{"why":"Documents resource disruptions in microservice systems, the failure scenario SecureSmart HPA is built to detect.","marker":"[13]"},{"why":"Supplies the benchmark microservice application used in all load tests.","marker":"[31]"},{"why":"Provides the load-testing tool that generates the simulated user workload and request patterns.","marker":"[36]"}],"fun_headline_variants":["Disruption-aware auto-scaler cuts CPU waste by 57%","SecureSmart HPA: 57% less CPU overuse amid disruptions","Kubernetes auto-scaling survives faults, reallocates capacity","Resilient scaling boosts resource sharing by 51% in tests"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that deleting microservice pods creates a resource shortage that lasts for the rest of the load test; in Kubernetes, the ReplicaSet controller normally recreates deleted pods within seconds, and the paper does not say how that recreation was prevented.","fun_headline_variants_meta":{"raw":{"variants":["Disruption-aware auto-scaler cuts CPU waste by 57%","SecureSmart HPA: 57% less CPU overuse amid disruptions","Kubernetes auto-scaling survives faults, reallocates capacity","Resilient scaling boosts resource sharing by 51% in tests"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000306,"raw_usage":{"total_tokens":1752,"prompt_tokens":943,"completion_tokens":809,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":559,"completion_tokens_details":{"reasoning_tokens":732}},"tokens_in":559,"tokens_out":809,"duration_ms":8402,"temperature":1.0,"reasoning_tokens":732,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T10:13:32.434165+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Record the live pod count of each microservice for the ten minutes after the disruption is injected; if the counts return to their pre-deletion values within seconds, the claimed 25%, 50%, and 75% wastage levels did not persist, and the measured overutilization reductions cannot be attributed to the simulated disruptions.","supporting_citations":[{"cited_title":"Smart HPA: A resource- efficient horizontal pod auto-scaler for microservice architectures,","cited_arxiv_id":null,"evidence_quote":"Defines Smart HPA, the prior auto-scaler that SecureSmart HPA extends and the baseline in every comparison."},{"cited_title":"Horizontal pod autoscaling in kubernetes for elastic container orchestration,","cited_arxiv_id":null,"evidence_quote":"Describes Kubernetes Horizontal Pod Autoscaling, the standard mechanism SecureSmart HPA modifies."},{"cited_title":"Hierarchical scaling of microservices in kubernetes,","cited_arxiv_id":null,"evidence_quote":"Motivates hierarchical scaling architectures for Kubernetes microservices, the design pattern SecureSmart HPA adopts."},{"cited_title":"Online boutique","cited_arxiv_id":null,"evidence_quote":"Supplies the benchmark microservice application used in all load tests."},{"cited_title":"Load testing tool","cited_arxiv_id":null,"evidence_quote":"Provides the load-testing tool that generates the simulated user workload and request patterns."}],"review_version":1}