Bird
Raised Fist0
Microservicessystem_design~25 mins

Why Kubernetes manages microservice deployment in Microservices - Design It to Understand It

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Design: Microservice Deployment Management with Kubernetes
Focus on deployment, scaling, and management of microservices using Kubernetes. Out of scope are microservice internal design and business logic.
Functional Requirements
FR1: Deploy multiple microservices independently
FR2: Ensure high availability and fault tolerance
FR3: Scale microservices automatically based on load
FR4: Manage service discovery and load balancing
FR5: Handle rolling updates without downtime
FR6: Monitor health and restart failed services automatically
Non-Functional Requirements
NFR1: Support at least 100 microservice instances concurrently
NFR2: API response latency p99 under 200ms
NFR3: Availability target of 99.9% uptime
NFR4: Deployment changes should not cause downtime
NFR5: Support heterogeneous microservices (different languages and runtimes)
Think Before You Design
Questions to Ask
❓ Question 1
❓ Question 2
❓ Question 3
❓ Question 4
❓ Question 5
Key Components
Container runtime (e.g., Docker)
Kubernetes control plane (API server, scheduler, controller manager)
Kubernetes worker nodes
Pods and ReplicaSets
Services and Ingress controllers
ConfigMaps and Secrets
Horizontal Pod Autoscaler
Health probes (liveness and readiness)
Design Patterns
Declarative configuration management
Rolling updates and rollbacks
Self-healing and auto-restart
Service discovery and load balancing
Autoscaling based on metrics
Reference Architecture
User --> Kubernetes API Server --> Scheduler --> Worker Nodes (Pods running microservices)
Worker Nodes --> Kubelet (manages containers)
Pods --> Services (for load balancing and discovery)
Horizontal Pod Autoscaler monitors metrics --> scales Pods
Health Probes --> Kubelet restarts unhealthy Pods
Components
Kubernetes API Server
Kubernetes
Central control point for managing cluster state and deployments
Scheduler
Kubernetes
Assigns Pods to worker nodes based on resource availability
Worker Nodes
Linux servers with container runtime
Run microservice containers inside Pods
Pods
Kubernetes
Smallest deployable unit, runs one or more containers
Services
Kubernetes
Provide stable network endpoints and load balancing for Pods
Horizontal Pod Autoscaler
Kubernetes
Automatically scale Pods based on CPU or custom metrics
Health Probes
Kubernetes
Check container health and readiness to restart or route traffic
Request Flow
1. User sends request to microservice via Service endpoint
2. Service load balances request to one of the healthy Pods
3. Pod runs containerized microservice to handle request
4. Kubelet on worker node monitors Pod health using probes
5. If Pod is unhealthy, Kubelet restarts it automatically
6. Horizontal Pod Autoscaler monitors metrics and adjusts Pod count
7. Scheduler places new Pods on nodes with available resources
8. Kubernetes API Server manages desired state and updates
Database Schema
Not applicable as Kubernetes manages deployment and runtime, not data storage.
Scaling Discussion
Bottlenecks
API Server overload with too many requests
Scheduler delays when cluster size grows
Worker node resource exhaustion
Network bottlenecks between services
Autoscaler reacting slowly to traffic spikes
Solutions
Use multiple API Server replicas behind a load balancer
Optimize scheduler with custom policies or multiple schedulers
Add more worker nodes and use resource quotas
Implement network policies and use efficient CNI plugins
Tune autoscaler thresholds and use predictive scaling
Interview Tips
Time: Spend 10 minutes explaining Kubernetes components and their roles, 15 minutes on deployment and scaling flow, 10 minutes on handling failures and updates, 10 minutes on scaling challenges and solutions
Kubernetes provides declarative deployment and self-healing
Pods are the smallest deployable units running containers
Services enable stable networking and load balancing
Autoscaling adjusts capacity automatically based on load
Rolling updates avoid downtime during deployments
Health probes ensure only healthy Pods serve traffic
Scaling requires addressing API server, scheduler, and node limits

Practice

(1/5)
1. Why does Kubernetes manage microservice deployment instead of manually running each service?
easy
A. Because it replaces the need for any servers
B. Because it automates starting, stopping, and scaling services reliably
C. Because it writes the code for microservices automatically
D. Because it only works with one service at a time

Solution

  1. Step 1: Understand manual deployment challenges

    Manually running many microservices is hard to keep track of and scale.
  2. Step 2: Role of Kubernetes in deployment

    Kubernetes automates managing service lifecycles, scaling, and recovery to keep apps running smoothly.
  3. Final Answer:

    Because it automates starting, stopping, and scaling services reliably -> Option B
  4. Quick Check:

    Automation of service management = B [OK]
