Aias00 opened a new issue, #7913: URL: https://github.com/apache/shenyu/issues/7913
### Behavior and reproduction With two Admin replicas, a working Kubernetes client and dynamic scaling policy enabled in their shared database, both replicas independently start the same metric monitor and actuate the same deployment. Existing Admin master election does not own or stop these scaling tasks. At `fda742c48e7f553c9964cf74b36732326d0fde00`, two independent instances of the actual ScaleService, each with the same enabled policy 3, registered two monitor callbacks. Run one metric evaluation through each callback using the actual ScaleObserver/ScaleRuleEvaluator with value 99 and upper threshold 10. A recording KubernetesScaler received **two scale-up actions** for that one logical monitoring cycle. The Kubernetes call was mocked; no live cluster was modified. Source tracing confirms the normal per-Admin ApplicationRunner starts these same lifecycles. ### Location / production path - [Every Admin startup loads policies and invokes executeScaling](https://github.com/apache/shenyu/blob/fda742c48e7f553c9964cf74b36732326d0fde00/shenyu-admin/src/main/java/org/apache/shenyu/admin/scale/scaler/ScaleTaskInitializer.java#L57) - [Policy 3 starts a monitor without checking master ownership](https://github.com/apache/shenyu/blob/fda742c48e7f553c9964cf74b36732326d0fde00/shenyu-admin/src/main/java/org/apache/shenyu/admin/scale/scaler/ScaleService.java#L112) - [Monitor registration](https://github.com/apache/shenyu/blob/fda742c48e7f553c9964cf74b36732326d0fde00/shenyu-admin/src/main/java/org/apache/shenyu/admin/scale/scaler/ScaleService.java#L237) - [Each rule observation actuates Kubernetes](https://github.com/apache/shenyu/blob/fda742c48e7f553c9964cf74b36732326d0fde00/shenyu-admin/src/main/java/org/apache/shenyu/admin/scale/monitor/observer/ScaleObserver.java#L43) - [Cluster master service only manages upstream/instance checkers](https://github.com/apache/shenyu/blob/fda742c48e7f553c9964cf74b36732326d0fde00/shenyu-admin/src/main/java/org/apache/shenyu/admin/mode/cluster/service/ShenyuClusterService.java#L66) Local synchronization and appliedTarget caching do not coordinate separate Admin JVMs. Concurrent read/replace operations can conflict or duplicate scale changes; the deterministic probe establishes duplicate actuation, not a claim about one exact final replica count under every network ordering. ### Expected behavior / suggested repair Define a single scaling authority in clustered Admin mode, tied to a lease/master lifecycle or another explicit coordination mechanism. Stop/fence follower and stale-master tasks, handle role changes, and propagate policy changes to the current owner. Preserve standalone mode. Test two Admin lifecycles, one actuation per observation, policy updates and master failover. Medium severity, high confidence; independently reviewed against startup and master-election code. Distinct from #7875 (multiple rules sharing a metric), #7886 (window scheduling), and generic Admin configuration synchronization. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
