[Yuan Gao (ygao-g)]

Part of #3624: size the rig so atenet-egress is the bottleneck under test.

Before this PR, the benchmark ran at a fixed request rate. The later PRs of #3624 measure the highest rate that atenet-egress holds, with the gateway as the system under test. So the load generator, which runs inside an actor, and the origin server should get more CPU and memory.

Measured on a GKE cluster with 4 c3-standard-22 nodes and envoy of atenet-egress at 1 vCPU. In each of the modes http, mitm and passthrough, envoy reached its CPU limit. The worker pod of the load generator peaked at 12 of its 18 vCPUs, and nighthawk-server at 2.1 of its 8. The run used the search of those later PRs.

AI use: AI-assisted for the diff, the split and the test runs; I reviewed the diff.

• Tests pass
• Docs updated

[Yuan Gao (ygao-g)]

Reviewer notes (Stage 1 stack guide)

Stack position: Independent of #3628; both sit on main. #3629 and #3630 carry this PR's three commits after #3628's.

Commit-by-commit checks (8c06a5bc3):

1. 05070e6c3: build_kubectl_ate moves from benchmarking/workloads/deploy.sh into benchmarking/lib/kubectl-ate.sh unchanged; both deploy scripts source it.
2. 6ce5bd931: Check resource alignment across traffic-driver-template.yaml.tmpl (16000m / 8 GiB actor), traffic-driver.yaml.tmpl (12-18 vCPU worker pod), and nighthawk-server.yaml (--concurrency 8, 6-8 vCPU). atelet registers the pod CPU limit from the downward API (internal/ateworker/register/register.go:117), and checkRoom (cmd/ateapi/internal/scheduling/scheduling.go:321-337) admits at most one 16000m actor onto an 18000m worker pod (18000 - 16000 < 16000).
3. 8c06a5bc3: Check that deploy-traffic-driver.sh sources the helper and builds kubectl-ate before its first kubectl ate call, in deploy and in delete.

Behavior impact:

• Default CPU and memory requests target multi-node clusters (c3-standard-22) and no longer fit a single-node kind cluster without lowering requests first.