[
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: [email protected]
For additional commands, e-mail: [email protected]
