[
https://issues.apache.org/jira/browse/YUNIKORN-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig Condit closed YUNIKORN-614.
---------------------------------
Resolution: Won't Do
> support co-deployment of YuniKorn with other schedulers, or multiple
> YuniKorn, in a single cluster
> --------------------------------------------------------------------------------------------------
>
> Key: YUNIKORN-614
> URL: https://issues.apache.org/jira/browse/YUNIKORN-614
> Project: Apache YuniKorn
> Issue Type: New Feature
> Components: core - scheduler, deployment
> Reporter: Bowen Li
> Priority: Major
>
> IIUIC, YuniKorn right now cannot be co-deployed with other schedulers, like
> default K8S scheduler, nor can users deploy multiple YuniKorn, in a single
> cluster.
> We have use cases of such requirements:
> # we want to have YuniKorn as the "active" scheduler to take job requests,
> and still be able to route requests to another scheduler as "backup" in case
> of any issues.
> # deploy and test a new YuniKorn version to take like 20% traffic to a K8S
> cluster, while keeping an old, stable version taking the remaining 80% traffic
> Seems we cannot do either at the moment, and a workaround is to deploy
> another cluster for the above use cases, which inevitably bring in huge
> DevOps costs.
> Ideally, we should support co-deployment of YuniKorn with other schedulers,
> or multiple YuniKorn, in a single cluster. We can further break down this
> ticket to sub-tasks to handle each of the above use cases.
> Traffic routing to different schedulers can be scoped and determined by some
> K8S native concepts like namespaces and node groups, or some custom concepts
> of YuniKorn which can be mapped to K8S native concepts for easier management.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
