Pith. sign in

REVIEW 3 major objections 6 minor 32 references

ARBITER claims that SLO-driven Kubernetes remediation can safely include LLM planners: the model only proposes a finite typed action, and deterministic validators, budgets, approval, and bounded execution decide whether any cluster mutation

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-01 13:14 UTC pith:MYP6WMYL

load-bearing objection ARBITER is a well-scoped, honest systems paper: the typed-action/validation substrate is genuinely useful, and the live rollback results are convincing, but the critical-path target mapping is validated only in an easiest-case scenario and the agentic-extension evidence is thin. the 3 major comments →

arxiv 2607.19182 v2 pith:MYP6WMYL submitted 2026-07-21 cs.DC

ARBITER: Guarded Agentic Control for SLO-Oriented Kubernetes Remediation

Pooyan Habibi , Alberto Leon-Garcia This is my paper
classification cs.DC
keywords Kubernetesservice-level objectivesOpenTelemetrydistributed tracingagentic controlsafe AI operationsautoscalingmicroservices
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper tries to establish a design principle for AI-driven cloud operations: the reasoning that decides what to fix can be agentic, but the authority to change a running cluster must sit in deterministic code. ARBITER implements that split with a bounded DiagnosisContext that correlates OpenTelemetry traces with Kubernetes placement and recent-change history, and a finite typed-action interface of four actions (scale, resize, evict, roll back). In live faults on a social-network microservice benchmark, the system chose rollback_canary in ten of ten bad-image deployments — both CPU-burn and pure-latency — where HPA either scaled the faulty image or never triggered; and it redirected remediation from a breached frontend to the responsible downstream service in five of five replicates, which resource-only control never did. If the claims hold, agentic operators become replaceable hypothesis generators behind a safety substrate, and SLO control extends beyond autoscaling to rollbacks, placement repair, and target selection.

Core claim

The central claim is that SLO-oriented remediation should be a guarded translation problem: OpenTelemetry and Kubernetes state are correlated into a bounded DiagnosisContext; planners — deterministic rules or an LLM — consume that context and emit one finite-vocabulary typed action; and only a deterministic safety validator, policy gates, budget checks, approval, pre-state capture, and bounded execution can mutate the cluster. ARBITER realizes this with four actions: scale_out, resize_cpu, deschedule_one, and rollback_canary. In live evaluation, the deterministic planner and a live approval-gated LLM harness both targeted the remediable downstream Deployment in all replicates of a critical-p

What carries the argument

The load-bearing mechanism is the causal resource graph: a time-indexed heterogeneous graph that correlates request spans with workload identity, pod placement, node pressure, and recent-change history. The graph answers intervention-oriented queries — most notably critical-path extraction, which resolves an SLO breach observed at a frontend to the Deployment that dominates the request's tail latency. From the graph the controller assembles a bounded DiagnosisContext (six fields: symptom, critical path, resource evidence, placement evidence, recent changes, allowed actions) that is the sole input to planners. The second half of the machinery is the typed intervention envelope: each of the fo

Load-bearing premise

The load-bearing assumption is that the slowest service on the recent request critical path is the remediable bottleneck; the evaluation only injects faults that guarantee that mapping, so the system is unproven when the dominant span is an innocent bystander such as an unhealthy-but-not-causal hop, an uninstrumented service, or a retry-amplified downstream.

What would settle it

