Progressive delivery concept in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create a Kubernetes Deployment with 3 replicas.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: [1]
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app-image:latest

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

A3

B1

C5

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Setting replicas to 0 stops the app from running.

Using 1 replica does not allow gradual rollout.

The replicas field sets how many copies of the app run. Here, 3 replicas means 3 pods will run.

2fill in blank

medium

Complete the code to define a Kubernetes Service that targets pods with label 'app: my-app'.

Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: [1]
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

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

Amy-app

Bfrontend

Cbackend

Ddatabase

Attempts:

3 left

💡 Hint

Common Mistakes

Using a selector label that does not match any pod causes no traffic routing.

Typos in label names break the selector.

The Service selector must match the pod label to route traffic correctly. Here, pods labeled app: my-app are targeted.

3fill in blank

hard

Fix the error in the rollout strategy to enable rolling updates with max 25% unavailable pods.

Kubernetes

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: [1]

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

A0

B25%

C50%

D100%

Attempts:

3 left

💡 Hint

Common Mistakes

Setting maxUnavailable to 0 blocks updates if pods can't be replaced immediately.

Setting maxUnavailable too high risks downtime.

Setting maxUnavailable to 25% allows at most 25% of pods to be down during updates, enabling smooth progressive delivery.

4fill in blank

hard

Fill both blanks to define a canary deployment with 10% traffic and 90% stable traffic.

Kubernetes

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
  - my-app.example.com
  http:
  - route:
    - destination:
        host: my-app
      weight: [1]
    - destination:
        host: my-app-canary
      weight: [2]

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

A90

B10

C50

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Weights not adding to 100 causes routing errors.

Assigning 0 weight to canary means no testing.

The weights control traffic split. 90% goes to stable, 10% to canary for gradual rollout.

5fill in blank

hard

Fill all three blanks to create a Kubernetes HorizontalPodAutoscaler targeting CPU usage at 50%.

Kubernetes

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: [1]
  minReplicas: [2]
  maxReplicas: [3]
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

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

Amy-app

B1

C5

D3

Attempts:

3 left

💡 Hint

Common Mistakes

Setting minReplicas higher than maxReplicas causes errors.

Wrong Deployment name prevents scaling.

The HPA targets the Deployment named my-app, scales between 1 and 5 replicas based on CPU usage at 50%.

Practice

1. What is the main goal of progressive delivery in Kubernetes?

easy

A. To avoid monitoring after deployment

B. To deploy all changes at once to all users

C. To release software changes gradually and safely

D. To delete old versions immediately after deployment

Solution

1. Step 1: Understand the concept of progressive delivery

   Progressive delivery means releasing software updates slowly to reduce risk and catch problems early.

2. Step 2: Compare options to the concept

   Only To release software changes gradually and safely describes gradual and safe release, matching the concept.

3. Final Answer:

   To release software changes gradually and safely -> Option C

4. Quick Check:

   Progressive delivery = gradual safe release [OK]

Hint: Think slow and safe rollout, not instant or risky [OK]

Common Mistakes:

• Confusing progressive delivery with instant deployment
• Ignoring the safety aspect of gradual rollout
• Assuming old versions are deleted immediately

2. Which Kubernetes feature is commonly used to run multiple versions of an application side by side for progressive delivery?

easy

A. Namespaces

B. Labels

C. Persistent Volumes

D. ConfigMaps

Solution

1. Step 1: Identify how Kubernetes distinguishes versions

   Kubernetes uses labels to tag and select different versions of deployments.

2. Step 2: Match features to use case

   Labels allow running multiple versions side by side by selecting pods with specific labels.

3. Final Answer:

   Labels -> Option B

4. Quick Check:

   Labels = version tags for deployments [OK]

Hint: Labels tag versions; namespaces separate environments [OK]

Common Mistakes:

• Confusing namespaces with version tagging
• Using ConfigMaps or volumes for version control
• Not knowing labels select pods

3. Given this Kubernetes deployment snippet for progressive delivery:

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

What does this configuration do?

medium

A. Deploys two pods running version 2.0 of myapp labeled as v2

B. Deletes all pods labeled v2 and replaces with version 1.0

C. Creates a service exposing version 1.0 of myapp

D. Scales the existing deployment to zero replicas

Solution

1. Step 1: Analyze deployment metadata and labels

   The deployment is named myapp-v2 and uses label version: v2 for pods.

2. Step 2: Check replicas and container image

   It creates 2 replicas running image myapp:2.0, matching label v2.

3. Final Answer:

   Deploys two pods running version 2.0 of myapp labeled as v2 -> Option A

4. Quick Check:

   Deployment with replicas=2 and image v2 = Deploys two pods running version 2.0 of myapp labeled as v2 [OK]

Hint: Look for replicas and image tags to identify deployment version [OK]

Common Mistakes:

• Confusing deployment labels with service exposure
• Assuming deletion instead of creation
• Mixing version labels with scaling actions

4. You deployed a new version of your app with label version: v2 but traffic is still going only to v1. What is a likely cause?

medium

A. Service selector is still set to version: v1

B. Deployment replicas for v2 are set to zero

C. Pods labeled v2 are not running

D. All of the above

Solution

1. Step 1: Check service selector labels

   If the service selector targets version v1, traffic won't reach v2 pods.

2. Step 2: Verify deployment replicas and pod status

   If replicas for v2 are zero or pods are not running, no v2 pods receive traffic.

3. Final Answer:

   All of the above -> Option D

4. Quick Check:

   Service selector + replicas + pod status all affect traffic [OK]

Hint: Check service selector, replicas, and pod health for traffic issues [OK]

Common Mistakes:

• Only checking one cause and ignoring others
• Assuming pods labeled v2 always run
• Not verifying service selectors

5. You want to implement progressive delivery by routing 10% of traffic to a new version v2 and 90% to v1. Which Kubernetes tool or method best supports this?

hard

A. Using multiple Deployments with labels and a Service with weighted traffic routing via Istio or another service mesh

B. Scaling down the v1 deployment to 10% replicas and scaling up v2 to 90% replicas

C. Deleting the v1 deployment and replacing it with v2 immediately

D. Using ConfigMaps to switch traffic percentages

Solution

1. Step 1: Understand traffic splitting in Kubernetes

   Kubernetes alone does not support weighted traffic routing; service meshes like Istio enable this.

2. Step 2: Evaluate options for traffic control

   Using multiple deployments with labels and Istio allows routing 10% to v2 and 90% to v1 safely.

3. Final Answer:

   Using multiple Deployments with labels and a Service with weighted traffic routing via Istio or another service mesh -> Option A

4. Quick Check:

   Weighted routing needs service mesh, not just scaling [OK]

Hint: Use service mesh for traffic weights, not just replica counts [OK]

Common Mistakes:

• Trying to control traffic by scaling replicas only
• Deleting old version immediately
• Using ConfigMaps for traffic routing