1IPAM Performance Test
2=====
3
4Motivation
5-----
6We wanted to be able to test the behavior of the IPAM controller's under various scenarios,
7by mocking and monitoring the edges that the controller interacts with. This has the following goals:
8
9- Save time on testing
10- To simulate various behaviors cheaply
11- To observe and model the ideal behavior of the IPAM controller code
12
13Currently the test runs through the 4 different IPAM controller modes for cases where the kube API QPS is a)
14equal to and b) significantly less than the number of nodes being added to observe and quantify behavior.
15
16How to run
17-------
18
19```shell
20# In kubernetes root path
21cd test/integration/ipamperf
22./test-performance.sh
23```
24
25The runner scripts support a few different options:
26
27```shell
28./test-performance.sh -h
29usage: ./test-performance.sh [-h] [-d] [-r <pattern>] [-o <filename>]
30usage: ./test-performance.sh <options>
31 -h display this help message
32 -d enable debug logs in tests
33 -r <pattern> regex pattern to match for tests
34 -o <filename> file to write JSON formatted results to
35 -p <id> enable cpu and memory profiles, output written to mem-<id>.out and cpu-<id>.out
36 -c enable custom test configuration
37 -a <name> allocator name, one of RangeAllocator, CloudAllocator, IPAMFromCluster, IPAMFromCloud
38 -k <num> api server qps for allocator
39 -n <num> number of nodes to simulate
40 -m <num> api server qps for node creation
41 -l <num> gce cloud endpoint qps
42```
43
44The tests follow the pattern TestPerformance/{AllocatorType}-KubeQPS{X}-Nodes{Y}, where AllocatorType
45is one of
46
47- RangeAllocator
48- IPAMFromCluster
49- CloudAllocator
50- IPAMFromCloud
51
52and X represents the QPS configured for the kubernetes API client, and Y is the number of nodes to create.
53
54The -d flags set the -v level for glog to 6, enabling nearly all of the debug logs in the code.
55
56So to run the test for CloudAllocator with 10 nodes, one can run
57
58```shell
59./test-performance.sh -r /CloudAllocator.*Nodes10$
60```
61
62At the end of the test, a JSON format of the results for all the tests run is printed. Passing the -o option
63allows for also saving this JSON to a named file.
64
65### Profiling the code
66It's possible to get the CPU and memory profiles of code during test execution by using the ```-p``` option.
67The CPU and memory profiles are generated in the same directory with the file names set to ```cpu-<id>.out```
68and ```cpu-<id>.out```, where ```<id>``` is the argument value. Typicall pattern is to put in the number
69of nodes being simulated as the id, or 'all' in case running the full suite.
70
71### Custom Test Configuration
72It's also possible to run a custom test configuration by passing the -c option. With this option, it then
73possible to specify the number of nodes to simulate and the API server qps values for creation,
74IPAM allocation and cloud endpoint, along with the allocator name to run. The defaults values for the
75qps parmeters are 30 for IPAM allocation, 100 for node creation and 30 for the cloud endpoint, and the
76default allocator is the RangeAllocator.
77
78Code Organization
79-----
80The core of the tests are defined in [ipam_test.go](ipam_test.go), using the t.Run() helper to control parallelism
81as we want to able to start the master once. [cloud.go](cloud.go) contains the mock of the cloud server endpoint
82and can be configured to behave differently as needed by the various modes. The tracking of the node behavior and
83creation of the test results data is in [results.go](results.go).
View as plain text