Interaction with other Kubernetes projects #1925
Replies: 1 comment
-
Maybe this KEP would be useful for this: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/3521-pod-scheduling-readiness/README.md Its alpha in 1.26. I like this idea!
I feel like maybe queues should start to include what kind of objects they are allowed to create?
If objects can be CRDs I think we may need to take this case by case as every single object probbaly has their own way of GC. I think an ephemeral namespace may be a heavy-handed but necessary approach for this. The other option (if crd) is to do the delete of the object but that may require too much support depending on what kind of objects we want to support.
This is a scary phase to me. Pretty much everything other than service/ingress ends up being a pod. A user could schedule a deployment object and I think the underlying Pods should be scheduled in Armada. A CRD will most likely create some kind of Pod under the hood. I almost think everything (minus services/ingress) should be handled via the scheduler. |
Beta Was this translation helpful? Give feedback.
-
Armada is designed for high-throughput scheduling of pods across several worker clusters. To achieve this, Armada relies on a multi-stage scheduling strategy, where
This strategy ensures that Armada has a global view of all pods in the system, which is necessary to fairly balance resource usage between users. Further, it ensures that a large number of pods can be ingested over a short span of time without overloading etcd. However, this strategy makes it difficult for Armada to interact with other components in the Kubernetes ecosystem that expect to interact directly with the Kubernets API, e.g., to
To address this issue, we propose for Armada to control the scheduling of pods created directly within a Kubernetes worker cluster that Armada manages. Specifically:
Using this approach, other components can interact directly with the Kubernetes API while Armada retains the global view of all pods necessary for scheduling across many clusters. Objects other than pods are created immediately without needing to go through the Armada scheduler. Any objects created in this way inherit the queue and job set of the object that created them. Pods created in this way are always scheduled by the Armada scheduler onto the cluster they were created in.
The mark that prevents scheduling could be implemented, e.g., via a kube-scheduler plugin that interacts with Armada.
Open questions:
Beta Was this translation helpful? Give feedback.
All reactions