How do I test microservices in Kubernetes without a test cluster?

Record traffic inside a running pod with Keploy. It captures the requests the service serves and every downstream call it makes, then replays them in CI as a plain process — with no cluster, namespace, or chart install.

Is Keploy an alternative to ephemeral namespaces?

For most integration tests, yes. Ephemeral namespaces install a full stack and wait for readiness in every pipeline. Keploy records that stack once and replays it in seconds. Keep a namespace for true end-to-end checks before release.

Does Keploy capture service-to-service calls in a cluster?

Yes, and that is the main reason to use it here. A pod's calls to other services — HTTP, gRPC, and database traffic — are all recorded, so one recording covers the whole request path across the cluster.

Do I need a sidecar or service mesh for Keploy?

No. Keploy records at the socket inside the pod, so no sidecar is injected and no mesh is required. That also means the request path under test is the application's own, without an extra proxy hop.

Does Keploy work with Istio or Linkerd?

Recording works alongside a mesh, and mesh-level features are not required. Capture through a mesh sidecar is partially supported — check the repository for the current state before depending on it.

Is Keploy free to use with Kubernetes?

Yes. The Keploy CLI is open source under Apache 2.0 and free to run on any workload with no seat limits. Paid cloud plans add hosted test storage, dashboards, and team management.

Keploy as a Kubernetes testing framework

Keploy records traffic inside a running Kubernetes pod, capturing the requests a service serves and every downstream call it makes across the cluster, then replays them in CI. No test cluster, ephemeral namespace, or service mesh is needed to run the resulting tests.

Generate Kubernetes tests free

keploy record -c "./orders-service"

18.4K+

1.2M+300M+mocks createdSlack

What Keploy gives a Kubernetes team

Any workload, any language

Keploy records inside the pod at the socket layer, so the container image, language, and framework do not matter. A Deployment, StatefulSet, or Job all record the same way.

Any container image or runtime
Deployments, StatefulSets, and Jobs
No sidecar injection required
No mesh or CNI dependency

Try Keploy for free Explore the docs

The problem

Why Kubernetes integration tests slow teams down

The friction is rarely the assertions. It is everything around them — spinning up dependencies, keeping mocks honest, and repairing tests after every refactor.

Book a call Explore the docs

Three ways to do it

Testing Kubernetes: by hand, with ephemeral namespaces, or with Keploy

Ephemeral namespaces give real cluster fidelity and make every pipeline wait for a full stack. Keploy records that stack once and replays it as a plain process.

By hand

ephemeral namespaces

With Keploy

Select any row for the full comparison, with code.

Get started Book a call

Same coverage, three costs

What you write for Kubernetes vs what Keploy records

All three produce the same assertion. Only the third still passes after the next refactor without anyone editing it.

By hand2–4 hours

deps_fakes.go

hand-written

// Hand-written: one fake per dependent service.

package testsupport

// Three services this one calls, three fakes to maintain.

type FakeInventory struct{}

func (FakeInventory) Reserve(sku string, n int) error { return nil }

type FakePricing struct{}

func (FakePricing) Quote(sku string) (int64, error) { return 4200, nil }

type FakeNotifications struct{}

func (FakeNotifications) Send(userID, template string) error { return nil }

Three fakes for three services, each encoding a contract another team owns. Every one of them goes stale the week that team ships.

ephemeral namespaces1–2 hours

ci-ephemeral-namespace.yaml

tool-assisted

# An ephemeral namespace per pull request.

name: integration

on: [pull_request]

jobs:

e2e:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- name: Create namespace

run: kubectl create namespace pr-${{ github.event.number }}

- name: Install the whole stack

run: helm install stack ./charts --namespace pr-${{ github.event.number }}

# Every dependency has to become ready before the first assertion.

- name: Wait for readiness

run: kubectl wait --for=condition=ready pod --all --timeout=600s

- name: Seed data

run: ./scripts/seed.sh

- name: Run tests

run: go test ./e2e/...

The highest-fidelity option there is, and the pipeline spends most of its time installing charts and waiting for pods rather than testing.

With Keploy~5 minutes

ci-replay.yaml

auto-generated

# Replay recorded pod traffic — no cluster involved.

name: integration

on: [pull_request]

jobs:

replay:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- name: Install Keploy

run: curl -sSL https://keploy.io/install.sh | bash

- name: Build

run: go build -o orders-service ./cmd/service

# No namespace, no Helm, no readiness wait, no seed step.

- name: Replay

run: keploy test -c "./orders-service" --delay 8

The recorded pod traffic includes every downstream service call, so this job exercises the same request path without deploying a single dependency.

Times are estimates for authoring one endpoint’s coverage from scratch, not measurements.

Explore the docs Request a trial

Keploy vs the alternatives

Kubernetes testing tools, compared

The options a team on service and platform integrations actually reaches for, and where each one genuinely wins. Select a row for the full comparison.

Keploy

WireMock

LocalStack

Mountebank

Hoverfly

Postman

SmartBear ReadyAPI

Best in classStrongPartialNot covered

Assessments reflect each tool’s documented behaviour, not benchmark measurements.

Request a trial Book a call

How it works

Record your Kubernetes app once, replay it forever

Keploy sits below your Kubernetes process at the network layer. It watches the calls your app already makes, then serves them back on replay so tests run with no dependencies attached.

Your Kubernetes appGET/api/v1/orders/{id}200

RecordingKeploy proxyeBPF · userspace

Service-to-service HTTPAny in-cluster REST call between pods

gRPCHTTP/2 framed calls between services

PostgreSQLPostgres protocol to an in-cluster or managed database

MySQLMySQL protocol to an in-cluster or managed database

+4 more Kubernetes dependencies

An example shape of a captured call. Your own endpoints and dependencies come from your real traffic, so nothing here has to be written by hand.

Try Keploy for free Request a trial

Mock coverage

What Keploy mocks for Kubernetes, with zero config

7 of the 8 dependencies a typical Kubernetes service talks to are stubbed from the recording itself — no mock classes, no fixture files, no containers in CI.

Service-to-service HTTP
Auto-mocked
Service-to-service HTTP
Any in-cluster REST call between pods
Auto-mocked
gRPCView page
HTTP/2 framed calls between services
Auto-mocked
PostgreSQLView page
Postgres protocol to an in-cluster or managed database
Auto-mocked
MySQLView page
MySQL protocol to an in-cluster or managed database
Auto-mocked
RedisView page
RESP to an in-cluster cache
Auto-mocked
Apache KafkaView page
Kafka protocol to an in-cluster broker
Auto-mocked
MongoDBView page
Wire protocol to an in-cluster or managed cluster
Partial
Istio and Linkerd
Recording through a mesh sidecar

Explore the docs Book a call

Quick start

Your first Kubernetes test suite in under five minutes

Every command below runs against your existing Kubernetes service. Nothing in your source tree changes.

1
1Install the Keploy CLI
A single binary. It needs a Linux kernel with eBPF support, or Docker on macOS and Windows — and it adds nothing to your project's dependencies.
curl -sSL https://keploy.io/install.sh | bash
2
2Record your service
Pass the command you already use to start the app. Keploy runs it and watches every socket it opens.
keploy record -c "./orders-service"
3
3Exercise the paths you care about
Record inside the pod while real traffic flows. Every downstream service, database, and cache call the request triggered is captured with it.
kubectl port-forward svc/orders 8080:80
curl -X POST localhost:8080/orders/ord_1/confirm -d '{"paymentToken":"tok_123"}'
4
4Replay in CI
Replay serves the recorded dependency responses, so the job needs no service containers and no Docker daemon.
keploy test -c "./orders-service" --delay 8