Run the controller on a cluster where retry storms or queue buildup at a frontend make a healthy downstream service appear as the dominant critical-path span, and watch whether it attempts remediation against that healthy service; a correct design should abstain from mutation when the dominant span is not a mutable cause.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • A single typed-action interface can cover rollback, resource scaling, placement repair, and critical-path target redirection, so SLO control generalizes beyond autoscaling.
  • LLM planners can be dropped into the planning slot without weakening safety: three pinned models agreed with the deterministic planner on all thirty regression contexts, and every adversarial input was rejected before execution.
  • Pure-latency regressions that produce no CPU signal still get rolled back, whereas HPA never reacts and throughput drops roughly by half.
  • The substrate transfers to a second microservice benchmark with only configuration changes and no controller code changes.
  • Agentic planning can extend the deterministic rule set: models noticed a long-tail co-location field the rules did not consult, pointing to planner-rule hybrid designs on the same interface.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The critical-path evidence has only been validated on faults engineered so the dominant span is the true culprit; in real clusters that span could be a healthy-but-slow hop, an uninstrumented service, or retry amplification, so a 'remediability gate' that checks whether the proposed target is owned and actionable before approval would harden the system.
  • The live-gated LLM path added several seconds of latency over the deterministic path, so latency-critical production use would likely run the deterministic planner as the hot path and treat the LLM as a novelty detector in parallel.
  • Because the graph records intervention outcomes back as vertices, a natural extension is to learn which action types actually resolve which evidence patterns, turning the diagnostic store into a learning substrate.
  • The HPA blindness on latency-only faults implies that autoscaling itself could benefit from change-history awareness; a resource-only controller will not catch an entire class of rollback-worthy faults.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper presents ARBITER, a Kubernetes control plane that translates OpenTelemetry traces and cluster state into bounded DiagnosisContext objects, and lets deterministic or LLM-based planners emit finite typed remediation actions. A deterministic validator, policy gates, budgets, approval, pre-state capture, and rollback monitors guard all cluster mutations. The evaluation uses DeathStarBench Social Network and Online Boutique: deployment regressions are rolled back in 10/10 runs, a downstream critical-path target is selected in 5/5 deterministic and 5/5 live-gated Sonnet runs, placement repair succeeds in 5/5 runs, and a validator/replay ablation shows 77/78 well-formed agent outputs allowed with 11/11 adversarial rejections. Additional tracks cover Online Boutique portability, offline model replay, and KWOK-based control-plane scale.

Significance. If substantiated, the architecture is a useful contribution to safe SLO-oriented cloud remediation: separating untrusted planners from a deterministic, policy-gated execution substrate is a credible way to make LLM-based operations safe. The paper is honest about claim boundaries, separates live-runtime evidence from fake-node scale evidence, and ships a substantial reproducible artifact set (controller, DSB-RegCtx corpus, harnesses, safety tests, figure scripts). The deterministic rollback results and the safety-validator results are convincing engineering evidence. The weakest link is the evidence-to-target mapping behind the critical-path claim: the only live validation is structurally engineered to make the correct target the dominant span, and the agentic target-selection result is partly enforced by the deterministic semantic guard.

major comments (3)
  1. [§4.2, §6, §8.2] The Q2 result (Fig. 8) is the sole live validation of critical-path-based target redirection, but the experiment injects CPU pressure directly onto the node running home-timeline-service. This guarantees the injected service dominates the downstream span of read-home-timeline requests, so the test cannot distinguish ‘identifies the remediable bottleneck from trace evidence’ from ‘the injection makes the correct target the only visible dominant span.’ The paper defines critical_path as ‘the chain from the slowest root in the last 60 s’ (§6) and explicitly disclaims formal causal identification (§4.2). Real clusters can present healthy slow hops, uninstrumented services, retry/queue amplification, or external dependencies, none of which are evaluated. The §11 claim that the substrate supports ‘right downstream target’ therefore needs additional experiments with ambiguous dominant-span evid
  2. [§5, §8.2] The live-gated Sonnet result does not provide independent evidence of agentic target selection. §5 states that when critical_path names a downstream Deployment different from the breached frontend, an agent-emitted resize_cpu/scale_out must target that downstream Deployment or the harness refuses to create the RemediationPlan. Since Q2’s metric is target correctness and the live Sonnet run passes through this semantic guard, the 5/5 downstream targeting is enforced by the deterministic guard, not demonstrated by the model. To support ‘target correctness across planners’ (Fig. 8 caption), the paper should report the model’s raw proposals before the guard is applied, or run a diagnostic pass with the guard disabled and compare targets.
  3. [§8.5] The long-tail extension result is weakened by an explicitly disclosed artifact: the noisy-neighbor context ‘carries the field hand-authored’ for placement_evidence.colocated_workloads because it predates the graph population of that field. The three pinned models choose deschedule_one citing this hand-authored field. As presented, this is a controlled synthetic demonstration, not evidence that the agentic planner extends the deterministic substrate on live graph output. The context should be re-captured from the live graph, or the result should be labeled as a synthetic scenario, before claiming extensibility.
