Why Kubernetes manages microservice deployment in Microservices - Scalability Evidence

Scalability Analysis - Why Kubernetes manages microservice deployment

Growth Table: Microservice Deployment with Kubernetes

Users	What Changes
100 users	Few microservices deployed on a single server; manual deployment possible; low traffic and resource needs.
10,000 users	Multiple microservices run on several servers; need for automated deployment and scaling; manual management becomes error-prone.
1,000,000 users	High traffic with many microservices; need for automatic scaling, load balancing, and self-healing; manual deployment impossible.
100,000,000 users	Massive scale with thousands of microservice instances; requires multi-cluster management, advanced scheduling, and fault tolerance; complex networking and resource management.

First Bottleneck: Manual Deployment and Resource Management

At small scale, deploying microservices manually works. As users grow, managing many services and servers manually becomes error-prone and slow. The first bottleneck is the lack of automation in deployment, scaling, and recovery. Without a system like Kubernetes, handling failures, scaling up/down, and balancing load becomes impossible at medium to large scale.

Scaling Solutions with Kubernetes

• Automated Deployment: Kubernetes automates starting, stopping, and updating microservices.
• Horizontal Scaling: It adds or removes service instances based on traffic automatically.
• Load Balancing: Distributes user requests evenly across service instances.
• Self-Healing: Restarts failed services without manual intervention.
• Resource Management: Efficiently allocates CPU, memory, and storage across services.
• Rolling Updates & Rollbacks: Updates services without downtime and can revert if problems occur.
• Multi-Cluster Support: Manages services across multiple data centers or clouds for high availability.

Back-of-Envelope Cost Analysis

• At 10,000 users, expect ~1000-5000 concurrent connections; a few servers can handle this with Kubernetes managing deployment.
• At 1,000,000 users, thousands of requests per second require multiple servers and automated scaling to avoid overload.
• Storage needs grow with service logs, container images, and state data; Kubernetes supports persistent volumes and storage classes.
• Network bandwidth must support inter-service communication and user traffic; Kubernetes manages service discovery and networking efficiently.

Interview Tip: Structuring Scalability Discussion

Start by explaining the challenges of manual microservice deployment as users grow. Identify the bottleneck as deployment and resource management. Then describe how Kubernetes automates these tasks, enabling scaling, load balancing, and self-healing. Finally, mention how Kubernetes supports multi-cluster setups for very large scale. Use simple examples and focus on benefits like automation and reliability.

Self-Check Question

Your microservice deployment system handles 1000 requests per second. Traffic grows 10x. What do you do first and why?

Answer: Implement automated horizontal scaling with Kubernetes to add more service instances dynamically. This prevents overload and maintains performance without manual intervention.

Key Result

Kubernetes manages microservice deployment by automating scaling, load balancing, and recovery, solving the bottleneck of manual resource management as user traffic grows from thousands to millions.

Practice

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