stateDiagram-v2
[*] --> Pending: CR Created
Pending --> Running: Master Job active
Running --> Succeeded: Master Job completed
Running --> Failed: Master Job failed
Pending --> Failed: Pod health check failed (after grace period)
Running --> Failed: Pod health check failed (after grace period)
Phase
Meaning
What to do
Pending
Resources are being created (Service, master Job, worker Job). Initial state after CR creation. Also set during recovery after external resource deletion.
Wait for resources to be scheduled. Check events if stuck.
Running
Master Job has at least one active pod. Test execution is in progress. startTime is set on this transition.
Monitor worker connections and test progress.
Succeeded
Master Job completed successfully (exit code 0). completionTime is set.
Collect results. CR can be deleted or kept for records.
Failed
Master Job failed, or pod health checks detected persistent failures after the 2-minute grace period. completionTime is set.
Check pod logs and events for failure details. Delete and recreate to retry.
The operator waits 2 minutes after pod creation before reporting pod health failures. This prevents false alarms during normal startup activities like image pulling, volume mounting, and scheduling.
# Quick status overviewkubectlgetlocusttestmy-test
# Detailed status with conditionskubectlgetlocusttestmy-test-ojsonpath='{.status}'|jq.
# Watch phase changes in real-timekubectlgetlocusttestmy-test-w
# Check specific conditionkubectlgetlocusttestmy-test-ojsonpath='{.status.conditions[?(@.type=="Ready")].status}'# Check worker connection progresskubectlgetlocusttestmy-test-ojsonpath='{.status.connectedWorkers}/{.status.expectedWorkers}'
Use kubectl wait to integrate LocustTest into CI/CD pipelines. The operator's status conditions follow standard Kubernetes conventions, making them compatible with any tool that supports kubectl wait.
GitHub Actions example:
name:Load Teston:workflow_dispatch:jobs:load-test:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-name:Apply testrun:kubectl apply -f locusttest.yaml-name:Wait for test completionrun:|kubectl wait locusttest/my-test \--for=jsonpath='{.status.phase}'=Succeeded \--timeout=30m-name:Check resultif:failure()run:|echo "Test failed or timed out"kubectl describe locusttest my-testkubectl logs -l performance-test-name=my-test --tail=50-name:Cleanupif:always()run:kubectl delete locusttest my-test --ignore-not-found
Generic shell script example:
#!/bin/bashset-e
# Apply testkubectlapply-flocusttest.yaml
# Wait for completion (either Succeeded or Failed)echo"Waiting for test to complete..."whiletrue;doPHASE=$(kubectlgetlocusttestmy-test-ojsonpath='{.status.phase}'2>/dev/null)case"$PHASE"inSucceeded)echo"Test passed!"exit0;;Failed)echo"Test failed!"kubectldescribelocusttestmy-test
exit1;;*)echo"Phase: $PHASE - waiting..."sleep10;;esacdone
# List all LocustTestskubectlgetlocusttests
kubectlgetlotest# short name# Describe a LocustTestkubectldescribelocusttest<name>
# Watch status changeskubectlgetlocusttest<name>-w
# Delete a LocustTestkubectldeletelocusttest<name>
These flags configure the operator pod itself (not LocustTest CRs). The Helm chart passes them through deployment.yaml; users running the binary directly or via custom kustomize overlays can pass them on the command line.
Flag
Default
Description
--enable-webhooks
false
Enable conversion + validation webhooks. When true, --webhook-cert-path is required. Chart binding: webhook.enabled.
--webhook-cert-path
""
Directory holding tls.crt / tls.key. Chart binding: hardcoded to /tmp/k8s-webhook-server/serving-certs.
--webhook-cert-name
tls.crt
Filename of the TLS certificate.
--webhook-cert-key
tls.key
Filename of the TLS key.
--webhook-cert-wait-timeout
2m
Maximum time to wait for cert files to appear. Set to 0 to wait indefinitely (not recommended).
When both are set, the explicit flag wins. Empty ENABLE_WEBHOOKS="" is ignored (the prior envVal != "false" check would have silently enabled webhooks on a typo). Valid values are those accepted by Go's strconv.ParseBool.