A/B testing with Ingress in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding A/B Testing with Kubernetes Ingress

What is the primary purpose of using Kubernetes Ingress for A/B testing?

A To automatically scale backend pods based on traffic load

B To encrypt all traffic between clients and backend services

C To route a percentage of traffic to different backend services for comparison

D To store user session data for backend services

💡 Hint

Think about how traffic can be split to test different versions of an application.

Kubernetes Ingress can be configured to route traffic to different backend services based on rules, enabling A/B testing by sending a portion of users to different versions.

❓ Configuration

intermediate

Configuring Traffic Split in Ingress for A/B Testing

Given the following Ingress snippet, what percentage of traffic is routed to service-v2?

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ab-test-ingress
spec:
  rules:
  - http:
      paths:
      - path: /app
        pathType: Prefix
        backend:
          service:
            name: service-v1
            port:
              number: 80
      - path: /app
        pathType: Prefix
        backend:
          service:
            name: service-v2
            port:
              number: 80
  traffic:
    - serviceName: service-v1
      weight: 80
    - serviceName: service-v2
      weight: 20

A 0%

B 80%

C 50%

D 20%

💡 Hint

Look at the weight values assigned to each service.

The weight field defines the percentage of traffic routed to each service. Here, service-v2 has weight 20, meaning 20% of traffic.

💻 Command Output

advanced

Output of kubectl describe Ingress with A/B Testing Annotations

What output will you see when running kubectl describe ingress ab-test-ingress if the Ingress has the annotation nginx.ingress.kubernetes.io/canary: "true" on service-v2 path?

Kubernetes

kubectl describe ingress ab-test-ingress

A

Annotations:
  nginx.ingress.kubernetes.io/canary: "true"
Rules:
  Host: <none>
  Paths:
    /app -> service-v1:80
    /app -> service-v2:80 (canary)

B Error from server (NotFound): ingress "ab-test-ingress" not found

C

No annotations found
Rules:
  /app -> service-v1:80
  /app -> service-v2:80

D

Annotations:
  nginx.ingress.kubernetes.io/canary: "false"
Rules:
  /app -> service-v1:80

💡 Hint

Canary annotation marks the service as a canary deployment in the Ingress description.

The annotation nginx.ingress.kubernetes.io/canary: "true" marks the backend as canary, which is shown in the describe output next to the service path.

❓ Troubleshoot

advanced

Troubleshooting Traffic Not Splitting in A/B Testing

You configured an Ingress with two services for A/B testing, but all traffic goes to service-v1 only. What is the most likely cause?

A The services have different port numbers configured

B The Ingress controller does not support traffic splitting by weight

C The Ingress resource is missing the <code>spec.rules</code> section

D The backend pods are not labeled with <code>app=service-v2</code>

💡 Hint

Not all Ingress controllers support weighted traffic splitting.

Weighted traffic splitting is a feature supported by some Ingress controllers like NGINX with canary annotations or specific configurations. If the controller does not support it, traffic will not split.

🔀 Workflow

expert

Steps to Implement A/B Testing with Kubernetes Ingress

What is the correct order of steps to implement A/B testing using Kubernetes Ingress?

A 1,2,3,4

B 2,1,4,3

C 1,3,2,4

D 3,1,2,4

💡 Hint

Think about deploying first, then configuring routing, then monitoring, then adjusting.

The correct workflow is to first deploy both versions, then configure Ingress to split traffic, monitor results, and finally adjust traffic weights 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