The Locust K8s Operator v2.0 is a complete Go rewrite that solves the slow, clunky Python-based pains of v1. Learn how to achieve a zero-downtime migration, get faster test startups, and leverage native OpenTelemetry for your performance testing pipeline.

From Python Sludge to Go Speed: Our Playbook for the Locust K8s Operator v2.0 Upgrade

I remember it like it was yesterday. It was 2 AM, the “go/no-go” call for our biggest feature launch of the year. Everything was green, except for the final performance test sign-off. “Should be 15 minutes, tops,” I’d told my director. An hour later, we were still staring at a Kubernetes dashboard, watching the Locust worker pods churn in a ‘Pending’ state. The old Python-based operator was struggling, taking an eternity to reconcile the state and spin up the cluster. We made the launch, but that delay, that gnawing uncertainty caused by our own tooling, stuck with me. If you’ve ever felt that pain, you’ll understand why the news of the v2.0 Go rewrite of the Locust Operator wasn’t just ‘nice-to-have’ news; it was a game-changer.

So, What Was Really Wrong With V1 Anyway?

Let’s be clear: the v1 operator was a fantastic piece of work that brought Locust to Kubernetes for many of us. But it had an architectural handicap: it was written in Python. For a Kubernetes operator, which is essentially a control loop constantly watching and reconciling resources, the overhead of a Python interpreter, its GIL (Global Interpreter Lock), and slower startup times were becoming a noticeable bottleneck, especially in large, dynamic clusters.

The move to Go for v2 isn’t about language snobbery. It’s about using the right tool for the job. Go is compiled to a static binary, making it incredibly fast to start. Its native support for concurrency with goroutines is tailor-made for the operator pattern, allowing it to manage many resources efficiently without breaking a sweat. The result? Pods that start in seconds, not minutes, and an operator that sips resources instead of chugging them. Plus, we get first-class OpenTelemetry support baked in, which is huge for observability.

Our Migration Playbook: From Cautious to Committed

When we saw the v2 announcement, we didn’t just jump in headfirst on our production clusters. We came up with a tiered approach to validate it and roll it out safely. Here’s our playbook, from the simple test drive to the full, zero-downtime migration.

Approach 1: The “Parallel Universe” Test Drive

This is the safest first step. Don’t touch your existing, working v1 installation. We’re going to install the v2 operator in a completely separate namespace to kick the tires. This lets you run tests and validate its performance without any risk to your current CI/CD pipelines that depend on the old operator.

First, add the new Helm repo:

helm repo add locust-operator https://locust-operator.github.io/locust-operator

Now, install the v2 operator into a new namespace, let’s call it locust-v2-testing.

helm install locust-operator-v2 locust-operator/locust-operator \
--version 2.0.0 \
--namespace locust-v2-testing \
--create-namespace

You now have a clean, isolated v2 environment. You can create new LocustTest custom resources in that namespace and see the speed difference for yourself. Your old operator in the default or locust namespace will remain completely untouched.

Approach 2: The Official Zero-Downtime Migration (The Right Way)

Okay, this is where the real magic is. The new Go operator is smart enough to adopt the resources managed by the old one without causing any downtime for your tests. This is the path we took for our staging and production clusters.

Pro Tip: Before you start, ALWAYS back up your existing LocustTest custom resources. A simple kubectl get locusttest --all-namespaces -o yaml > locust-backup.yaml will save you if something goes wrong.

The key is to install the v2 operator into the same namespace as your v1 operator, but crucially, you prevent it from running its controller manager just yet by setting replicas to 0.

# Assuming your v1 operator is in the 'locust' namespace
helm upgrade --install locust-operator locust-operator/locust-operator \
--version 2.0.0 \
--namespace locust \
--set controllerManager.replicas=0

This installs all the new v2 components but keeps the brain turned off. Now, the graceful handoff. First, scale down the old v1 operator:

# The deployment name might vary based on your Helm release name
kubectl scale deployment/locust-operator-controller-manager --replicas=0 -n locust

Once the old operator is scaled down, you can scale up the new v2 operator. It will see the existing CRDs and tests, take over leadership election, and start managing them seamlessly.

kubectl scale deployment/locust-operator-controller-manager --replicas=1 -n locust

After confirming everything is stable, you can safely remove the old v1 operator’s Helm release. This process felt like changing a tire on a moving car, but it worked flawlessly for us.

Approach 3: The “Nuke and Pave” (For a Clean Slate)

Sometimes, an old installation is just too messy. Maybe you have manual tweaks, weird configs, or you just want a completely fresh start. This is the ‘nuclear’ option. It’s simple, but destructive.

WARNING: This approach will completely uninstall the v1 operator AND its Custom Resource Definition (CRD). Deleting the CRD will permanently delete all of your defined LocustTest resources across the entire cluster. Proceed with extreme caution and ensure you have backups!

First, completely remove the old Helm release:

# Replace 'my-old-locust-release' with your v1 Helm release name
helm uninstall my-old-locust-release -n locust

Now, the dangerous part. Delete the CRD:

kubectl delete crd locusttests.locust.io

Your cluster is now completely clean of the old operator. You can now do a fresh, standard installation of the v2 operator.

helm install locust-operator locust-operator/locust-operator \
--version 2.0.0 \
--namespace locust \
--create-namespace

This is the cleanest way to start, but it requires you to redeploy all of your test definitions. We used this for our dev environment, where tests are ephemeral anyway.

Ultimately, the upgrade to the v2.0 Locust Operator has been a massive quality-of-life improvement for my team at TechResolve. Our tests are faster, our pipelines are more reliable, and I can sleep a little easier during those late-night release calls.

---

🤖 Frequently Asked Questions