You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@yunikorn.apache.org by "Bowen Li (Jira)" <ji...@apache.org> on 2021/03/30 04:07:00 UTC

[jira] [Comment Edited] (YUNIKORN-614) support co-deployment of YuniKorn with other schedulers, or multiple YuniKorn, in a single cluster

    [ https://issues.apache.org/jira/browse/YUNIKORN-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311104#comment-17311104 ] 

Bowen Li edited comment on YUNIKORN-614 at 3/30/21, 4:06 AM:
-------------------------------------------------------------

Yes, I understand there will be race condition if we deploy 2 YK with different versions and don't do anything else. That's why I suggested to at least associate it or make it configurable with K8S concepts like namespace or node group or node tags, to give users the options to do it if they desire.

E.g. users can choose to deploy 2 YK in 2 separate namespaces and won't have racing conditions.


was (Author: phoenixjiangnan):
Yes, I understand there will be race condition if we deploy 2 YK with different versions and don't do anything. That's why I suggested to at least associate it or make it configurable with K8S concepts like namespace or node group or node tags, to give users the options to do it if they desire.

E.g. users can choose to deploy 2 YK in 2 separate namespaces and won't have racing conditions.

> 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: issues-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: issues-help@yunikorn.apache.org