End-to-End PR Testing in Kubernetes with Testkube and vCluster

Testing in Kubernetes at pull request (PR) time is essential, but it can be complex. Shared staging environments introduce risks of test collisions, flakiness, and resource contention. For teams moving fast and shipping often, confidence in each merge matters, and ephemeral, isolated environments are key.

Testkube can run complete test suites in ephemeral preview environments like vClusters, which allows teams to validate new features or patches in isolated, production-like clusters. It runs directly from the GitHub Actions pipeline to enable accurate, automated testing of every feature branch in isolated environments, without the overhead of managing infrastructure. It retains logs, artifacts, and results, even after environments are gone from any on-prem or cloud-managed Kubernetes cluster.

The Problem with Traditional PR Testing

Most teams rely on a shared staging environment for integration testing. While this can work early on, it quickly breaks down as teams scale or test complexity grows.

Key issues include:

• Test collisions from multiple PRs deploying to the same cluster
• Hard-to-reproduce bugs caused by shared or stale state
• Slow feedback loops when staging is overloaded or unavailable
• High cloud costs and complexity when spinning up full environments for every PR
• Limited visibility into test performance and resource usage

You need a way to run automated tests for every feature branch in clean, isolated, and cost-efficient environments, without managing infrastructure.

Meet the Stack

GitHub

Acts as the CI/CD trigger. When a pull request is opened or updated, GitHub Actions kicks off the pipeline. This orchestrates provisioning the virtual cluster, deploying the application, and running automated tests.

Testkube

Testkube is a cloud-native test orchestration platform that runs any kind of tests from inside your Kubernetes Clusters. Testkube uses custom resources (CRDs) to define test executions and integrates seamlessly with both GitOps tools and traditional CI/CD pipelines for centralized test scheduling, observability and analytics.

Testkube’s multi-agent architecture makes it easy to deploy lightweight Runner Agents into ephemeral Kubernetes clusters for running tests to validate both infrastructure and application functionality.

Testkube uses the concept of Test Workflows to define how to execute your tests, which includes advanced functionality like parallelisation, sharding, dependencies and test composition.

vCluster

vCluster spins up lightweight, virtual Kubernetes clusters within a namespace on a host cluster (like GKE). Each vCluster has its own API server and control plane components, providing complete isolation for workloads, RBAC, and namespaces, ideal for spinning up short-lived, production-like environments for every PR without the cost or overhead of full clusters.

Google Cloud (GKE)

Provides the physical Kubernetes infrastructure to run host clusters. GKE offers autoscaling, high availability, and enterprise-grade Kubernetes features, making it a reliable foundation for running multiple vClusters in parallel with efficient resource utilization.

Prerequisites

• A Kubernetes cluster(Could be on-premise or cloud-managed)
• Helm installed
• kubectl installed
• A Testkube account and Environment with the Testkube Standalone Agent deployed on the GKE cluster.
• A GitHub repository(Demo repository)
• A Test Workflow is created using the Testkube Dashboard in the Testkube Environment (A sample Test Workflow)

How It Works: Pull Request → vCluster → Testkube

1. A developer opens or updates a PR on GitHub.
2. GitHub Actions authenticates and connects to the GKE cluster.
3. GitHub Actions spins up a new vCluster named after the PR.
4. The application for which PR has been raised is deployed to this vCluster from the GitHub repository.
5. Github Actions provisions a Testkube Runner Agent in the ephemeral vCluster and connects it to the Testkube Control Plane and Environment containing the Test Workflows to run.
6. Github Actions triggers the execution of desired Testkube Workflows to run required tests on the provisioned Runner Agent 
7. Test results are visible in the GHA log and also stored in the Testkube Control Plane, where they can be seen in the Testkube dashboard.
8. After testing, the Testkube runner agent and vCluster is deleted as part of the pipeline to save costs.

Benefits of This Approach

• Realistic Testing: Run your tests in an isolated, production-like environment.
• Cost-Efficient: vClusters are far lighter than full clusters.
• Repeatable and scalable: Tests run the same way every time, no leftover state with reliable PR testing at scale.
• Test Visibility: Testkube gives detailed insights into test runs, resource usage, test performance metrics like durations, and failures.

Code Snippet: CI/CD Flow

With Testkube's capability to integrate with CI/CD like GitHub Actions and run on virtual clusters like vClusters on a cloud-managed cluster, here is the workflow that can automate the complete process.

Let us understand each step of this workflow that runs when a PR is raised against the `main` branch.