Hint: Kubernetes automates service control, not replaces servers or code [OK]
Common Mistakes:
  • Thinking Kubernetes replaces servers
  • Believing Kubernetes writes app code
  • Assuming Kubernetes handles only one service
2. Which of the following is the correct Kubernetes command to deploy a microservice from a YAML file named service.yaml?
easy
A. kubectl apply -f service.yaml
B. kubectl run service.yaml
C. kubectl start service.yaml
D. kubectl create service.yaml

Solution

  1. Step 1: Identify the command to apply configuration files

    The kubectl apply -f command applies changes from a YAML file to the cluster.
  2. Step 2: Check other options for correctness

    kubectl run is for running pods directly, kubectl start and kubectl create do not accept YAML files directly.
  3. Final Answer:

    kubectl apply -f service.yaml -> Option A
  4. Quick Check:

    Apply YAML file = kubectl apply -f [OK]
Hint: Use 'kubectl apply -f' to deploy YAML files [OK]
Common Mistakes:
  • Using 'kubectl run' to deploy YAML files
  • Trying 'kubectl start' which is invalid
  • Confusing 'kubectl create' with applying configs
3. Given this Kubernetes YAML snippet for a microservice pod:
apiVersion: v1
kind: Pod
metadata:
  name: myservice
spec:
  containers:
  - name: app
    image: myapp:v1
    ports:
    - containerPort: 80
What will happen if the pod crashes unexpectedly?
medium
A. The pod will restart only if the image is updated
B. The pod will stay crashed until manually restarted
C. Kubernetes will automatically restart the pod to keep the service running
D. Kubernetes will delete the pod and not recreate it

Solution

  1. Step 1: Understand pod restart policy default

    By default, Kubernetes restarts pods automatically if they crash to maintain service availability.
  2. Step 2: Check other options for correctness

    Pods do not stay crashed without restart, nor are they deleted permanently without recreation, and restarts are not tied to image updates.
  3. Final Answer:

    Kubernetes will automatically restart the pod to keep the service running -> Option C
  4. Quick Check:

    Pod auto-restart on crash = D [OK]
Hint: Pods auto-restart by default to keep services alive [OK]
Common Mistakes:
  • Thinking pods stay crashed until manual restart
  • Believing pods delete permanently on crash
  • Assuming restart depends on image updates
4. You deployed a microservice with Kubernetes, but it keeps crashing. The YAML file has this snippet:
spec:
  containers:
  - name: app
    image: myapp:v1
    ports:
    - containerPort: 80
  restartPolicy: Never
What is the problem and how to fix it?
medium
A. The pod name is missing; add metadata name
B. The containerPort is wrong; change it to 8080
C. The image version is invalid; update to 'v2'
D. The restartPolicy 'Never' stops restarts; change it to 'Always' to fix

Solution

  1. Step 1: Identify restartPolicy effect

    Setting restartPolicy: Never means Kubernetes will not restart the pod if it crashes.
  2. Step 2: Fix by changing restartPolicy

    Changing restartPolicy to Always lets Kubernetes restart the pod automatically to keep it running.
  3. Final Answer:

    The restartPolicy 'Never' stops restarts; change it to 'Always' to fix -> Option D
  4. Quick Check:

    restartPolicy 'Always' enables auto-restart [OK]
Hint: Use restartPolicy 'Always' to auto-restart pods [OK]
Common Mistakes:
  • Changing port without checking crash cause
  • Updating image version without error info
  • Ignoring restartPolicy effect
5. You want to deploy a microservice that must always be available, even if some pods fail. Which Kubernetes feature helps achieve this and how?
hard
A. Use a Deployment with replicas to run multiple pod copies for high availability
B. Use a single Pod with restartPolicy set to Never
C. Use a ConfigMap to store pod data for recovery
D. Use a ServiceAccount to control pod permissions

Solution

  1. Step 1: Understand high availability needs

    Running multiple copies of a microservice ensures it stays available if some pods fail.
  2. Step 2: Use Kubernetes Deployment with replicas

    A Deployment manages multiple pod replicas and automatically replaces failed pods to maintain availability.
  3. Final Answer:

    Use a Deployment with replicas to run multiple pod copies for high availability -> Option A
  4. Quick Check:

    Deployment + replicas = high availability [OK]
Hint: Deploy replicas with Deployment for service uptime [OK]
Common Mistakes:
  • Using single pod with no replicas
  • Confusing ConfigMap with availability
  • Mixing permissions with availability