Deploy from a Source Checkout to a Real Kubernetes Cluster
This guide starts from an AIPerf source checkout and deploys that code to a real Kubernetes cluster. It builds a container image, pushes it to a registry, installs or upgrades the AIPerf operator with Helm, then runs a benchmark against a real inference endpoint.
This guide does not use the mock server path. Use it when you have a real OpenAI-compatible endpoint already running, or when you want to deploy a real Dynamo/vLLM endpoint first.
Prerequisites
You need:
- An AIPerf source checkout.
kubectlconfigured for the target cluster.- Helm v3.
- Docker or another container builder that can build and push OCI images.
- Registry credentials for the image repository you will use.
- Permission to install CRDs, create the operator namespace, create benchmark namespaces, and create JobSet workloads.
- JobSet installed on the cluster. If it is not installed, install it before the AIPerf operator.
- A real OpenAI-compatible inference endpoint reachable from benchmark pods, or permission to deploy one.
Check the cluster first:
For GPU benchmarks, verify GPU resources are allocatable:
1. Set up the checkout
Install the local development environment from the checkout:
Use the local CLI through uv run until the package is installed somewhere else:
Pick a tag that identifies the exact checkout you are deploying:
2. Build and push the AIPerf image
The same image is used by the operator containers and benchmark JobSet pods unless you explicitly override defaults.image in the Helm chart.
NGC-style registry
Use this shape for an NGC organization or private NVIDIA registry namespace:
GitHub Container Registry
Use this shape for GHCR:
If your cluster nodes use a different architecture than the build host, build for the cluster platform:
3. Create an image pull secret if the registry is private
Skip this section if every node can pull the image without a secret.
Create the operator namespace first:
For NGC-style registries:
For GHCR:
The Helm install below references this secret for the operator. Benchmark jobs also need pull access in the namespace you run them in. Kubernetes secrets are namespace-scoped, so create the same pull secret there:
4. Install or upgrade the AIPerf operator
Split the image into repository and tag for Helm:
Install the operator:
If you created aiperf-registry, include it in the Helm release:
The chart default for defaults.image is empty, which means AIPerfJob pods use <image.repository>:<image.tag>, falling back to the chart’s appVersion when image.tag is also empty. Set defaults.image only when benchmark pods should run a different image from the operator.
Wait for the operator and results server:
Run Helm tests if the cluster can pull the chart’s test image:
5. Run against an existing real endpoint
Use this path when your inference server is already deployed in the cluster or reachable from the cluster network.
Set the endpoint and model:
Run cluster-side preflight checks:
Submit a benchmark:
For private benchmark images, pass the pull secret name when submitting jobs:
For repeatable runs, put the benchmark configuration in YAML and pass --config benchmark.yaml; see End-to-End Workflow for the init -> validate -> preflight -> profile sequence.
6. Optional: deploy a real Dynamo/vLLM endpoint first
Skip this section if you already have a real endpoint.
Install the Dynamo platform chart if your cluster does not already have it:
Deploy an aggregated Dynamo vLLM server by applying a DynamoGraphDeployment manifest such as the aggregated vLLM example in Getting Started on Kubernetes:
Wait for the frontend and worker pods to become ready:
Use the Dynamo service URL as the benchmark endpoint:
7. Monitor and retrieve results
Watch progress:
Reattach to a detached run:
Download results:
Port-forward the results server and dashboard:
Then open http://localhost:8081.
8. Upgrade after source changes
After changing source code, repeat the build and push with a new immutable tag:
Wait for the new operator pod before submitting new jobs:
Troubleshooting
ImagePullBackOff
Check the failing pod and events:
Common fixes:
- Confirm the image was pushed with the exact tag used by Helm or
aiperf kube profile. - Create the pull secret in both
aiperf-systemand the benchmark namespace. - Pass
--image-pull-secrets aiperf-registrytoaiperf kube profilefor private benchmark images. - Use
--set image.pullPolicy=Alwayswhile testing mutable tags; prefer immutable tags for normal use.
Operator is running but jobs use an old image
The operator image and default benchmark image come from the Helm release. Check the rendered CRD default:
If you set defaults.image, it overrides the benchmark image independently of image.repository and image.tag.
Endpoint check fails
Verify the endpoint from inside the cluster:
If the server is still starting and you intentionally want the benchmark to wait until worker runtime, set skipEndpointCheck: true in the AIPerfJob YAML. Do not use this to hide a wrong service name or namespace.
RBAC or namespace errors
The Helm chart creates benchmark RBAC in the release namespace and in any namespaces listed in benchmarkRbacNamespaces. If you run jobs in a different namespace, add that namespace to benchmarkRbacNamespaces:
Related Documentation
- Getting Started on Kubernetes — First benchmark walkthrough and Dynamo manifest examples.
- End-to-End Workflow — Full
init->validate->preflight->profile->resultslifecycle. - Production Deployments — CI/CD, Kueue, private registries, multi-tenancy, and operations patterns.
- Kubernetes Configuration Reference — CRD fields, Helm values, and AIPerfJob configuration.
- Monitoring and Troubleshooting — Watch, debug, logs, and common failure modes.