Chapter 12 · Kubernetes Operator

Chapter goals: Use the Locust Kubernetes Operator to manage distributed load testing declaratively in a K8s cluster, master Helm installation, LocustTest CRD configuration, and monitoring integration.

12.1 Why an Operator

Chapter 11 used Docker Compose for master + workers. In a K8s environment, you want:

• Declarative test config (YAML as code, git-versionable);
• Auto-restart on Pod failure, auto-scheduled resource quotas;
• Shared networking and monitoring with other cluster services.

The Locust Kubernetes Operator is a CRD + Controller that defines load tests as K8s resources (LocustTest), auto-creating master/worker Jobs, mounting locustfiles, and exposing the Web UI.

12.2 Installing the Operator

Method 1: Helm Chart (Recommended)

# Add the repository
helm repo add locust-operator https://locustio.github.io/k8s-operator
helm repo update

# Install to a dedicated namespace
helm install locust-operator locust-operator/locust-operator \
  --namespace locust-operator --create-namespace

Verify:

# Check operator Pod status
kubectl get pods -A -l app.kubernetes.io/name=locust-operator
# NAMESPACE           NAME                                    READY   STATUS    AGE
# locust-operator     locust-operator-xxxxxxxxx-xxxxx         1/1     Running   18s

# Check CRD is registered
kubectl get crd
# NAME                        CREATED AT
# locusttests.locust.io       2024-01-15T08:30:00Z

Method 2: Manifest File

kubectl apply -f https://raw.githubusercontent.com/locustio/k8s-operator/main/dist/install.yaml

12.3 Creating Your First LocustTest Resource

# locust-test.yaml
apiVersion: locust.io/v1
kind: LocustTest
metadata:
  name: my-load-test
spec:
  master:
    configMapName: "my-locustfile"       # Reference to ConfigMap containing the locustfile
    image: "locustio/locust:latest"
    replicas: 1
  worker:
    configMapName: "my-locustfile"
    image: "locustio/locust:latest"
    replicas: 5                          # 5 worker Pods
  experiment_target: "http://my-app.default.svc.cluster.local:8000"

First create the ConfigMap holding your locustfile:

kubectl create configmap my-locustfile --from-file=locustfile.py

Then apply the test resource:

kubectl apply -f locust-test.yaml

12.4 Monitoring and Logs

# Watch the test progress
kubectl logs -f deploy/my-load-test-master -n default

# Check worker Pod status
kubectl get pods -l locust.io/test=my-load-test

# Access the Web UI via port-forward
kubectl port-forward svc/my-load-test-master 8089:8089
# Then visit http://localhost:8089

12.5 Chapter Summary

• The Operator defines tests as K8s CRDs — declarative, versionable, auto-recoverable;
• Helm is the recommended install method;
• ConfigMap holds the locustfile; LocustTest spec declares master/worker replicas;
• kubectl port-forward exposes the Web UI for local debugging.

🧪 随堂测验

点击你认为正确的选项。答错时会展示正确答案与原因解析。

1. What does the Locust Kubernetes Operator automate?

2. How is the locustfile delivered to the Operator-managed Pods?

3. What command exposes the Operator-managed Web UI locally?

4. What is the benefit of declarative K8s management over Docker Compose for production testing?

🛠️ Hands-On Exercises

1. Install the Locust Operator via Helm; create a ConfigMap with a simple locustfile; apply a LocustTest CRD with 1 master + 2 workers.
2. Use kubectl port-forward to access the Web UI; run a 60-second test and check the Statistics tab.
3. Kill one worker Pod mid-test; observe the Operator recreating it and verify stats remain aggregated.

Proceed to Chapter 13: Non-HTTP Protocol Testing.