1. Authenticate to Google Cloud: Fetches the credentials from the repository secrets and authenticates to the Google Cloud account.
2. Manually install auth plugin: Installs the Google Cloud auth plugin, which provides the `gcloud` CLI.
3. Set up GKE credentials: Add GKE secrets to GitHub and use it to configure your GCP project and zone.
4. Install vCluster CLI: Installs the vCluster CLI
5. Create vCluster: Fetches the PR specific event number and uses it to append to the vCluster name created using the CLI
6. Connect to vCluster: Switches context to the vCluster and checks the status of resources.
7. Deploy Sample Application: Deploys the application on the vCluster for which the test has to be performed.
8. Set up Testkube: Configure Testkube account using Testkube GitHub Action with user-specific environment ID, organization ID, and API Token.
9. Provision ephemeral Testkube Runner Agent: With the Testkube Standalone agent running mandatory on your cluster, configure an ephemeral runner on the vCluster for test execution. Replace the environment name with user user-specific Testkube environment name.
10. Run Tests on Runner Agent: Run the curl-nginx-app Test Workflow (see below) for validating the deployment of our application. We’ll pass in the URL to the application and label the execution by adding a tag with PR specific details.
11. Disconnect vCluster and delete resources: Delete the resource created for performing the execution for cost optimization, like the ephemeral runner and the vCluster.

The Testkube Test Workflow

As mentioned above, Testkube uses Test Workflows to define how to run any kind of test from inside your Kubernetes clusters. The Test Workflow being run in this example (step 10 above) is a simple curl test to validate the availability of the application under test:

YAML
kind: TestWorkflow
apiVersion: testworkflows.testkube.io/v1
metadata:
  name: curl-nginx-app
  namespace: testkube
spec:
  config:
    url:
      type: string
  container: {}
  steps:
  - name: Run curl
    container:
      image: curlimages/curl:8.7.1
    shell: curl {{ config.url }}
status: {}

Read more about Test Workflows in the Testkube Documentation.

Observability & Resource Insights

With Testkube, testing goes beyond pass/fail, it becomes a window into how your workloads behave under test conditions. Testkube integration with GitHub Actions sets up the first window to test execution for the entire team.

Testkube not just runs tests but also gives visibility into test behavior:

• Track execution metrics like duration, CPU, and memory usage per test execution.

Note: Resource usage for a curl test was very low to record, hence added a snippet for a different test execution to demonstrate how Testkube can identify resource-heavy tests.

• Identify regressions by comparing test results and resource profiles across PRs and detect flaky tests by analyzing inconsistent results in repeat runs.

• Correlate test failures with application logs and cluster events for faster debugging. 

• Leverage Testkube’s dashboard and API to integrate insights into your observability stack using Webhooks (e.g., Prometheus, Grafana)

• Test Analytics: Since Testkube stores execution logs, artifacts and metrics for every execution one can do advanced analytics on test execution results over time

This enables teams to continuously refine their test coverage, adjust Kubernetes resource requests/limits, and improve deployment reliability, based on real data, not assumptions.

Clean-Up & Security

Ephemeral environments deliver value only when they are provisioned and torn down automatically, ensuring isolation, repeatability, and optimal resource utilization without overhead.

This setup ensures:

• vCluster teardown happens automatically at the workflow end.

• Secrets like GCP credentials and Testkube tokens are injected securely via GitHub Actions secrets.

Final Thoughts

This architecture enables staging-grade testing for every pull request, without the complexity of managing dedicated staging environments. It brings together powerful cloud native components in a cohesive workflow:

• vCluster provisions fully isolated, lightweight Kubernetes clusters per PR, ensuring clean, reproducible environments without impacting shared infrastructure.
  
  
• Testkube can deploy Runner Agents into ephemeral clusters, enabling in-cluster execution of any kind of test, with full access to services and logs, and deep integrations with your test tooling.
  
  
• GitHub Actions automates the entire lifecycle, provisioning, testing, and cleanup, driven by PR events, with secure handling of secrets and credentials.
  
  
• GKE provides scalable, production-grade infrastructure to back ephemeral environments reliably and cost-efficiently.
  
  

For engineering teams scaling their development velocity, managing growing test complexity, or adopting GitOps practices, this setup provides a robust foundation for automated, reliable, and resource-efficient PR testing workflows.

Get started with Testkube now to have a GitOps testing machine that is highly configurable. By adopting this approach, teams can shift left on reliability, catch regressions earlier, and scale testing without scaling complexity.

Join the Testkube Slack community to start a conversation or read Testkube documentation to start building fault-tolerant, automated test pipelines tailored to the organisation’s infrastructure.