E2E for ShardingController

[qi-min]

Summary

ShardingController is a newly introduced component in volcano-controllers to support shard management and control. To ensure correctness and stability, we need to add end-to-end (E2E) test cases to validate shard control behavior and sharding accuracy under different sharding strategies.

The E2E tests should cover scenarios such as shard assignment, node resource boundary changes, controller reconciliation behavior under different strategies, and nodes distribution across shards. These tests will help verify that the ShardingController works as expected in real cluster environments and prevent regressions as new sharding strategies or features are introduced.

Scenarios

1. Shards are created based on default configuration after controller startup if Shards do not exist
2. Nodes are assigned from one shard to another shard when resource usage of node significantly changed
3. Newly created Nodes are added to shard
4. Removed or unschedulable nodes are moved out from shard
5. Configuration change trigger nodes re-assigned to different
6. Node re-assignment keep nodes as stable as possible in each shard

[shiverse94]

can I share the approach here.

[shiverse94]

Can you please verify whether i am heading toward right directions?
#4966

[SOHAMPAL23]

/assign

[SOHAMPAL23]

The ShardingController directly affects how nodes are grouped and managed across shards, so even small logic issues can lead to unstable scheduling behavior. Unit tests alone can’t fully capture this, because shard assignment depends on real controller reconciliation, node lifecycle events, and dynamic resource changes.

My approach is to validate ShardingController end-to-end in a real Kubernetes environment, exactly the way it runs in production. Using a reproducible test cluster, the E2E tests will verify that shards are created correctly, nodes are assigned and re-assigned as expected when resources or configurations change, and that node movement remains stable and minimal during reconciliation.

Specifically, the tests will:

• Verify that shards are automatically created on controller startup when none exist.

• Ensure nodes are assigned and re-assigned correctly based on resource usage and sharding strategy.

• Validate behavior when nodes are added, removed, or become unschedulable.

• Confirm that configuration changes trigger controlled rebalancing, without unnecessary node movement.

• Check that the controller maintains stability and minimal disruption during reconciliation.

These tests will be fully automated, integrated into CI, and designed to be deterministic and reproducible, helping the project:

• Catch regressions early

• Increase confidence in sharding logic

• Safely evolve sharding strategies over time