Canary deployments in Kubernetes - Time & Space Complexity

Time Complexity: Canary deployments

O(n)

Understanding Time Complexity

When using canary deployments in Kubernetes, it's important to understand how the deployment process scales as you increase the number of users or pods.

We want to know how the time to roll out changes as the system grows.

Scenario Under Consideration

Analyze the time complexity of the following Kubernetes deployment snippet for a canary release.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-canary
spec:
  replicas: 10
  selector:
    matchLabels:
      app: my-app-canary
  template:
    metadata:
      labels:
        app: my-app-canary
    spec:
      containers:
      - name: my-app-container
        image: my-app:v2-canary
        resources:
          limits:
            cpu: "500m"
            memory: "256Mi"

This snippet creates 10 pods running the canary version of the app alongside existing stable pods.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Creating and updating each pod in the canary deployment.
• How many times: Once per replica, here 10 times for 10 pods.

How Execution Grows With Input

As the number of replicas (pods) increases, the deployment controller performs operations for each pod.

Input Size (n)	Approx. Operations
10	10 pod creations and updates
100	100 pod creations and updates
1000	1000 pod creations and updates

Pattern observation: The work grows directly with the number of pods you deploy.

Final Time Complexity

Time Complexity: O(n)

This means the time to complete the canary deployment grows linearly with the number of pods you create.

Common Mistake

[X] Wrong: "Deploying more pods in a canary release takes the same time no matter how many pods there are."

[OK] Correct: Each pod requires separate creation and readiness checks, so more pods mean more work and longer deployment time.

Interview Connect

Understanding how deployment time scales helps you design better release strategies and shows you can think about system growth clearly.

Self-Check

"What if we used a rolling update strategy that updates pods in batches instead of all at once? How would the time complexity change?"

Practice

1. What is the main purpose of a canary deployment in Kubernetes?

easy

A. To release a new version to a small group of users first to reduce risk

B. To deploy all users to the new version immediately

C. To delete the old version before deploying the new one

D. To run multiple versions permanently without any rollout

Solution

1. Step 1: Understand canary deployment concept

   Canary deployments release new software versions to a small subset of users first to test stability and reduce risk.

2. Step 2: Compare options with this concept

   Only To release a new version to a small group of users first to reduce risk describes this gradual rollout to a small group to reduce risk.

3. Final Answer:

   To release a new version to a small group of users first to reduce risk -> Option A

4. Quick Check:

   Canary deployment = gradual rollout [OK]

Hint: Canary means small test group rollout first [OK]

Common Mistakes:

• Thinking canary deploys to all users at once
• Confusing canary with blue-green deployment
• Assuming canary deletes old versions immediately

2. Which Kubernetes resource is typically used to manage canary deployments?

easy

A. Deployment

B. ConfigMap

C. ServiceAccount

D. PersistentVolume

Solution

1. Step 1: Identify resource for managing app versions

   Deployments manage application versions and rollout strategies in Kubernetes.

2. Step 2: Match resource to canary deployment

   Canary deployments use multiple Deployments with different labels to control traffic.

3. Final Answer:

   Deployment -> Option A

4. Quick Check:

   Canary uses Deployment resource [OK]

Hint: Deployments control app versions and rollout [OK]

Common Mistakes:

• Choosing ConfigMap which stores config, not versions
• Selecting ServiceAccount which manages permissions
• Picking PersistentVolume which handles storage

3. Given this snippet of a Kubernetes Deployment YAML for canary rollout, what percentage of traffic will go to the canary pods?

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-canary
  labels:
    version: canary
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
      version: canary
  template:
    metadata:
      labels:
        app: myapp
        version: canary
    spec:
      containers:
      - name: myapp
        image: myapp:v2

Assuming the stable deployment has 8 replicas with label version: stable and the Service routes traffic evenly by label.

medium

A. 20%

B. 25%

C. 80%

D. 50%

Solution

1. Step 1: Calculate total replicas

   Stable has 8 replicas, canary has 2 replicas, total = 8 + 2 = 10 replicas.

2. Step 2: Calculate canary traffic percentage

   Traffic is split evenly by label, so canary gets 50% traffic regardless of pod count.

3. Final Answer:

   50% -> Option D

4. Quick Check:

   Service splits traffic evenly by label = 50% canary [OK]

Hint: Check how Service splits traffic: by pods or labels [OK]

Common Mistakes:

• Assuming traffic splits by pod count instead of labels
• Ignoring label-based routing in Service
• Miscounting total replicas

4. You applied a canary Deployment but users report they see only the old version. What is the most likely cause?

medium

A. The image tag in the canary Deployment is incorrect

B. The Deployment replicas are set to zero

C. The Service selector does not include the canary label

D. The pod resource limits are too high

Solution

1. Step 1: Understand how Service routes traffic

   Service routes traffic to pods matching its selector labels.

2. Step 2: Identify why canary pods get no traffic

   If Service selector misses canary label, canary pods won't receive traffic, so users see only old version.

3. Final Answer:

   The Service selector does not include the canary label -> Option C

4. Quick Check:

   Service selector missing canary label = no canary traffic [OK]

Hint: Check Service selector matches canary pod labels [OK]

Common Mistakes:

• Assuming zero replicas without checking
• Blaming image tag without logs
• Ignoring Service selector labels

5. You want to roll out a canary deployment with 10% traffic to the new version and 90% to stable. You have 10 stable pods and 2 canary pods. How should you configure the Service to achieve this traffic split?

hard

A. Set Service selector to include both stable and canary labels and use weighted routing with 10% weight on canary

B. Create two Services, one for stable and one for canary, and use an Ingress with traffic splitting

C. Use a single Deployment with 12 replicas and update image tag gradually

D. Set Service selector to only stable label and manually scale canary pods to 1

Solution

1. Step 1: Understand traffic splitting in Kubernetes Service

   Standard Kubernetes Service does not support weighted traffic splitting by itself.

2. Step 2: Identify method to split traffic by percentage

   Using two Services and an Ingress or service mesh allows weighted traffic splitting (e.g., 10% to canary, 90% to stable).

3. Step 3: Evaluate options

   Create two Services, one for stable and one for canary, and use an Ingress with traffic splitting describes creating two Services and using Ingress for traffic splitting, which is the correct approach.

4. Final Answer:

   Create two Services, one for stable and one for canary, and use an Ingress with traffic splitting -> Option B

5. Quick Check:

   Weighted traffic split requires Ingress or service mesh [OK]

Hint: Use Ingress or service mesh for weighted traffic split [OK]

Common Mistakes:

• Expecting Service selector to do weighted routing
• Scaling pods to control traffic percentage
• Using single Deployment for canary traffic split