minor comments (6)
  1. [§8.1–§8.3] The headline 10/10 and 5/5 results are reported without confidence intervals or exact binomial bounds. With N=5 per condition, a perfect run is consistent with a wide range of true success rates; state this limitation or provide interval estimates.
  2. [Figures 6–9] Bar charts generally lack error bars or per-replicate scatter. The text reports standard deviations for some conditions (e.g., 79.4±5.4 s, 398.3±3.5 RPS) but not for all conditions in the placement matrix (Fig. 9), making visual comparisons harder.
  3. [§5, Table 3] Table 3 catalogs gate behavior but does not map the 11 adversarial inputs to the specific gate categories they exercise. A per-input mapping would strengthen the safety claim.
  4. [§8.4] The CPU-pressure fallback is appropriately flagged as non-SLO evidence, but the text could state more directly that this run validates executor/fallback behavior only and does not support the SLO-remediation claim, since no p99 observations occurred in the pressure window.
  5. [§8.7] The 10k-node KWOK run did not complete. The conclusion should avoid implying control-plane evidence beyond the completed 1k and 5k runs; the current text already mostly respects this, but the abstract’s mention of ‘scale evidence’ could be read too broadly.
  6. [Listing 1] The listing omits critical_path with no in-listing explanation. A short note that this is a regression case and the field is populated when a recent root span dominates would prevent reader confusion.

Circularity Check

1 steps flagged

Disclosed guard and injection design force the headline target-selection result; central architecture remains non-circular.

specific steps
  1. self definitional [§5 Safety model (semantic guard); §8.2 Critical-path downstream targeting; Abstract]
    "when a DiagnosisContext contains a nonzero-duration downstream critical_path Deployment that differs from the breached frontend, an agent-emitted resize_cpu or scale_out must target that downstream Deployment or the harness refuses to create the RemediationPlan. ... The live-gated Sonnet harness also executes the downstream target in every replicate (5/5)."

    The live-gated Sonnet 5/5 downstream-target result is not an independent planner outcome: the harness's semantic guard rejects any agent-emitted resize/scale plan that does not target the downstream Deployment whenever critical_path evidence is present. Therefore the reported 'target correctness across planners' is entailed by the deterministic guard, not by the model's planning. The paper discloses the guard ('The guard does not choose the action for the agent; it prevents semantically inconsistent outputs'), which reduces but does not remove the construction-forced nature of the result.

full rationale

ARBITER is primarily an empirical systems paper, not a formal derivation; its deterministic rollback, placement, and portability results are live end-to-end executions of the implemented controller against an external cluster and are not circular. The deployment-regression branch (rollback_canary when recent_changes shows an image flip in the 240 s window) is a rule executed on injected faults; that is normal engineering validation, not a fit renamed as prediction. The critical-path Q2 experiment is a controlled positive instance: injecting CPU pressure directly on the node hosting home-timeline-service guarantees that service is the dominant downstream span, so it validates the dominance heuristic only in an unambiguous scenario; the paper explicitly disclaims formal causal identification and this remains a validation gap rather than a circularity. The one construction-forced result is the live-gated Sonnet 5/5 downstream targeting, which is enforced by the semantic guard; the paper discloses this, and the broader agentic-extensibility claim rests on the offline replay rather than on that forced result. Self-citation ([11] AgileSphere, same authors) is confined to related work and is not load-bearing. Overall, the central architecture and safety-substrate claims have independent content; the score reflects the one disclosed but logically forced evaluation result.

Axiom & Free-Parameter Ledger

7 free parameters · 6 axioms · 1 invented entities

ARBITER pulls its evidence model from OpenTelemetry traces and Kubernetes object state, so there are no exotic invented entities (no new particles, forces, or dimensions). The ledger's load is carried by telemetry-to-target mapping assumptions, hand-set control thresholds, and the semantic guard that partially determines the agentic result. The heaviest assumption is trace-critical-path-is-bottleneck, which the Q2 evaluation never challenges because the fault is injected directly onto the target's node. The most fitting-like element is the undisclosed CONF/COST arithmetic behind the deterministic scorer's 0.83/0.52 ranking in §8.5.

