Running Automated Tests as Native Kubernetes Workloads (Without Building Custom Operators)

Your platform team standardized deployments with Argo or Flux. You run 85% of your workloads in Kubernetes. Infrastructure is declarative, version-controlled, and reproducible. Then someone asks you to add automated testing to the delivery pipeline, and suddenly you are back to writing bespoke scripts.

The pattern repeats every time a new testing tool enters the stack. QA wants Playwright for E2E tests. The backend team runs k6 for load testing. Someone on the SRE team has a collection of curl-based smoke tests they run manually after incidents. Each tool needs its own operator, its own scaling config, its own way of collecting results. You end up maintaining a growing list of custom integrations that have nothing to do with your actual platform work.

This is the custom operator trap. It is not that any single integration is hard. It is that the maintenance surface grows with every framework, and none of these bespoke solutions talk to each other. You have test results scattered across pipeline logs, Slack notifications, and Grafana dashboards that someone set up six months ago and nobody has touched since.

Tests as native Kubernetes jobs: what changes at the infrastructure level

The shift is conceptually simple. Instead of running tests inside CI pipeline containers or through custom operators, you run them as native Kubernetes jobs. The same scheduler that manages your production workloads manages your test workloads. Pod scheduling, resource requests, node affinity, namespace isolation: all the infrastructure patterns you already use for applications apply directly to test execution.

This means your test workloads inherit everything you have already built into your cluster: RBAC policies, network policies, resource quotas, service mesh configuration. A Playwright test running as a K8s job in your staging namespace has the same network path to your application as a real user would. A k6 load test can hit internal services without tunneling through a VPN or punching holes in your network policies.

The practical benefit for platform teams is that tests become workloads you manage the same way you manage everything else. No special infrastructure. No separate scaling story. No operators to maintain per framework.

Elastic scaling for test workloads on your existing infrastructure

Kubernetes already knows how to scale workloads. When you run tests as K8s jobs, you get elastic scaling for free: shard a Playwright suite across 20 pods, run k6 with distributed load generation across nodes, execute a matrix of browser and API tests in parallel. The cluster autoscaler handles the rest.

The trade-off is between test isolation and resource efficiency. Running every test in its own pod gives you clean isolation but costs more compute. Running multiple tests per pod reduces overhead but introduces contention. This scales well until you hit approximately 500 concurrent jobs, at which point you need to revisit your resource allocation strategy and possibly look at dedicated node pools for test workloads. The right answer depends on your cluster size and how much spare capacity you carry.

Version-controlled tests synced via Argo and Flux

If your deployment workflow is GitOps-native, your testing workflow should be too. Tests defined as CRDs, stored in Git, synced to clusters through Argo CD or Flux. Change a test configuration in a pull request, get it reviewed like any other infrastructure change, merge it, and it is live in the cluster on the next sync cycle.

This is the difference between testing infrastructure that fits your platform and testing infrastructure that runs alongside it as a parallel system you have to manage separately. When tests are CRDs, they are resources. Your existing tooling for managing resources (GitOps, RBAC, namespace scoping, audit logs) applies without modification.

Orchestrating Playwright, k6, and curl from one control plane

The Aspen Group runs roughly 90 microservices across multiple brands in healthcare. Their Director of Platform Engineering, Joel Vasallo, described their situation before they had an orchestration layer: "One team might be doing manual QA, another writing integration tests with their own tools. Everyone had their own way of doing things. It was totally decentralized."

That decentralization is common. And it is workable until it is not. For TAG, the breaking point was a P1 outage on a Saturday. Their dedicated QA engineer was unreachable. A critical release was blocked. The SRE team needed a way to validate a fix, and the only person who knew how to run the tests was not available.

The key insight from Joel's experience is that a platform-level orchestration layer needs to be framework-agnostic. "One team might use Playwright. Another might use k6. Someone else might just want to write a curl test. Testkube doesn't care, it just runs it all." When the entry point is low enough (a curl test counts), teams that are not deep in automation can start contributing. When the ceiling is high enough (Playwright with parallel sharding), teams that need sophisticated testing can get it without building custom infrastructure.

From ad-hoc scripts to Test Orchestration: the missing infrastructure layer

