Support for Best-Effort / Progressive Scheduling in Karmada

[akuowen]

Currently, Karmada Scheduler schedules ResourceBindings in an all-or-nothing manner.

Scenario:
I want 5 replicas, but the available resources in the member clusters are only enough for 1 replica.

Current behavior:
If scheduling cannot satisfy all replicas, no replicas are scheduled, and the ResourceBinding is marked as failed.

Expected behavior / Proposal:

Scheduler should support partial assignment (best-effort): schedule as many replicas as resources allow.

The remaining replicas should be recorded as pending in status.pendingReplicas.

A controller (or external mechanism) can watch pending replicas and trigger rescheduling once cluster resources become available.

Repeat until the desired total replicas are fully scheduled.

This would enable progressive scheduling, allowing Karmada to gradually utilize available cluster resources without failing the entire ResourceBinding.

Questions:

Is there a plan in Karmada to support this kind of best-effort / progressive scheduling?

Would this fit better as an extension to Scheduler, or as a controller outside Scheduler?

[RainbowMango]

Thanks for the feedback, @akuowen!

This feature request is quite similar to #6333, which we've been discussing.

The best-effort / progressive scheduling concept sounds reasonable, and we're currently gathering more real-world use cases to better assess its value and prioritize accordingly.

Could you provide more specific details about your scenario? For example, what kind of workloads would benefit from this, and in what situations is partial scheduling preferred over waiting for all resources to become available?

[akuowen]

感谢您的反馈。@akuowen！

此功能请求与我们一直在讨论的#6333非常相似。

尽力而为/渐进式调度概念听起来很合理，我们目前正在收集更多实际用例，以便更好地评估其价值并据此确定优先级。

您能否提供更具体的场景细节？例如，哪些类型的工作负载会受益于此？在哪些情况下，部分调度比等待所有资源可用更可取？

Thank you for your reply @RainbowMango .

A concrete scenario for best-effort / progressive scheduling is serverless or function workloads, similar to AWS Lambda:

Workload type: Each replica is an independent function instance that can serve requests immediately.

Problem with current logic: If all replicas cannot be scheduled due to limited cluster resources, no instances are created and requests are blocked, leading to service unavailability.

Expected / Best-Effort behavior:

Schedule as many replicas as possible immediately (e.g., 1 of 5).

Track remaining replicas as pending in status.pendingReplicas.

When resources free up, schedule pending replicas progressively.

This behavior can be configurable and does not affect the existing scheduler logic.

Benefit: At least one function instance is available to handle requests immediately, instead of waiting for all resources. This enables immediate responsiveness and better resource utilization.

[QingShan-Xu]

+1

[RainbowMango]

Thanks @akuowen for providing the concrete use case! I think the request is reasonable, and the serverless/function workloads scenario is quite compelling.

However, we should also recognize that the complexity of implementing this feature is evident. It involves design considerations across several areas:

• We need to define how the scheduler performs best-effort scheduling, including scheduling strategy selection and resource assessment improvements.
• We need to introduce new fields in the ResourceBinding status to record pending replicas (e.g., pendingReplicas), while considering compatibility with existing status fields.
• We need to design a mechanism to manage how rescheduling attempts are triggered and executed, including trigger conditions, backoff strategies, and retry limits.

Therefore, I suggest that our next step should be to create a formal proposal to systematically design this feature. If you're interested, we'd be very welcome to have you draft this proposal! I'd be happy to review and discuss it. This will ensure our design is comprehensive and maintainable, and it can also gather community feedback.

I'd also like to invite you to join our Karmada community meeting to further discuss this requirement and how we can move forward together. This would be a great opportunity to discuss the design details with the broader community and explore potential implementation approaches.

[akuowen]

Thanks @akuowen for providing the concrete use case! I think the request is reasonable, and the serverless/function workloads scenario is quite compelling.

However, we should also recognize that the complexity of implementing this feature is evident. It involves design considerations across several areas:

• We need to define how the scheduler performs best-effort scheduling, including scheduling strategy selection and resource assessment improvements.
• We need to introduce new fields in the ResourceBinding status to record pending replicas (e.g., pendingReplicas), while considering compatibility with existing status fields.
• We need to design a mechanism to manage how rescheduling attempts are triggered and executed, including trigger conditions, backoff strategies, and retry limits.

Therefore, I suggest that our next step should be to create a formal proposal to systematically design this feature. If you're interested, we'd be very welcome to have you draft this proposal! I'd be happy to review and discuss it. This will ensure our design is comprehensive and maintainable, and it can also gather community feedback.

I'd also like to invite you to join our Karmada community meeting to further discuss this requirement and how we can move forward together. This would be a great opportunity to discuss the design details with the broader community and explore potential implementation approaches.

Thanks @RainbowMango for the detailed feedback and encouragement!

I’m glad to hear that the serverless / function-style use case resonates, and I agree that supporting best-effort / progressive scheduling involves non-trivial design considerations across scheduler behavior, ResourceBinding status, and rescheduling mechanisms.

I’d be happy to draft a formal proposal to help structure the discussion and explore a feasible design direction. This will likely take some time, as I’d like to think through the scope carefully and keep it aligned with Karmada’s existing scheduling model.

Before getting started, I wanted to ask about the preferred way to share such a proposal with the community:

Would you recommend replying in this issue with a design draft, or

Submitting a separate PR under something like docs/proposals/ for broader visibility and review?

Please let me know what works best. I’ll follow up with a proposal once I have a solid draft ready.
Thanks again for the guidance, and I’m also happy to join a community meeting to discuss this further when appropriate.

[RainbowMango]

I’d be happy to draft a formal proposal to help structure the discussion and explore a feasible design direction. This will likely take some time, as I’d like to think through the scope carefully and keep it aligned with Karmada’s existing scheduling model.

Thank you in advance. No need to rush, please take your time.

I would prefer to have a formal proposal at docs/proposals/. You can get started with the proposal template.