free parameters (7)
  • recent-change proximity window = 240 s
    Deployment-regression predicate fires only if an image flip in recent_changes falls within this window of the symptom (§4.3, §6). The evaluation injects the image change at T+60 s inside the window; the threshold is hand-chosen and determines whether rollback_canary fires.
  • critical-path lookback = 60 s
    Graph attaches 'the chain from the slowest root in the last 60 s' to critical_path (§6). Hand-chosen; determines whether downstream evidence is present for the Q2 target redirect.
  • node-CPU deschedule threshold = NodeCPU ≥ 70%
    deschedule_one is considered only when NodeCPU ≥ 70% (§4.3). Hand-chosen gating for placement repair; not derived from SLO data.
  • scorer cost weight = 0.2
    arg max_a CONF(a) − 0.2·COST(a) (§4.3). Together with undisclosed per-action CONF/COST values it produces the 0.83 (resize_cpu) vs 0.52 (deschedule_one) ranking in §8.5 that the paper calls 'intentionally suboptimal'; the constituent values are not given.
  • per-action confidence values (CONF) = undisclosed
    Deterministic branches assign confidences entering the scorer; the reported 0.83/0.52 scores cannot be recomputed from the text because CONF/COST are not tabulated (§4.3, §8.5). This is the paper's most fitting-like element.
  • validator auto-allow confidence threshold = 0.85 default; 0.95 deployed
    Actions below the threshold are classified require_approval (§5). The paper asserts it is not tuned on evaluation workloads; still a hand-set constant. All experiments use the approval-required path, so it does not affect reported outcomes.
  • safety budget caps = MaxReplicasDelta=1, MaxCPUDelta=0.1, MaxMemoryDeltaMiB, MaxEvictions=1
    Four-axis budget (§5, Table 2); hand-set action caps defining the evaluated vocabulary, including the replicas=3 refusal that is the single denied replay (§8.5).
axioms (6)
  • domain assumption Trace parent-child structure and exclusive wall time along the longest child chain identify the dominant remediable request-path bottleneck
    §4.2/Fig. 3; the graph is explicitly operational: 'does not claim formal causal identification' (§4.2). Q2 injects pressure on the host of home-timeline-service so the fault is guaranteed to dominate the trace; off-path bottlenecks (queues, retries, external dependencies, uninstrumented services) would break the redirect.
  • domain assumption OpenTelemetry trace coverage spans the full user-visible request path of the monitored applications
    §4.1 and §10: 'diagnosis quality depends on telemetry coverage'. If a critical-path service is uninstrumented or tail-sampled out, critical_path[] is incomplete and target redirection may select the wrong deployment.
  • domain assumption A recent image flip within 240 s of a latency breach is the cause of the breach, so rollback is the right remediation
    §4.3 deployment-regression predicate. Evaluated only for isolated bad-image rollouts (no noisy neighbors, no pre-existing pressure, §8.1); coincidental rollouts or rollback-averse scenarios are untested.
  • domain assumption Pod co-location edges represent harmful interference for placement repair
    §4.2, §8.3: evidential co-location edge with co-residency window, overlap, temporal support, and confidence. The placement experiment does not show SLO benefit — ARBITER placement is slower on p99 and throughput than HPA (§8.3).
  • ad hoc to paper Semantic guard: if critical_path names a downstream Deployment different from the breached frontend, agent-emitted resize_cpu/scale_out must target the downstream Deployment
    §5. This deterministic rule is why the live-gated Sonnet 5/5 downstream-target result is partially enforced rather than independently agent-chosen. Disclosed as a design rule, but it shapes the headline agentic result.
  • ad hoc to paper Approval-required execution path with a harness that approves validator-passing plans is a fair stand-in for operator approval
    §5, §6: 'the experiment harness approves validator-passing plans for repeatability'. The evaluation never exercises a live human approver or the require_approval denial path.
invented entities (1)
  • RemediationPlan custom resource (CRD) independent evidence
    purpose: Durable mutation envelope storing the typed action, evidence, approval state, pre-state, phase, and observed effect (§6).
    New Kubernetes CRD introduced by the paper, but it ships in the open-source repository and is exercised by all live experiments, so there is a falsifiable handle outside the paper. It is a software artifact, not a speculative physical entity.

