☸️ Docker & Kubernetes
Kubernetes Architecture
Kubernetes cluster internals — Control Plane, Worker Nodes, Pods, Services, and Ingress
Kubernetes is a distributed operating system for containers. It continuously reconciles actual cluster state toward desired state. You declare 'I want 3 replicas of this service' and K8s makes it happen — and keeps it that way even when nodes fail.
Key Concepts
Control Plane
API Server receives all cluster commands. etcd stores cluster state (all objects — pods, services, deployments). Scheduler decides which Node gets each Pod. Controller Manager watches state and drives reconciliation.
Worker Nodes
kubelet runs on each node, receives Pod specs from API Server and ensures containers run. kube-proxy handles network routing between pods. Container runtime (containerd) executes the actual containers.
Service Discovery
Pods get ephemeral IPs — they change on restart. K8s Services provide stable virtual IPs (ClusterIP) and DNS names. Other pods call http://order-service (DNS) and K8s routes to a healthy pod.
Ingress
Ingress controller (Nginx, Traefik) handles external HTTP routing: path-based routing, TLS termination, host-based routing. One external load balancer serving all internal services.
System Architecture Blueprint
The Reconciliation Loop
Unlike traditional deployments where you run a script to start servers, Kubernetes is declarative. You submit a YAML file describing the 'Desired State' (e.g. 3 Pods running v2 of the App).
- **1. Declare:** You apply the YAML to the API Server. The API Server saves this Desired State in **etcd**.
- **2. Observe:** The Controller Manager constantly observes the Actual State of the cluster.
- **3. Reconcile:** If Actual State does not match Desired State (e.g. a Node crashes and its Pod dies, reducing the count to 2), the Controller Manager notices the discrepancy.
- **4. Act:** The Scheduler finds a new healthy Node, and commands its **kubelet** to start a new Pod, restoring the count to 3. This loop runs continuously, ensuring high availability without human intervention.
Kubernetes Deployment YAML
order-service-deployment.yamlyaml
1apiVersion: apps/v1
2kind: Deployment
3metadata:
4 name: order-service
5 namespace: production
6spec:
7 replicas: 3 # Desired state — K8s maintains this count
8 selector:
9 matchLabels:
10 app: order-service
11 template:
12 metadata:
13 labels:
14 app: order-service
15 spec:
16 containers:
17 - name: order-service
18 image: myregistry/order-service:v2.4.1 # Immutable tag, not 'latest'
19 ports:
20 - containerPort: 3000
21 resources:
22 requests:
23 memory: "256Mi" # K8s scheduler uses this to find a node
24 cpu: "200m"
25 limits:
26 memory: "512Mi" # OOM kill if exceeded
27 cpu: "500m"
28 livenessProbe:
29 httpGet:
30 path: /health
31 port: 3000
32 initialDelaySeconds: 30
33 periodSeconds: 10
34 readinessProbe:
35 httpGet:
36 path: /ready
37 port: 3000
38---
39apiVersion: v1
40kind: Service
41metadata:
42 name: order-service
43spec:
44 selector:
45 app: order-service
46 ports:
47 - port: 80
48 targetPort: 3000
49 type: ClusterIP💡
Senior Architect Insight: Always define both readinessProbe and livenessProbe. readinessProbe prevents traffic from reaching a Pod that hasn't finished startup. livenessProbe restarts a Pod that has deadlocked but is still running. Without both, K8s will send traffic to broken pods and not restart them.