k3s/test/integration/scheduler_perf
Kubernetes Submit Queue 97921ff38e Merge pull request #41195 from wojtek-t/remove_default_failure_domains
Automatic merge from submit-queue (batch tested with PRs 41401, 41195, 41664, 41521, 41651)

Remove default failure domains from anti-affinity feature

Removing it is necessary to make performance of this feature acceptable at some point.

With default failure domains (or in general when multiple topology keys are possible), we don't have transitivity between node belonging to a topology. And without this, it's pretty much impossible to solve this effectively.

@timothysc
2017-02-17 19:46:40 -08:00
..
BUILD move client/record 2017-01-31 19:14:13 -05:00
README.md fix the wrong test path 2017-02-09 15:16:11 +08:00
scheduler_bench_test.go [scheduler] interface for configuration factory, configurator. 2017-01-18 15:06:16 -05:00
scheduler_test.go Make scheduler_perf warn rather then fail if scheduling rate is between 30 and 100. 2017-02-16 08:44:19 -05:00
test-performance.sh Update scheduler perf to spin up similar client to other tests 2016-10-12 23:50:07 -04:00
util.go Remove default failure domains from anti-affinity feature 2017-02-16 13:32:34 +01:00

README.md

Scheduler Performance Test

Motivation

We already have a performance testing system -- Kubemark. However, Kubemark requires setting up and bootstrapping a whole cluster, which takes a lot of time.

We want to have a standard way to reproduce scheduling latency metrics result and benchmark scheduler as simple and fast as possible. We have the following goals:

  • Save time on testing
    • The test and benchmark can be run in a single box. We only set up components necessary to scheduling without booting up a cluster.
  • Profiling runtime metrics to find out bottleneck
    • Write scheduler integration test but focus on performance measurement. Take advantage of go profiling tools and collect fine-grained metrics, like cpu-profiling, memory-profiling and block-profiling.
  • Reproduce test result easily
    • We want to have a known place to do the performance related test for scheduler. Developers should just run one script to collect all the information they need.

Currently the test suite has the following:

  • density test (by adding a new Go test)
    • schedule 30k pods on 1000 (fake) nodes and 3k pods on 100 (fake) nodes
    • print out scheduling rate every second
    • let you learn the rate changes vs number of scheduled pods
  • benchmark
    • make use of go test -bench and report nanosecond/op.
    • schedule b.N pods when the cluster has N nodes and P scheduled pods. Since it takes relatively long time to finish one round, b.N is small: 10 - 100.

How To Run

cd kubernetes/test/integration/scheduler_perf
./test-performance.sh

Analytics

Analytics