Kubernetes basics review in Microservices - System Design Exercise

Design: Kubernetes Cluster for Microservices

Design the Kubernetes cluster architecture and core components for microservices deployment. Out of scope: detailed microservice code, CI/CD pipelines, and advanced security policies.

Functional Requirements

FR1: Deploy multiple microservices with independent scaling

FR2: Ensure high availability of services

FR3: Enable rolling updates without downtime

FR4: Provide service discovery and load balancing

FR5: Allow configuration and secret management

FR6: Monitor health and restart failed containers automatically

Non-Functional Requirements

NFR1: Support up to 1000 concurrent users

NFR2: API response latency p99 under 200ms

NFR3: Cluster uptime 99.9% (max 8.77 hours downtime per year)

NFR4: Use open-source Kubernetes components

NFR5: Support deployment on cloud or on-premise

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Kubernetes Master components (API Server, Controller Manager, Scheduler)

Worker nodes with kubelet and container runtime

Pods and ReplicaSets for service instances

Deployments for managing rolling updates

Services for load balancing and discovery

ConfigMaps and Secrets for configuration

Ingress controllers for external access

Persistent Volumes if storage is needed

Monitoring tools like Prometheus and Grafana

Design Patterns

Blue-green and rolling deployment patterns

Sidecar containers for logging or proxy

Health checks with readiness and liveness probes

Horizontal Pod Autoscaling

Namespace isolation for multi-tenancy

Reference Architecture

                 +---------------------+
                 |   Kubernetes Master  |
                 | +-----------------+ |
                 | | API Server      | |
                 | | Scheduler       | |
                 | | Controller Mgr  | |
                 | +-----------------+ |
                 +----------+----------+
                            |
          +-----------------+-----------------+
          |                                   |
   +------+-------+                   +-------+------+
   | Worker Node 1 |                   | Worker Node 2|
   | +----------+ |                   | +----------+ |
   | | kubelet  | |                   | | kubelet  | |
   | | Pod(s)   | |                   | | Pod(s)   | |
   | +----------+ |                   | +----------+ |
   +--------------+                   +--------------+

Additional components:
- Services for load balancing
- Ingress controller for external traffic
- ConfigMaps and Secrets for config
- Monitoring stack (Prometheus, Grafana)

Components

API Server

Kubernetes

Central control plane to expose Kubernetes API and handle requests

Scheduler

Kubernetes

Assigns pods to worker nodes based on resource availability

Controller Manager

Kubernetes

Maintains cluster state by managing controllers like ReplicaSets

kubelet

Kubernetes

Agent on worker nodes to manage pod lifecycle and report status

Pods

Kubernetes

Smallest deployable units that run containers

Deployments

Kubernetes

Manage desired state and rolling updates of pods

Services

Kubernetes

Provide stable network endpoints and load balancing

Ingress Controller

Kubernetes

Manage external HTTP/S access to services

ConfigMaps and Secrets

Kubernetes

Store configuration data and sensitive information securely

Monitoring Stack

Prometheus, Grafana

Collect metrics and visualize cluster health

Request Flow

1. User sends request to external URL

2. Ingress controller receives request and routes to appropriate Service

3. Service load balances request to one of the Pods

4. Pod processes request and returns response

5. kubelet monitors Pod health and restarts if needed

6. API Server manages cluster state and schedules new Pods as required

7. Monitoring tools collect metrics from nodes and Pods

Database Schema

Not applicable - Kubernetes manages container orchestration and does not require a traditional database schema.

Scaling Discussion

Bottlenecks

API Server overload with too many requests

Scheduler delays when cluster size grows

Network congestion between nodes

Resource exhaustion on worker nodes

Storage I/O bottlenecks if persistent volumes used

Solutions

Use API Server horizontal scaling with load balancer

Optimize scheduler performance or use multiple schedulers

Implement network policies and use CNI plugins optimized for scale

Add more worker nodes and use autoscaling

Use distributed storage solutions and caching

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying scope, 20 minutes designing architecture and components, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain Kubernetes core components and their roles clearly

Describe how Pods, Deployments, and Services work together

Highlight how rolling updates and self-healing are achieved

Discuss how configuration and secrets are managed securely

Address scaling challenges and practical solutions

Mention monitoring and observability importance

Practice

1. What is a pod in Kubernetes?

easy

A. A command-line tool to manage Kubernetes

B. The smallest unit that runs one or more containers together

C. A configuration file format used in Kubernetes

D. A network policy to control traffic

