Pods and deployments for services in Microservices - System Design Exercise

Design: Microservices Deployment with Pods and Deployments

Design the deployment architecture for microservices using pods and deployments. Focus on how pods and deployments manage service lifecycle, scaling, and updates. Out of scope: detailed service internal logic, network policies, and persistent storage design.

Functional Requirements

FR1: Deploy multiple microservices independently

FR2: Ensure high availability and fault tolerance for each service

FR3: Support rolling updates without downtime

FR4: Automatically recover from pod failures

FR5: Scale services based on load

FR6: Isolate services for security and resource management

Non-Functional Requirements

NFR1: Handle up to 1000 concurrent requests per service

NFR2: API response latency p99 under 200ms

NFR3: Availability target 99.9% uptime

NFR4: Use container orchestration platform (e.g., Kubernetes)

NFR5: Support zero downtime deployments

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Pods as the smallest deployable units running containers

Deployments to manage pod replicas and updates

ReplicaSets to maintain desired pod count

Service abstraction for stable network endpoints

Horizontal Pod Autoscaler for scaling

Health checks (liveness and readiness probes)

Design Patterns

Rolling update deployment pattern

Blue-green or canary deployment strategies

Self-healing with pod restarts

Resource requests and limits for pods

Label selectors for grouping pods

Reference Architecture

Client
  |
  v
Service (Load Balancer)
  |
  v
+-----------------------------+
| Deployment Controller        |
|  +-----------------------+  |
|  | ReplicaSet            |  |
|  |  +-----------------+  |  |
|  |  | Pod (Container)  |  |  |
|  |  +-----------------+  |  |
|  +-----------------------+  |
+-----------------------------+
  |
  v
Kubernetes Cluster with multiple Deployments managing Pods for each microservice

Components

Pod

Kubernetes

Runs one or more containers for a microservice instance

Deployment

Kubernetes

Manages ReplicaSets and controls pod lifecycle, scaling, and rolling updates

ReplicaSet

Kubernetes

Ensures the desired number of pod replicas are running

Service

Kubernetes

Provides stable network endpoint and load balancing for pods

Horizontal Pod Autoscaler

Kubernetes

Automatically scales pods based on CPU or custom metrics

Liveness and Readiness Probes

Kubernetes

Monitor pod health and control traffic routing

Request Flow

1. Client sends request to Service endpoint (load balancer).

2. Service routes request to one of the healthy pods managed by Deployment.

3. Pod runs container(s) serving the microservice logic.

4. Deployment monitors pod health and replaces failed pods automatically.

5. During updates, Deployment performs rolling updates by creating new pods and terminating old ones gradually.

6. Horizontal Pod Autoscaler adjusts the number of pod replicas based on load metrics.

7. Liveness probes detect unhealthy pods and trigger restarts.

8. Readiness probes ensure only ready pods receive traffic.

Database Schema

Not applicable as this design focuses on deployment architecture rather than data storage.

Scaling Discussion

Bottlenecks

Single pod resource limits causing CPU or memory bottlenecks

Deployment controller overwhelmed by rapid scaling or updates

Network load balancing limits at Service level

Slow pod startup time delaying scaling response

Insufficient cluster node resources to schedule new pods

Solutions

Define resource requests and limits per pod to optimize scheduling and prevent resource contention

Use multiple deployments and namespaces to distribute load on control plane

Implement external load balancers or ingress controllers for high traffic

Optimize container images and startup scripts to reduce pod startup latency

Scale cluster nodes horizontally and use cluster autoscaler to add nodes automatically

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying constraints, 20 minutes designing the deployment architecture with pods and deployments, 10 minutes discussing scaling and failure handling, and 5 minutes summarizing.

Explain the role of pods as smallest deployable units running containers

Describe how deployments manage pod replicas and enable rolling updates

Discuss health checks and self-healing mechanisms

Highlight autoscaling and resource management for handling load

Mention strategies for zero downtime deployments and fault tolerance

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