A/B testing with Ingress in Kubernetes - Step-by-Step Execution

Process Flow - A/B testing with Ingress

User sends request

↓

Ingress receives request

↓

Check routing rules

↓

Route to Service A (e.g., 70% traffic)

↓

Route to Service B (e.g., 30% traffic)

↓

Service A or B processes request

↓

Response sent back to user

User requests come to Ingress, which routes them to different services based on defined traffic weights for A/B testing.

Execution Sample

Kubernetes

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ab-testing-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: service-a
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: service-b
            port:
              number: 80

Example Ingress defining backends for service-a and service-b. Note: Native Kubernetes Ingress does not support weighted traffic splitting (e.g., 70/30). Use an Ingress controller like NGINX with canary annotations (nginx.ingress.kubernetes.io/canary: "true", nginx.ingress.kubernetes.io/canary-weight: "30") for actual A/B testing. The execution simulates weighted routing.

Process Table

Step	Request ID	Ingress Routing Decision	Traffic Weight	Service Routed	Response
1	req-001	Check routing rules	70% to service-a, 30% to service-b	service-a	Response from service-a
2	req-002	Check routing rules	70% to service-a, 30% to service-b	service-b	Response from service-b
3	req-003	Check routing rules	70% to service-a, 30% to service-b	service-a	Response from service-a
4	req-004	Check routing rules	70% to service-a, 30% to service-b	service-a	Response from service-a
5	req-005	Check routing rules	70% to service-a, 30% to service-b	service-b	Response from service-b
6	req-006	Check routing rules	70% to service-a, 30% to service-b	service-a	Response from service-a
Exit	-	Traffic routing complete for requests	-	-	-

💡 All requests routed according to 70/30 traffic split; testing complete

Status Tracker

Variable	Start	After req-001	After req-002	After req-003	After req-004	After req-005	After req-006	Final
service-a count	0	1	1	2	3	3	4	4
service-b count	0	0	1	1	1	2	2	2

Key Moments - 2 Insights

How does Ingress decide which service to route a request to?

Ingress uses the defined traffic weights (e.g., 70% to service-a, 30% to service-b) to route requests probabilistically, as shown in the execution_table where requests are distributed accordingly.

Why do some requests go to service-b even though service-a has higher traffic weight?

Because traffic is split by percentage, some requests will go to service-b to test the alternative version; this is visible in execution_table rows where service-b handles some requests.

Visual Quiz - 3 Questions

Look at the execution_table, how many requests were routed to service-b after 6 requests?

A 2

B 3

C 4

D 1

💡 Hint

Check the 'Service Routed' column in execution_table rows for requests routed to service-b.

At which step does the third request get routed to service-a?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Request ID' and 'Service Routed' columns in execution_table.

If the traffic weight changes to 50% for each service, how would the variable_tracker change after 6 requests?

A service-b count would be 6, service-a 0

B service-a count would be 6, service-b 0

C service-a and service-b counts would be about equal, around 3 each

D service-a count would be 4, service-b 2

💡 Hint

Traffic weights control distribution; equal weights mean roughly equal counts in variable_tracker.

Concept Snapshot

A/B testing with Ingress routes user requests to multiple services.
Traffic split is controlled by weights (e.g., 70% to service-a, 30% to service-b).
Ingress checks routing rules for each request and sends it accordingly.
This allows testing different versions live without downtime.
Monitor counts to verify traffic distribution matches weights.

Full Transcript

In A/B testing with Ingress, user requests come to the Ingress controller. The Ingress checks routing rules that define how to split traffic between two services, for example, 70% to service-a and 30% to service-b. Each request is routed based on these weights. Over multiple requests, the distribution approximates the defined split. This lets you test different versions of your app live. The execution table shows each request's routing decision and response. The variable tracker counts how many requests each service handled. Key points include understanding how routing decisions are made and why some requests go to the lower-weighted service. Changing traffic weights changes the distribution of requests accordingly.

Practice

1. What is the main purpose of using A/B testing with Kubernetes Ingress?

easy

A. To monitor CPU usage of pods

B. To increase the number of pods automatically

C. To split user traffic between different versions of an application

D. To backup Kubernetes cluster data

Solution

1. Step 1: Understand A/B testing concept in Kubernetes

   A/B testing with Ingress is used to route traffic between different app versions to test new features safely.

2. Step 2: Identify the purpose of Ingress in traffic management

   Ingress controls how external traffic reaches services, enabling traffic splitting for A/B testing.

