A/B testing with Ingress in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the Ingress API version.

Kubernetes

apiVersion: networking.k8s.io/[1]
kind: Ingress
metadata:
  name: example-ingress

Drag options to blanks, or click blank then click option'

Av1

Bv1beta1

Cv2

Dv1alpha1

Attempts:

3 left

💡 Hint

Common Mistakes

Using deprecated API versions like v1beta1 causes errors.

The current stable API version for Ingress is networking.k8s.io/v1.

2fill in blank

medium

Complete the code to define the host for the Ingress rule.

Kubernetes

spec:
  rules:
  - host: [1]
    http:
      paths:

Drag options to blanks, or click blank then click option'

Alocalhost

Bmyapp.local

Ctest.ingress

Dexample.com

Attempts:

3 left

💡 Hint

Common Mistakes

Using invalid host names or IP addresses here.

The host field specifies the domain name for routing traffic. example.com is a common placeholder.

3fill in blank

hard

Fix the error in the path type specification for Ingress.

Kubernetes

      paths:
      - path: /[1]
        pathType: Prefix
        backend:
          service:
            name: service-v1
            port:
              number: 80

Drag options to blanks, or click blank then click option'

Av2

Bv1

Cv1beta1

Dv1alpha1

Attempts:

3 left

💡 Hint

Common Mistakes

Using API version strings instead of URL path segments.

The path should be a string representing the URL path prefix, such as v1 for version 1 of the service.

4fill in blank

hard

Fill both blanks to route traffic to the correct service and port for version 2.

Kubernetes

      - path: /[1]
        pathType: Prefix
        backend:
          service:
            name: [2]
            port:
              number: 8080

Drag options to blanks, or click blank then click option'

Av2

Bservice-v2

Cservice-v1

Dv1

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing service names and paths between versions.

The path /v2 routes to the service-v2 on port 8080 for A/B testing.

5fill in blank

hard

Fill all three blanks to complete the Ingress rule for A/B testing with two services.

Kubernetes

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ab-testing-ingress
spec:
  rules:
  - host: [1]
    http:
      paths:
      - path: /[2]
        pathType: Prefix
        backend:
          service:
            name: [3]
            port:
              number: 80

Drag options to blanks, or click blank then click option'

Aexample.com

Bv1

Cservice-v1

Dv2

Attempts:

3 left

💡 Hint

Common Mistakes

Using mismatched paths and service names.

The host is example.com, path /v1 routes to service-v1 on port 80 for the first version.

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