[
https://issues.apache.org/jira/browse/YUNIKORN-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311003#comment-17311003
]
Weiwei Yang commented on YUNIKORN-614:
--------------------------------------
Like [~wilfreds] pointed out, technically it is not a problem to co-locate YK
with other schedulers. The reason we do not recommend doing so is basically
that if we let the 2 schedulers schedule things simultaneously on the same set
of nodes, we could see scheduling conflicts. [~phoenixjiangnan] we also would
like to understand more use cases, the 2 use cases you brought up are slightly
different. the first one is like an active/backup pattern, and the second one
is like an A/B testing pattern. The first one is likely causing fewer problems
as that doesn't require running scheduling simultaneously, the latter one is a
bit harder as we will see the issues [~wilfreds] pointed out in the previous
comment.
> 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.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
