Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
Today, YK works behind the scene, and the workflow is like
- app operator or job server launch a bunch of pods on K8s
- YK gets notified and group pods to apps based on appID
- YK schedules the pods with respect to the app info
This provides a simple model to integrate with existing K8s and to support workloads, but it has some user experience issues. Such as
- YK can hardly manage the app lifecycle end to end. An outstanding issue is we do not know when an app is finished if we only look at the pod status.
- YK doesn't have ability to admit apps. We need the ability to admit app based on various conditions, e.g resource quota, cluster overhead, ACL, etc.
- Hard to track app status. Sometimes app might be pending in resource queues, but we do not have a good way to expose such status info.
To further improve the user experience, we need to introduce an application tracking API and K8s custom resource definition (CRD). The CRD will be used by app operator/job server to interact with YK, to get the lifecycle fully controlled.
Attachments
Issue Links
- is blocked by
-
YUNIKORN-373 [umbrella] Upgrade Kubernetes dependency to 1.16
- Closed
- links to