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%.