Implement sending mixed traffic (json,proto)

[arshadd-b]

What type of PR is this?

What this PR does / why we need it:

Implements sending mixed traffic by modifying contentType to accept both json and proto.

Which issue(s) this PR fixes:

Fixes # kubernetes/kubernetes#131885

Special notes for your reviewer:

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: arshadd-b
Once this PR has been reviewed and has the lgtm label, please assign mborsz for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• clusterloader2/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @arshadd-b!

It looks like this is your first PR to kubernetes/perf-tests 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/perf-tests has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @arshadd-b. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[arshadd-b]

Hi @mborsz @wojtek-t
Could you please have a look
Thank you

[serathius]

Have you tested if this for loop works?

[arshadd-b]

yes, have tested it, I passed the env variable export CL2_LIST_BENCHMARK_CONTENT_TYPE=json,proto
and it was working fine. I have highlighted json and proto log.

`I0904 12:17:41.288482 96635 exec_service.go:122] Exec service: service set up successfully!
W0904 12:17:41.288517 96635 imagepreload.go:92] No images specified. Skipping image preloading
I0904 12:17:41.291307 96635 clusterloader.go:454] Test config successfully dumped to: generatedConfig_list-benchmark.yaml
I0904 12:17:41.291315 96635 clusterloader.go:243] --------------------------------------------------------------------------------
I0904 12:17:41.291317 96635 clusterloader.go:244] Running ../testing/list/config.yaml
I0904 12:17:41.291319 96635 clusterloader.go:245] --------------------------------------------------------------------------------
I0904 12:17:41.291355 96635 simple_test_executor.go:58] AutomanagedNamespacePrefix: test-2guakh
I0904 12:17:41.324983 96635 simple_test_executor.go:162] Step "[step: 01] Setup namespace for list benchmark pods" started
I0904 12:17:41.440693 96635 simple_test_executor.go:183] Step "[step: 01] Setup namespace for list benchmark pods" ended
I0904 12:17:41.440713 96635 simple_test_executor.go:162] Step "[step: 02] Setup permissions" started
I0904 12:17:41.449398 96635 simple_test_executor.go:183] Step "[step: 02] Setup permissions" ended
I0904 12:17:41.449415 96635 simple_test_executor.go:162] Step "[step: 03] starting measurements" started
I0904 12:17:41.460559 96635 container_memory_usage.go:129] ContainerMemoryUsage: measurement already running
I0904 12:17:41.460576 96635 simple_test_executor.go:183] Step "[step: 03] starting measurements" ended

I0904 12:17:41.460583 96635 simple_test_executor.go:162] Step "[step: 04] Wait 5 minutes for json" started

[{kube-apiserver map[cpu:{{891606624 -9} {} 891606624n DecimalSI} memory:{{228081664 0} {} BinarySI}]}]
names kube-apiserver
I0904 12:18:11.461067 96635 simple_test_executor.go:183] Step "[step: 04] Wait 5 minutes for json" ended
I0904 12:18:11.461088 96635 simple_test_executor.go:162] Step "[step: 05] gathering measurements" started
I0904 12:18:11.464702 96635 container_memory_usage.go:166] ContainerMemoryUsage: measurement already running
I0904 12:18:11.464713 96635 container_memory_usage.go:177] ContainerMemoryUsage: gathering summaries
I0904 12:18:11.464719 96635 container_memory_usage.go:184] %!d(float64=0.2124176025390625): peak
I0904 12:18:11.464721 96635 container_memory_usage.go:185] %!d(float64=1): threshold
I0904 12:18:11.464727 96635 simple_test_executor.go:183] Step "[step: 05] gathering measurements" ended
I0904 12:18:11.464734 96635 simple_test_executor.go:162] Step "[step: 06] starting measurements" started
I0904 12:18:11.465408 96635 container_memory_usage.go:129] ContainerMemoryUsage: measurement already running
I0904 12:18:11.465415 96635 simple_test_executor.go:183] Step "[step: 06] starting measurements" ended

I0904 12:18:11.465419 96635 simple_test_executor.go:162] Step "[step: 07] Wait 5 minutes for proto" started

[{kube-apiserver map[cpu:{{899564744 -9} {} 899564744n DecimalSI} memory:{{226471936 0} {} 221164Ki BinarySI}]}]
names kube-apiserver
I0904 12:18:41.465856 96635 simple_test_executor.go:183] Step "[step: 07] Wait 5 minutes for proto" ended
I0904 12:18:41.465879 96635 simple_test_executor.go:162] Step "[step: 08] gathering measurements" started
I0904 12:18:41.468584 96635 container_memory_usage.go:166] ContainerMemoryUsage: measurement already running
I0904 12:18:41.468592 96635 container_memory_usage.go:177] ContainerMemoryUsage: gathering summaries
I0904 12:18:41.468600 96635 container_memory_usage.go:184] %!d(float64=0.2124176025390625): peak
I0904 12:18:41.468602 96635 container_memory_usage.go:185] %!d(float64=1): threshold
I0904 12:18:41.468606 96635 simple_test_executor.go:183] Step "[step: 08] gathering measurements" ended
I0904 12:18:41.468613 96635 simple_test_executor.go:97] ContainerMemoryUsage: {"peakMemory": %!d(float64=0.2124176025390625), "threshold": %!d(float64=1)}
I0904 12:18:41.468615 96635 simple_test_executor.go:97] ContainerMemoryUsage: {"peakMemory": %!d(float64=0.2124176025390625), "threshold": %!d(float64=1)}
I0904 12:18:51.501218 96635 simple_test_executor.go:411] Resources cleanup time: 10.032641458s
I0904 12:18:51.501232 96635 simple_test_executor.go:414] Tearing down dependencies
I0904 12:18:51.501236 96635 simple_test_executor.go:418] All dependencies torn down successfully, cleanup time: 3.667µs`

