In-Cluster Test Execution

What Is In-Cluster Test Execution?

In-cluster test execution runs tests inside the same Kubernetes cluster as the application under test. Each test runs as a native Job that creates its own pod.

Because tests live next to the app, they use the same networking, service discovery, configuration, and secrets. Results reflect how the system behaves in a real cluster, not on an outside machine.

How In-Cluster Test Execution Works

1. Trigger: a pipeline, schedule, or cluster event starts the run.
2. Schedule: Kubernetes schedules a Job, and the Job creates a test pod.
3. Execute: the pod runs the test against in-cluster services.
4. Collect: logs, results, and artifacts are gathered and stored.
5. Clean up: the pod exits, and cluster resources are released.

In-Cluster vs. Remote Test Execution

Both models can run the same tests. The difference is where the test code runs.

What Runs Well In-Cluster

• Integration tests: services calling each other on internal DNS
• API tests: endpoints that are not exposed outside the cluster
• Load tests: traffic generated close to the target service
• Smoke tests: quick checks right after a deployment
• End-to-end tests: browser tests that reach internal and external services alike

Why In-Cluster Execution Matters

Tests that run outside the cluster miss real network paths and policies. Results can pass in CI and still fail in production.

• Real behavior: network policies, DNS, and service mesh rules apply to tests.
• No exposed endpoints: internal services stay private while still being tested.
• Elastic capacity: test pods use cluster nodes instead of a fixed agent pool.
• Simpler pipelines: CI triggers tests instead of running them.
• Better security: credentials stay in the cluster rather than in CI systems.

Real-World Example

A B2B SaaS team has a payment service that only listens on an internal address. Their CI-based tests needed tunnels and extra firewall rules to reach it.

1. Move execution: the team runs the payment API suite in-cluster with Testkube.
2. Call directly: tests reach the service on internal DNS, like any other service.
3. Trigger from CI: the pipeline starts the run and waits for the result.

The tunnels are gone, and results now match how the service behaves in production.

How In-Cluster Execution Relates to Testkube

Testkube runs all tests inside Kubernetes clusters using native Jobs. Each test gets an isolated pod, with no external CI agents required.

Testkube adds secure secret injection, namespace control, webhook integrations, and artifact storage. Results stay in one place across clusters and pipelines.

Best Practices for In-Cluster Testing

• Use dedicated namespaces: keep test pods separate from production workloads.
• Set resource limits: stop large suites from starving application pods.
• Inject secrets from the cluster: avoid copying credentials into pipelines.
• Clean up after runs: remove temporary data and resources.
• Centralize results: collect results from every cluster in one place.

Frequently Asked Questions (FAQs)