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