[serathius]

/ok-to-test

[serathius]

Looking at the metric report generated by /modules/measurements.yaml there is only one file ResourceUsageSummary_list-benchmark_2025-09-05T11:45:11+02:00.json even though we call it twice now.

Do we know if the metrics are properly aggregated from two gather commands? Maybe the result is just overridden by second run. Could you maybe look if we could generate separate files for content types?

[arshadd-b]

Looking at the metric report generated by /modules/measurements.yaml there is only one file ResourceUsageSummary_list-benchmark_2025-09-05T11:45:11+02:00.json even though we call it twice now.

Do we know if the metrics are properly aggregated from two gather commands? Maybe the result is just overridden by second run. Could you maybe look if we could generate separate files for content types?

sure will check this and try to add

[arshadd-b]

Looking at the metric report generated by /modules/measurements.yaml there is only one file ResourceUsageSummary_list-benchmark_2025-09-05T11:45:11+02:00.json even though we call it twice now.

Do we know if the metrics are properly aggregated from two gather commands? Maybe the result is just overridden by second run. Could you maybe look if we could generate separate files for content types?

Hi @serathius
to implement this, I have checked two things

1. making the testName dynamic name: list-benchmark-${{ct}}
   in this case it will create two different yaml and two api.config one for json and one for proto
   But I think currently clusterLoader just picks only one here in code https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/cmd/clusterloader.go#L380

2. passing contentType to measurement.yaml
   I think for ResourceUsageSummary and TestMetrics in the code I could not find any parameter that can help us override the name but for APIResponsivenessPrometheus it is happening due to summaryName param
   These are the changes i did in my measurement.yaml

   steps:

   • name: "{{$action}}ing measurements for {{$contentType}} "
     measurements:
     • Identifier: APIResponsivenessPrometheusSimple
       Method: APIResponsivenessPrometheus
       Params:
       action: {{$action}}
       enableViolations: false
       useSimpleLatencyQuery: true
       summaryName: APIResponsivenessPrometheus_{{$contentType}}
     • Identifier: ResourceUsageSummary
       Method: ResourceUsageSummary
       Params:
       action: {{$action}}
       summaryName: ResourceUsageSummary_{{$contentType}}
     • Identifier: TestMetrics
       Method: TestMetrics
       Params:
       action: {{$action}}
       summaryName: TestMetrics_{{$contentType}}`

Please let me know if I have missed something
Thank you