pith-pipeline@v1.3.0-alltime-deepseek · 20114 in / 23010 out tokens · 240345 ms · 2026-08-01T13:14:37.648688+00:00 · methodology

0 comments
read the original abstract

Maintaining service-level objectives (SLOs) on Kubernetes microservices remains difficult because autoscalers observe coarse resource metrics, recent SLO controllers often depend on custom telemetry, and unconstrained agentic operators cannot safely mutate production clusters. We present ARBITER, a guarded control plane for SLO-oriented Kubernetes remediation. ARBITER builds an OpenTelemetry-native causal resource graph, assembles bounded DiagnosisContext objects, and exposes a finite typed-action interface that separates planning from execution. The same interface supports deterministic planners and an LLM-backed planning harness, with deterministic schema checks, policy gates, resource/disruption budgets, approval, and bounded execution forming the safety substrate. We evaluate ARBITER on a 4-node Kubernetes cluster using DeathStarBench Social Network and Online Boutique. The evaluation tests two forms of SLO-oriented control that resource autoscaling alone does not provide: selecting the right remediation action and selecting the right downstream target. For bad-image deployment regressions, ARBITER selects rollback_canary in all ten CPU-burn and pure-latency runs; HPA either scales the faulty image or never triggers. For a downstream critical-path fault, the user-visible breach appears at the frontend, but trace evidence identifies home-timeline-service as the remediable bottleneck. Deterministic ARBITER and a live approval-gated Sonnet harness target that downstream service in every replicate, whereas HPA/resource-only control never does. Additional experiments cover guarded placement repair, Online Boutique portability, adversarial safety rejection, offline multi-model replay, and KWOK-based control-plane scale evidence. We release the controller, replay corpus, harnesses, safety tests, and figure artifacts: https://github.com/pooyan/arbiter.

Figures

Figures reproduced from arXiv: 2607.19182 by Alberto Leon-Garcia, Pooyan Habibi.

