Repository navigation
docs: add ecosystem volcano - #1959
kube-gopher wants to merge 1 commit into
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
volcano-sh/website#595 |
|
/remove-kind enhancement |
volcano-sh-bot
added
kind/documentation
|
|
||
| [Volcano](https://volcano.sh) is the default scheduler for Kthena `ModelServing` workloads. It provides gang scheduling, network topology-aware scheduling, and queue-based resource sharing for LLM inference. | ||
|
|
||
| For each `ServingGroup`, the ModelServing controller creates a Volcano `PodGroup` with the same name, so that Volcano schedules all pods of the group together. |
There was a problem hiding this comment.
Add a link to the PodGroup description.
| # ... | ||
| ``` | ||
|
|
||
| To require only a minimum number of replicas per role, for example in prefill/decode disaggregation, set `gangPolicy.minRoleReplicas`: |
There was a problem hiding this comment.
Add a note. If MinRoleReplicas is not specified, by default, Pods from all roles are scheduled together in a gang.
|
Since Volcano is the default scheduler for ModelServing, would this guide fit better under installation or scheduling rather than Ecosystem? |
|
ok |
1cbaf4c to
137ad61
Compare
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues block the Volcano integration guide and sidebar update.
No open issues 🎉
What changed in this PR
Adds an ecosystem guide explaining how Kthena ModelServing workloads integrate with the Volcano scheduler.
Changes:
- Documents prerequisites, gang scheduling, topology-aware placement, and queue assignment with YAML examples.
- Adds the Volcano integration guide to the Ecosystem sidebar.
| File | Description |
|---|---|
docs/kthena/sidebars.ts |
Adds the Volcano guide to Ecosystem navigation. |
docs/kthena/docs/ecosystem/volcano-integration.md |
Documents Volcano scheduling features and configuration for ModelServing workloads. |
Review effort: Balanced
| - Install [Volcano](https://volcano.sh/en/docs/installation/) in your cluster. Role-level gang scheduling and role-level network topology require Volcano **1.14** or later. | ||
| - Install Kthena by following [Installation](../getting-started/installation.md). | ||
|
|
||
| Kthena detects Volcano at runtime, so you can install it before or after Kthena without restarting the controller. |
There was a problem hiding this comment.
This holds for the controller, but not for ModelServings that already exist when Volcano is installed afterwards.
Pods are only annotated with scheduling.k8s.io/group-name while the PodGroup CRD is present (manager.go#L553-L556). Detecting the CRD doesn't recreate or re-annotate existing pods. Those pods are already Pending with schedulerName: volcano. Once Volcano starts, its PodGroup controller creates a separate PodGroup for each pod without that annotation and sets the annotation itself (pg_controller_handler.go#L184-L189). As a result those pods are scheduled one by one, without gang, minResources, or the queue annotation, until they are recreated.
Suggest adding a note, e.g. "ModelServings whose pods were created before Volcano was installed are not gang scheduled until their pods are recreated."
@kube-gopher When you have done, please also add it into Volcano's website for Kthena integration |
okay |
Signed-off-by: kube-gopher <jzlyy68@gmail.com>
137ad61 to
1717fb4
Compare
What type of PR is this?
/kind enhancement
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Bug evidence (required for bug-related PRs):
Special notes for your reviewer:
Does this PR introduce a user-facing change?: