Bird
Raised Fist0
Kubernetesdevops~5 mins

A/B testing with Ingress in Kubernetes - Cheat Sheet & Quick Revision

Choose your learning style10 modes available
LearnWhyDeepVisualTryChallengeProjectRecallTime

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Recall & Review
beginner
What is A/B testing in the context of Kubernetes Ingress?
A/B testing is a method to compare two versions of an application by routing a portion of user traffic to each version using Kubernetes Ingress rules.
Click to reveal answer
beginner
How does Kubernetes Ingress help implement A/B testing?
Ingress can route traffic based on rules like URL paths or headers, allowing splitting user requests between different backend services representing different app versions.
Click to reveal answer
intermediate
What is a common way to split traffic for A/B testing using Ingress?
Using annotations or Ingress controllers that support weighted routing to send a percentage of traffic to different backend services.
Click to reveal answer
intermediate
Name one popular Ingress controller that supports advanced traffic splitting for A/B testing.
NGINX Ingress Controller supports annotations for traffic splitting and can be used for A/B testing.
Click to reveal answer
beginner
Why is monitoring important during A/B testing with Ingress?
Monitoring helps track user behavior and performance on each version to decide which one works better before full rollout.
Click to reveal answer
What does A/B testing with Kubernetes Ingress primarily involve?
AScaling pods automatically
BBacking up cluster data
CUpdating container images
DRouting traffic between two versions of an app
Which Ingress feature is commonly used to split traffic for A/B testing?
APersistent volumes
BPod autoscaling
CWeighted routing
DNamespace isolation
Which annotation might you use with NGINX Ingress for traffic splitting?
Akubernetes.io/ingress.class
Bnginx.ingress.kubernetes.io/canary-weight
Cnginx.ingress.kubernetes.io/rewrite-target
Dkubernetes.io/limit-rps
Why should you monitor traffic during A/B testing?
ATo compare performance and user experience
BTo increase pod replicas
CTo backup data
DTo update Ingress rules automatically
What is a canary deployment in the context of A/B testing?
AA small portion of traffic sent to a new version
BA full rollout of a new version
CDeleting old pods
DScaling down services
Explain how Kubernetes Ingress can be configured to perform A/B testing between two application versions.
Think about how traffic can be divided between different services using Ingress.
You got /4 concepts.
    Describe why monitoring is crucial during an A/B test using Ingress and what metrics you might watch.
    Consider what information helps decide which app version is better.
    You got /4 concepts.

      Practice

      (1/5)
      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