Figure 1
Figure 1. Figure 1: ARBITER architecture. Telemetry from applications and the cluster ( [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Causal resource graph ( 2 of [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Critical-path query output for one DSB read-home-timeline request from a real OTLP trace. Bars show per-span wall time with a diagonal scale break; indentation marks parent–child depth; the right column shows live Kubernetes placement correlated with the trace by the controller. Deployment when critical_path disagrees with the breached frontend. When no stronger predicate ap￾plies, the planner considers bo… view at source ↗
Figure 4
Figure 4. Figure 4: Guarded execution state machine ( 4 – 5 of [PITH_FULL_IMAGE:figures/full_fig_p007_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Evaluated DeathStarBench Social Network request path and fault [PITH_FULL_IMAGE:figures/full_fig_p009_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Deployment-regression scenario, CPU-burn flavor at [PITH_FULL_IMAGE:figures/full_fig_p010_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Deployment-regression scenario, pure-latency flavor at [PITH_FULL_IMAGE:figures/full_fig_p011_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: DeathStarBench critical-path downstream fault. The breached request enters through [PITH_FULL_IMAGE:figures/full_fig_p012_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: DeathStarBench noisy-neighbor placement repair, [PITH_FULL_IMAGE:figures/full_fig_p013_9.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

32 extracted references · 1 linked inside Pith

  1. [1]

    FIRM: An intelligent fine-grained resource manage- ment framework for SLO-oriented microservices,

    H. Qiuet al., “FIRM: An intelligent fine-grained resource manage- ment framework for SLO-oriented microservices,” inProceedings of the 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2020, pp. 805–825

    2020

  2. [2]

    Autothrottle: A practical bi-level approach to resource management for SLO-targeted microservices,

    Z. Wanget al., “Autothrottle: A practical bi-level approach to resource management for SLO-targeted microservices,” inProceed- ings of the 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI). Santa Clara, CA: USENIX Association, 2024, pp. 149–165. 15

    2024

  3. [3]

    OpenTelemetry collector for Kubernetes,

    OpenTelemetry, “OpenTelemetry collector for Kubernetes,” 2026. [Online]. Available: https://opentelemetry.io/docs/platforms/ kubernetes/collector/

    2026

  4. [4]

    Scheduling framework,

    Kubernetes, “Scheduling framework,” 2026. [Online]. Available: https://kubernetes.io/docs/concepts/scheduling-eviction/sche duling-framework/

    2026

  5. [5]

    KWOK: Kubernetes without Kubelet,

    Kubernetes SIGs, “KWOK: Kubernetes without Kubelet,” 2026. [Online]. Available: https://kwok.sigs.k8s.io/

    2026

  6. [6]

    kube-burner documentation,

    kube-burner, “kube-burner documentation,” 2026. [Online]. Available: https://kube-burner.github.io/kube-burner/v1.16.1/

    2026

  7. [7]

    ClusterLoader2 performance tests,

    Kubernetes, “ClusterLoader2 performance tests,” 2026. [Online]. Available: https://github.com/kubernetes/perf-tests/tree/mast er/clusterloader2

    2026

  8. [8]

    Sinan: ML-based and QoS-aware resource man- agement for cloud microservices,

    Y. Zhanget al., “Sinan: ML-based and QoS-aware resource man- agement for cloud microservices,” inProceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS). ACM, 2021, pp. 167– 181

    2021

  9. [9]

    GRAF: A graph neural network based proactive resource allocation framework for SLO-oriented microservices,

    J. Parket al., “GRAF: A graph neural network based proactive resource allocation framework for SLO-oriented microservices,” inProceedings of the 17th International Conference on Emerging Net- working Experiments and T echnologies (CoNEXT), 2021, pp. 154–167

    2021

  10. [10]

    AutoMan: Resource-efficient provisioning with tail latency guarantees for microservices,

    B. Caiet al., “AutoMan: Resource-efficient provisioning with tail latency guarantees for microservices,”Future Generation Computer Systems, vol. 143, pp. 61–75, 2023

    2023

  11. [11]

    AgileSphere: Predictive- reactive Kubernetes cluster autoscaling with warm-pool node promotion,

    P . Habibi, S. Rawat, and A. Leon-Garcia, “AgileSphere: Predictive- reactive Kubernetes cluster autoscaling with warm-pool node promotion,”IEEE Access, vol. 14, 2026

    2026

  12. [12]

    Sage: Practical and scalable ML-driven performance debugging in microservices,

    Y. Ganet al., “Sage: Practical and scalable ML-driven performance debugging in microservices,” inProceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), 2021, pp. 135–151

    2021

  13. [13]

    Seer: Leveraging big data to navigate the complexity of performance debugging in cloud microservices,

    Y. Ganet al., “Seer: Leveraging big data to navigate the complexity of performance debugging in cloud microservices,” inProceedings of the 24th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS). ACM, 2019, pp. 19–33

    2019

  14. [14]

    MicroRCA: Root cause localization of performance issues in microservices,

    L. Wuet al., “MicroRCA: Root cause localization of performance issues in microservices,” inProceedings of the IEEE/IFIP Network Operations and Management Symposium (NOMS), 2020, pp. 1–9

    2020

  15. [15]

    Sieve: Actionable insights from monitored metrics in distributed systems,

    J. Thalheimet al., “Sieve: Actionable insights from monitored metrics in distributed systems,” inProceedings of the 18th ACM/I- FIP/USENIX Middleware Conference. ACM, 2017, pp. 14–27

    2017

  16. [16]

    Recommending root-cause and mitigation steps for cloud incidents using large language models,

    T. Ahmedet al., “Recommending root-cause and mitigation steps for cloud incidents using large language models,” inProceedings of the 45th IEEE/ACM International Conference on Software Engineering (ICSE). IEEE, 2023, pp. 1737–1749

    2023

  17. [17]

    Automatic root cause analysis via large language models for cloud incidents,

    Y. Chenet al., “Automatic root cause analysis via large language models for cloud incidents,” inProceedings of the 19th European Conference on Computer Systems (EuroSys). ACM, 2024, pp. 674– 688

    2024

  18. [18]

    RCAgent: Cloud root cause analysis by au- tonomous agents with tool-augmented large language models,

    Z. Wanget al., “RCAgent: Cloud root cause analysis by au- tonomous agents with tool-augmented large language models,” in Proceedings of the 33rd ACM International Conference on Information and Knowledge Management (CIKM). ACM, 2024, pp. 4966–4974

    2024

  19. [19]

    AIOpsLab: A holistic framework to evalu- ate ai agents for enabling autonomous clouds,

    Y. Chenet al., “AIOpsLab: A holistic framework to evalu- ate ai agents for enabling autonomous clouds,”arXiv preprint arXiv:2501.06706, 2025

    Pith/arXiv arXiv 2025

  20. [20]

    Large-scale cluster management at Google with Borg,

    A. Vermaet al., “Large-scale cluster management at Google with Borg,” inProceedings of the T enth European Conference on Computer Systems (EuroSys). ACM, 2015, pp. 1–17

    2015

  21. [21]

    Omega: Flexible, scalable schedulers for large compute clusters,

    M. Schwarzkopfet al., “Omega: Flexible, scalable schedulers for large compute clusters,” inProceedings of the European Conference on Computer Systems (EuroSys). ACM, 2013, pp. 351–364

    2013

  22. [22]

    Borg, Omega, and Kubernetes,

    B. Burnset al., “Borg, Omega, and Kubernetes,”Communications of the ACM, vol. 59, no. 5, pp. 50–57, 2016

    2016

  23. [23]

    Kubernetes scheduling: Taxonomy, ongoing issues and challenges,

    C. Carri ´on, “Kubernetes scheduling: Taxonomy, ongoing issues and challenges,”ACM Computing Surveys, vol. 55, no. 7, pp. 138:1– 138:37, 2023

    2023

  24. [24]

    Custom scheduling in Kubernetes: A survey on common problems and solution approaches,

    Z. Rejiba and J. Chamanara, “Custom scheduling in Kubernetes: A survey on common problems and solution approaches,”ACM Computing Surveys, vol. 55, no. 7, pp. 151:1–151:37, 2023

    2023

  25. [25]

    A survey of Kubernetes scheduling algorithms,

    K. Senjabet al., “A survey of Kubernetes scheduling algorithms,” Journal of Cloud Computing, vol. 12, no. 1, p. 87, 2023

    2023

  26. [26]

    Extending the Kubernetes plat- form with network-aware scheduling capabilities,

    A. Marchese and O. Tomarchio, “Extending the Kubernetes plat- form with network-aware scheduling capabilities,” inService- Oriented Computing, ser. Lecture Notes in Computer Science. Cham: Springer, 2022, vol. 13740, pp. 465–480

    2022

  27. [27]

    Communication-aware schedul- ing of microservices-based applications on Kubernetes clusters,

    A. Marchese and O. Tomarchio, “Communication-aware schedul- ing of microservices-based applications on Kubernetes clusters,” inProceedings of the 12th International Conference on Cloud Computing and Services Science (CLOSER). SCITEPRESS, 2022, pp. 190–198

    2022

  28. [28]

    Topology-aware scheduling framework for microser- vice applications in cloud,

    X. Liet al., “Topology-aware scheduling framework for microser- vice applications in cloud,”IEEE T ransactions on Parallel and Dis- tributed Systems, vol. 34, no. 5, pp. 1635–1649, 2023

    2023

  29. [29]

    DRS: A deep reinforcement learning enhanced Kubernetes scheduler for microservice-based system,

    Z. Jianet al., “DRS: A deep reinforcement learning enhanced Kubernetes scheduler for microservice-based system,”Software: Practice and Experience, vol. 54, no. 10, pp. 2102–2126, 2024

    2024

  30. [30]

    KEDA documentation,

    KEDA, “KEDA documentation,” 2026. [Online]. Available: https://keda.sh/docs/

    2026

  31. [31]

    Descheduler for Kubernetes,

    Kubernetes SIG Scheduling, “Descheduler for Kubernetes,” 2026. [Online]. Available: https://github.com/kubernetes-sigs/desche duler

    2026

  32. [32]

    Pod topology spread constraints,

    Kubernetes, “Pod topology spread constraints,” 2026. [Online]. Available: https://kubernetes.io/docs/concepts/scheduling-evi ction/topology-spread-constraints/

    2026