You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What would you like to be added:
We need a test suite for measuring direct scheduler throughput without depending on KCM QPS limits.
Why is this needed:
Today our load test only tests scheduler-throughput at a a very small scale i.e max-pods to 5k and also its limited by KCM throughput as current test-suite depends on deployment/replicaset controller throughput in creating pods. That would limit us from knowing the actual scheduler throughput that we can achieve out of scheduler today.
Also, some users of K8s today actually leverage scheduler directly to create pods without having to depend on KCM for other wrappers like deployments/jobs/replicaset controllers, we need a test-suite that would help us know the limits of scheduler throughput without having to depend on the KCM bottlenecks/regressions.
We could use this test-suite to run periodically in test-infra to see if we truly regress w.r.t max scheduler throughput in our e2e tests.
The text was updated successfully, but these errors were encountered:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
What would you like to be added:
We need a test suite for measuring direct scheduler throughput without depending on KCM QPS limits.
Why is this needed:
Today our load test only tests scheduler-throughput at a a very small scale i.e max-pods to 5k and also its limited by KCM throughput as current test-suite depends on deployment/replicaset controller throughput in creating pods. That would limit us from knowing the actual scheduler throughput that we can achieve out of scheduler today.
Also, some users of K8s today actually leverage scheduler directly to create pods without having to depend on KCM for other wrappers like deployments/jobs/replicaset controllers, we need a test-suite that would help us know the limits of scheduler throughput without having to depend on the KCM bottlenecks/regressions.
We could use this test-suite to run periodically in test-infra to see if we truly regress w.r.t max scheduler throughput in our e2e tests.
The text was updated successfully, but these errors were encountered: