Great question! Testing request interception is a common need for validating app behavior, and you’ve got two solid paths forward: declarative YAML configurations (the go-to for most testing workflows) and programmatic control via Kubernetes client libraries. Let’s break down both options:

Option 1: YAML Configurations (Declarative, Ops-Friendly) #

This is the easiest way to set up request interception for testing, since you can define rules once and apply them directly to your cluster. Here are the most practical methods:

1. Network Policies #

You can use Kubernetes NetworkPolicy resources to block or restrict inbound HTTP traffic to specific Pods. This works at the network layer, so it’s great for testing "what if" scenarios where certain traffic is cut off.

Example YAML to block all inbound HTTP (port 80) traffic to Pods labeled app: my-test-app:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-http-to-test-pods
spec:
  podSelector:
    matchLabels:
      app: my-test-app
  policyTypes:
  - Ingress
  ingress: [] # Empty ingress rule means all inbound traffic is blocked

If you want to allow only specific sources (e.g., your test runner) and block others, you can add an ingress rule with from clauses.

2. Sidecar Proxies (Envoy/Istio) #

For more granular HTTP-level interception (like modifying requests, returning mock responses, or rate-limiting), sidecar proxies are perfect. OpenShift has built-in support for Istio via Service Mesh, but you can also deploy Envoy as a sidecar manually.

Example: Use Istio’s VirtualService to route HTTP requests to a mock service instead of your real Pod (great for testing error handling):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: intercept-test-app
spec:
  hosts:
  - my-test-app.default.svc.cluster.local
  http:
  - match:
    - uri:
        prefix: /api
    route:
    - destination:
        host: mock-api-service.default.svc.cluster.local # Your mock service

3. Ingress Controller Rules #

If your traffic comes through an Ingress (common for external access), you can use annotations or rewrite rules to intercept requests. For Nginx Ingress (used in OpenShift), you can block specific paths or redirect them to a test endpoint.

Example annotation to block all /api requests to your app:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/configuration-snippet: |
      location /api {
        return 403; # Block with 403 Forbidden
      }
spec:
  rules:
  - host: test-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-test-app
            port:
              number: 80

Option 2: Kubernetes Client Libraries (Programmatic Control) #

Yes, you can use Kubernetes client libraries to automate request interception—this is ideal if you need to dynamically adjust rules during test runs (e.g., block traffic at the start of a test, then unblock it afterward).

How It Works #

Client libraries (like client-go for Go, python-kubernetes for Python, or kubernetes-client/java for Java) let you interact with the Kubernetes API to create, update, or delete the same YAML resources we talked about above. For example:

• Use the library to create a NetworkPolicy when your test starts, then delete it when the test finishes.
• Programmatically update an Istio VirtualService to switch between real and mock endpoints based on test steps.

Example (Python) #

Here’s a quick snippet using python-kubernetes to create the NetworkPolicy we defined earlier:

from kubernetes import client, config

# Load cluster config (works for in-cluster or local kubectl config)
config.load_kube_config()

v1 = client.NetworkingV1Api()

# Define the NetworkPolicy
policy = client.NetworkingV1NetworkPolicy(
    api_version="networking.k8s.io/v1",
    kind="NetworkPolicy",
    metadata=client.V1ObjectMeta(name="block-http-to-test-pods"),
    spec=client.NetworkingV1NetworkPolicySpec(
        pod_selector=client.V1LabelSelector(match_labels={"app": "my-test-app"}),
        policy_types=["Ingress"],
        ingress=[]
    )
)

# Create the policy in the default namespace
v1.create_namespaced_network_policy(namespace="default", body=policy)

# Later, delete it when done testing
# v1.delete_namespaced_network_policy(name="block-http-to-test-pods", namespace="default")

Which Should You Choose? #

• YAML Configurations: Best for static testing scenarios where you can define rules upfront. It’s simple, requires no coding, and is easy to share with your team.
• Client Libraries: Perfect for dynamic, automated testing workflows where you need to adjust interception rules on the fly as part of your test suite.

内容的提问来源于stack exchange，提问作者Jeff