3. Final Answer:

   To split user traffic between different versions of an application -> Option C

4. Quick Check:

   A/B testing = traffic split [OK]

Hint: A/B testing means splitting traffic between app versions [OK]

Common Mistakes:

• Confusing A/B testing with scaling pods
• Thinking Ingress is for monitoring only
• Assuming Ingress handles backups

2. Which annotation is commonly used in Kubernetes Ingress to split traffic by percentage for A/B testing?

easy

A. nginx.ingress.kubernetes.io/canary-weight

B. nginx.ingress.kubernetes.io/rewrite-target

C. nginx.ingress.kubernetes.io/ssl-redirect

D. nginx.ingress.kubernetes.io/proxy-body-size

Solution

1. Step 1: Identify annotations for traffic splitting

   The annotation 'nginx.ingress.kubernetes.io/canary-weight' is used to specify the percentage of traffic sent to the canary version.

2. Step 2: Differentiate from other annotations

   Other annotations like rewrite-target or ssl-redirect serve different purposes unrelated to traffic splitting.

3. Final Answer:

   nginx.ingress.kubernetes.io/canary-weight -> Option A

4. Quick Check:

   Canary weight = traffic percentage [OK]

Hint: Look for 'canary-weight' to split traffic by percent [OK]

Common Mistakes:

• Using rewrite-target for traffic splitting
• Confusing SSL redirect with traffic control
• Ignoring canary annotations

3. Given this Ingress snippet for A/B testing, what percentage of traffic goes to the canary service?

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "30"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: stable-service
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: canary-service
            port:
              number: 80

medium

A. 70%

B. 30%

C. 50%

D. 100%

Solution

1. Step 1: Read the canary-weight annotation

   The annotation 'nginx.ingress.kubernetes.io/canary-weight' is set to "30", meaning 30% of traffic goes to canary.

2. Step 2: Understand traffic split logic

   Traffic is split by percentage; 30% to canary-service, remaining 70% to stable-service.

3. Final Answer:

   30% -> Option B

4. Quick Check:

   Canary weight = 30% traffic [OK]

Hint: Check canary-weight value for traffic percent [OK]

Common Mistakes:

• Assuming canary gets 70% instead of 30%
• Confusing service names with traffic percentages
• Ignoring canary annotation

4. You configured this Ingress for A/B testing but all traffic goes to the stable service only. What is the likely error?

metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "50"
spec:
  rules:
  - host: test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: stable-service
            port:
              number: 80

medium

A. Missing canary backend path in spec

B. Incorrect canary-weight value format

C. Host name is invalid

D. Stable service port is wrong

Solution

1. Step 1: Check Ingress spec for canary backend

   The spec only has one backend for stable-service; no path defined for canary-service.

2. Step 2: Understand traffic routing requirements

   For canary traffic to work, a separate path with canary annotations and backend service must be defined.

3. Final Answer:

   Missing canary backend path in spec -> Option A

4. Quick Check:

   Canary needs separate backend path [OK]

Hint: Ensure canary backend path exists in Ingress spec [OK]

Common Mistakes:

• Assuming canary-weight alone routes traffic
• Ignoring missing canary backend path
• Blaming host or port without checking paths

5. You want to route 20% of users with header X-User-Type: beta to the canary service and the rest to stable. Which Ingress annotation setup achieves this?

hard

A. Use nginx.ingress.kubernetes.io/canary-by-cookie: "beta"

B. Use nginx.ingress.kubernetes.io/canary-weight: "20" only

C. Use nginx.ingress.kubernetes.io/canary: "false"

D. Use nginx.ingress.kubernetes.io/canary-by-header: "X-User-Type" and nginx.ingress.kubernetes.io/canary-by-header-value: "beta"

Solution

1. Step 1: Identify header-based routing annotations

   To route traffic based on header, use 'canary-by-header' and 'canary-by-header-value' annotations.

2. Step 2: Understand difference from weight-based routing

   Weight-based routing splits traffic by percentage regardless of headers; header-based routing targets specific users.

3. Final Answer:

   Use nginx.ingress.kubernetes.io/canary-by-header: "X-User-Type" and nginx.ingress.kubernetes.io/canary-by-header-value: "beta" -> Option D

4. Quick Check:

   Header-based routing uses canary-by-header annotations [OK]

Hint: Use canary-by-header and canary-by-header-value for header routing [OK]

Common Mistakes:

• Using only canary-weight for header routing
• Confusing cookie-based routing with header routing
• Setting canary to false disables routing