Pods and deployments for services in Microservices - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the number of replicas in a Kubernetes deployment.

Microservices

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service
spec:
  replicas: [1]
  selector:
    matchLabels:
      app: my-service

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

A0

B5

C3

D1

Attempts:

3 left

💡 Hint

Common Mistakes

Setting replicas to 0 stops all pods.

Using a string instead of a number.

The replicas field defines how many pod copies run. Setting it to 1 means one pod will run.

2fill in blank

medium

Complete the code to define the container image in the pod template.

Microservices

spec:
  template:
    metadata:
      labels:
        app: my-service
    spec:
      containers:
      - name: my-service-container
        image: [1]

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

Amy-service:1.0

Bnginx:latest

Cubuntu:20.04

Dredis:alpine

Attempts:

3 left

💡 Hint

Common Mistakes

Using a generic image like nginx instead of the service image.

Forgetting to specify the image tag.

The image field specifies the container image to run. Here, my-service:1.0 is the correct service image.

3fill in blank

hard

Fix the error in the deployment selector to correctly match the pod labels.

Microservices

spec:
  selector:
    matchLabels:
      app: [1]
  template:
    metadata:
      labels:
        app: my-service

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

Aapp-service

Bservice-app

Cmy-service

Dmyapp

Attempts:

3 left

💡 Hint

Common Mistakes

Using different label names in selector and pod template.

Typos in label values.

The selector must exactly match the pod template labels. Here, both use app: my-service.

4fill in blank

hard

Fill both blanks to define a service that exposes the deployment on port 80 and targets container port 8080.

Microservices

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

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

A80

B8080

C443

D3000

Attempts:

3 left

💡 Hint

Common Mistakes

Swapping port and targetPort values.

Using a port not exposed by the container.

The service port is the external port (80), and targetPort is the container port (8080) the service forwards to.

5fill in blank

hard

Fill all three blanks to create a deployment with 3 replicas, using the image 'my-service:2.0', and label the pods with 'app: my-service'.

Microservices

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

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

A3

Bmy-service

D1

Attempts:

3 left

💡 Hint

Common Mistakes

Mismatching selector and pod labels.

Setting replicas to 1 instead of 3.

The deployment needs 3 replicas, and the selector and pod labels must both be 'app: my-service' to match pods correctly.

Practice

1. What is the main role of a Pod in a microservices architecture?

easy

A. To manage updates and scaling of containers

B. To run one or more containers together as a single unit

C. To route network traffic between services

D. To store persistent data for containers

Solution

1. Step 1: Understand what a Pod is

   A Pod is the smallest deployable unit in Kubernetes that runs one or more containers together.

2. Step 2: Differentiate Pod from other components

   Deployments manage Pods, Services route traffic, and persistent storage is handled separately.

3. Final Answer:

   To run one or more containers together as a single unit -> Option B

4. Quick Check:

   Pod = container unit [OK]

Hint: Pods run containers; deployments manage pods [OK]

Common Mistakes:

• Confusing Pods with Deployments
• Thinking Pods handle networking
• Assuming Pods store data

2. Which of the following is the correct YAML snippet to define a Deployment that runs 3 replicas of a Pod?

easy

A. kind: Pod\nreplicas: 3\nmetadata:\n name: my-pod

B. replicas: 3\nkind: Service\nmetadata:\n name: my-service

C. replicas: 3\nkind: Deployment\nmetadata:\n name: my-deployment

D. kind: Deployment\nmetadata:\n name: my-deployment\nreplicas: three

Solution

1. Step 1: Identify correct kind and replicas field

   Deployment kind is correct and replicas should be a number, here 3.

2. Step 2: Check metadata and syntax

   Metadata name is valid; 'replicas: three' is invalid because replicas must be numeric.

3. Final Answer:

   replicas: 3\nkind: Deployment\nmetadata:\n name: my-deployment -> Option C

4. Quick Check:

   Deployment with numeric replicas = correct YAML [OK]

Hint: Deployments use 'kind: Deployment' and numeric replicas [OK]

Common Mistakes:

• Using 'kind: Pod' instead of Deployment
• Setting replicas as a word instead of number
• Confusing Service with Deployment

3. Given this Deployment YAML snippet, how many Pods will be running after applying it?

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 4
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web-container
        image: nginx

medium

A. 4 Pods

B. 0 Pods until manually started

C. 1 Pod

D. Depends on the number of nodes

Solution

1. Step 1: Read replicas count in Deployment spec

   The replicas field is set to 4, meaning Kubernetes will maintain 4 Pods.

2. Step 2: Understand Deployment behavior

   Deployment automatically creates and manages the specified number of Pods.

3. Final Answer:

   4 Pods -> Option A

4. Quick Check:

   replicas = 4 Pods running [OK]

Hint: replicas number = Pods count after deployment [OK]

Common Mistakes:

• Assuming only 1 Pod runs by default
• Thinking Pods need manual start
• Confusing nodes with Pod count

4. You applied a Deployment YAML but notice no Pods are running. Which is the most likely cause?
apiVersion: apps/v1 kind: Deployment metadata: name: api-server spec: replicas: 3 selector: matchLabels: app: api template: metadata: labels: app: backend spec: containers: - name: api-container image: myapi:latest

medium

A. The Deployment kind is incorrect

B. The replicas count is too high for the cluster

C. The container image name is invalid

D. The selector labels do not match the Pod template labels

Solution

1. Step 1: Compare selector and template labels

   The selector uses label 'app: api' but the Pod template labels 'app: backend' which do not match.

2. Step 2: Understand label matching importance

   Deployment uses selector to manage Pods; mismatch means no Pods are controlled or created.

3. Final Answer:

   The selector labels do not match the Pod template labels -> Option D

4. Quick Check:

   Selector labels must match Pod labels [OK]

Hint: Selector and Pod labels must match exactly [OK]

Common Mistakes:

• Ignoring label mismatch
• Assuming image name causes no Pods
• Thinking replicas count blocks Pod creation

5. You want to update a microservice with zero downtime using Kubernetes. Which approach best uses Pods and Deployments to achieve this?

hard

A. Update the Deployment with a new image version; Kubernetes creates new Pods and gradually replaces old ones

B. Delete all old Pods manually and then create new Pods with the updated image

C. Scale down the Deployment to zero replicas, then scale up with the new image

D. Create a new Deployment with the updated image and delete the old Deployment immediately

Solution

1. Step 1: Understand Deployment update strategy

   Deployments support rolling updates that create new Pods and remove old Pods gradually.

2. Step 2: Compare options for zero downtime

   Manual deletion or scaling down causes downtime; creating new Deployment causes conflicts.

3. Final Answer:

   Update the Deployment with a new image version; Kubernetes creates new Pods and gradually replaces old ones -> Option A

4. Quick Check:

   Rolling update = zero downtime update [OK]

Hint: Use Deployment rolling updates for zero downtime [OK]

Common Mistakes:

• Deleting Pods manually causing downtime
• Scaling to zero causes service interruption
• Creating new Deployment causes conflicts