github
/
k3s
mirror of https://github.com/k3s-io/k3s
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
k3s/test/integration/scheduler_perf
History
Kubernetes Submit Queue d8efc779ed Merge pull request #38154 from caesarxuchao/rename-release_1_5 
Automatic merge from submit-queue (batch tested with PRs 38154, 38502)

Rename "release_1_5" clientset to just "clientset"

We used to keep multiple releases in the main repo. Now that [client-go](https://github.com/kubernetes/client-go) does the versioning, there is no need to keep releases in the main repo. This PR renames the "release_1_5" clientset to just "clientset", clientset development will be done in this directory.

@kubernetes/sig-api-machinery @deads2k 

```release-note
The main repository does not keep multiple releases of clientsets anymore. Please find previous releases at https://github.com/kubernetes/client-go
```
 		2016-12-14 14:21:51 -08:00
..
BUILD rename /release_1_5 to /clientset 2016-12-14 12:39:48 -08:00
README.md Remove 'this is HEAD' warning on docs 2016-10-26 00:06:59 +02:00
scheduler_bench_test.go Generalize Pod creation across e2e and integration tests 2016-10-26 11:52:14 +02:00
scheduler_test.go spell check for test/* 2016-12-14 06:03:00 -08: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 rename /release_1_5 to /clientset 2016-12-14 12:39:48 -08: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/component/scheduler/perf
./test-performance.sh

Analytics

Analytics