If you are a platform engineer, you have probably built some version of this yourself. A CronJob that runs smoke tests. A custom controller that watches for deployment events and triggers a test suite. A Slack webhook that posts results from a script someone wrote in a weekend. Each piece works, but the whole thing is held together with duct tape, and you are the only person who understands how it fits together.

The pattern you are building toward has a name: test orchestration. It is an infrastructure layer that sits between your CI/CD pipeline (which triggers tests) and your test frameworks (which define tests). The orchestration layer handles the parts that neither CI/CD nor test frameworks were built for: scheduling test workloads as K8s jobs, routing tests to the right cluster or namespace, collecting results and artifacts into one place, managing parallel execution and sharding, and providing a single interface that QA, Dev, and SRE teams can all use without requiring deep Kubernetes expertise.

Testkube is purpose-built for this layer. It runs natively in Kubernetes, supports any test framework through pre-built and custom executors, integrates with Argo, Spinnaker, and any CI/CD tool as a trigger source, and stores test definitions as CRDs that fit into your GitOps workflow. Joel described how it fit into TAG's stack: "Triggering tests as Kubernetes jobs meant I could integrate them into our workflows, Argo, Spinnaker, whatever. It just worked."

Centralized logs, artifacts, and health scores in Your Cluster

When test results are scattered across pipeline logs, Slack channels, and individual dashboards, the platform team becomes the bottleneck for answering a basic question: did the tests pass?

A test orchestration layer centralizes this by default. Every test execution, regardless of framework or trigger, reports results to the same place. Logs, artifacts (including Playwright recordings and screenshots), execution history, and pass/fail trends are all accessible through one dashboard or CLI. Joel noted this mattered for teams beyond engineering: "Most of us live in the CLI, but that's not true for everyone. Testkube gives you a visual dashboard, historical test data, and even recordings of Playwright runs. That accessibility matters."

For platform teams specifically, this means you stop being the intermediary between test execution and test results. QA can see their Playwright results. SREs can check smoke test status after an incident. Developers can verify their integration tests passed. Nobody files a ticket asking you to dig through pod logs.

How The Aspen Group moved from curl scripts to a shared testing platform

The Aspen Group (TAG) is a healthcare services platform with 14,000+ employees, roughly 90 microservices, and 85% of workloads running in Kubernetes. Their infrastructure was modern. Their testing was not. When Joel Vasallo joined as Director of Platform Engineering, teams used a patchwork of curl commands and isolated scripts. "We moved from a set of monolithic VMs hosting over 900 APIs to roughly 80 to 150 microservices across all the brands," Joel said. The infrastructure had been modernized. Testing had not kept pace.

The Saturday P1 outage was the turning point. The QA engineer was unreachable, a release was blocked, and the SRE team pulled up a Testkube proof of concept that had recently gone live. The tests were not comprehensive, but they were enough to give the CTO confidence to ship a fix. "That moment proved that testing didn't have to be tied to a person," Joel said. "It could be tied to a process. And that process could scale."

Joel had discovered Testkube at KubeCon. He chose it because it fit the platform patterns TAG already used: Kubernetes-native jobs, GitOps sync, framework-agnostic execution. Teams bring their own tools. Tests are version-controlled and treated like deployments. "We're helping QA understand that tests should be treated like deployments," Joel said. "You version them. You source control them. That's the graduation from QA to quality engineering."

Today, testing at TAG is a shared process across QA, Dev, and SRE. The platform team owns deployment. QA creates and curates test libraries. Developers contribute tests directly. SREs use the same jobs to validate fixes post-incident. Joel summed it up: "I'm not selling Testkube as a QA tool. I'm selling it as a testing platform for everyone. It's the glue."

See how this fits your platform stack

If you are maintaining custom operators, bespoke scripts, or ad-hoc CronJobs to run tests in Kubernetes, you are building a test orchestration layer by hand. Testkube is that layer, built as a product so you can stop maintaining it as a side project.

It runs in your clusters, supports any framework, fits into your GitOps workflow, and gives your entire organization a single interface for test execution and results. Explore the architecture documentation, try our trial, or see a demo of how it integrates with Argo and Flux.