Solution

1. Step 1: Understand Kubernetes resource types

   Kubernetes groups containers into pods to run them together on the same host.

2. Step 2: Identify the role of a pod

   A pod is the smallest deployable unit that can contain one or more containers sharing resources.

3. Final Answer:

   The smallest unit that runs one or more containers together -> Option B

4. Quick Check:

   Pod = smallest container group [OK]

Hint: Pods group containers; smallest deployable unit [OK]

Common Mistakes:

• Confusing pods with kubectl tool
• Thinking pods are config files
• Mixing pods with network policies

2. Which command correctly lists all pods in the default namespace?

easy

A. kubectl get pods

B. kubectl list pods

C. kubectl show pods

D. kubectl describe pods all

Solution

1. Step 1: Recall kubectl commands for listing resources

   The standard command to list pods is kubectl get pods.

2. Step 2: Check other options for correctness

   kubectl list pods and kubectl show pods are invalid commands; kubectl describe pods all is incorrect syntax.

3. Final Answer:

   kubectl get pods -> Option A

4. Quick Check:

   List pods = kubectl get pods [OK]

Hint: Use 'kubectl get pods' to list pods [OK]

Common Mistakes:

• Using 'list' or 'show' instead of 'get'
• Adding unnecessary arguments like 'all'
• Confusing describe with get

3. Given this YAML snippet for a pod:

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp-container
    image: nginx:latest
    ports:
    - containerPort: 80

What will kubectl get pods myapp-pod show after creation?

medium

A. NAME READY STATUS RESTARTS AGE
myapp-pod 1/1 Completed 0 0s

B. Error: pod not found

C. NAME READY STATUS RESTARTS AGE
myapp-pod 0/1 Pending 0 0s

D. NAME READY STATUS RESTARTS AGE
myapp-pod 1/1 Running 0 0s

Solution

1. Step 1: Understand pod creation from YAML

   The YAML defines a pod with one container running nginx, exposing port 80.

2. Step 2: Predict pod status after creation

   Immediately after creation, the pod should be running with 1 container ready, so status is Running and READY is 1/1.

3. Final Answer:

   NAME READY STATUS RESTARTS AGE myapp-pod 1/1 Running 0 0s -> Option D

4. Quick Check:

   Pod created and running = READY 1/1 Running [OK]

Hint: New pod with valid image shows READY 1/1 Running [OK]

Common Mistakes:

• Expecting Pending status without reason
• Confusing Completed with Running
• Assuming pod not found immediately after creation

4. You run kubectl apply -f pod.yaml but get an error: "error: unable to recognize \"pod.yaml\": no matches for kind \"Pod\" in version \"v2\"". What is the likely fix?

medium

A. Delete the pod.yaml and recreate it

B. Rename the file to pod.yml

C. Change apiVersion from v2 to v1 in pod.yaml

D. Run the command with sudo

Solution

1. Step 1: Analyze the error message

   The error says no matches for kind "Pod" in version "v2", meaning the apiVersion is invalid.

2. Step 2: Correct the apiVersion in YAML

   The correct apiVersion for Pod is "v1", so changing from "v2" to "v1" fixes the issue.

3. Final Answer:

   Change apiVersion from v2 to v1 in pod.yaml -> Option C

4. Quick Check:

   apiVersion must be valid (v1 for Pod) [OK]

Hint: Check apiVersion spelling and value in YAML [OK]

Common Mistakes:

• Changing file extension instead of apiVersion
• Running with sudo unnecessarily
• Deleting file without fixing content

5. You want to update a running pod's container image from nginx:1.19 to nginx:1.21 without downtime. Which Kubernetes resource and method should you use?

hard

A. Create a Deployment and update its image with kubectl set image

B. Directly edit the pod with kubectl edit pod to change the image

C. Delete the pod and create a new one with the new image

D. Use kubectl scale pod to increase replicas

Solution

1. Step 1: Understand pod immutability and updates

   Pods are immutable; you cannot update container images directly on running pods without recreating them.

2. Step 2: Use Deployment for zero downtime updates

   Deployments manage pods and allow rolling updates to change images without downtime using kubectl set image.

3. Final Answer:

   Create a Deployment and update its image with kubectl set image -> Option A

4. Quick Check:

   Use Deployment + set image for smooth updates [OK]

Hint: Use Deployment and set image for zero downtime update [OK]

Common Mistakes:

• Trying to edit pod image directly
• Deleting pod causes downtime
• Scaling pod is invalid command