Microservices Orchestration with Kubernetes
Docker packages your microservices into containers. Kubernetes decides where those containers run, keeps them running, and scales them up or down based on load. Kubernetes is the operating system for your microservices infrastructure.
The Problem Kubernetes Solves
Imagine you have 50 microservices, each running 3 containers, spread across 20 servers. On a busy Friday afternoon, the Order Service needs 10 containers instead of 3. One server crashes and takes 8 containers with it.
Without Kubernetes, a human or script must manually reassign containers and restart them. With Kubernetes, this all happens automatically within seconds.
Core Kubernetes Concepts
Cluster
A cluster is a group of servers (called nodes) that Kubernetes manages as one unit. You interact with the cluster as a whole — you never manually SSH into individual servers to manage containers.
KUBERNETES CLUSTER =================== +-----------------------------------------------------------+ | CONTROL PLANE (cluster brain) | | - Scheduler: decides where pods run | | - API Server: your command entry point | | - etcd: stores all cluster state | +-----------------------------------------------------------+ | Node 1 | Node 2 | Node 3 | Node 4 | | [Pod][Pod] | [Pod][Pod] | [Pod] | [Pod][Pod] | +--------------+--------------+--------------+--------------+
Pod
A Pod is the smallest unit Kubernetes manages. Usually one container runs inside one Pod. Kubernetes schedules, scales, and monitors Pods.
Deployment
A Deployment tells Kubernetes: "Run 3 copies of the Order Service container at all times." If a Pod crashes, the Deployment controller starts a new one. If you update the image, the Deployment rolls out the new version without downtime.
Deployment for Order Service: replicas: 3 # Always keep 3 Pods running image: order-service:1.2 Kubernetes ensures 3 Pods run at all times. If 1 crashes: Kubernetes detects it (health check fails) Starts a new Pod immediately 3 Pods running again within seconds
Service (Kubernetes Service)
A Kubernetes Service provides a stable network address for a group of Pods. Pods come and go, but the Service address stays the same. Other services call the Service address — Kubernetes routes to a healthy Pod automatically.
KUBERNETES SERVICE AS STABLE FRONT DOOR ========================================= [Order Service Pod 1] [Order Service Pod 2] <-- Service: "order-service:8080" (stable) [Order Service Pod 3] Pod 2 crashes. Order Service removed from rotation. Pod 4 starts. Order Service adds Pod 4 to rotation. The stable address "order-service:8080" never changes. Callers never notice Pod changes.
Horizontal Pod Autoscaling
Kubernetes monitors CPU and memory usage. When load increases, it automatically starts more Pods. When load drops, it removes extra Pods to save resources.
AUTOSCALING EXAMPLE ==================== Normal traffic: Order Service runs 3 Pods, CPU at 30% Black Friday sale begins: Orders spike --> CPU rises to 80% Kubernetes detects: CPU above 70% threshold Starts 3 more Pods: now 6 Pods running CPU drops to 45% Sale ends: Orders drop --> CPU falls to 15% Kubernetes detects: CPU below 20% threshold Removes 3 Pods: back to 3 Pods running Cost returns to normal
Rolling Updates and Rollbacks
Kubernetes deploys new versions without downtime using a rolling update strategy. It replaces Pods one at a time, ensuring some Pods always handle traffic.
ROLLING UPDATE: Updating Order Service from v1.1 to v1.2
==========================================================
Step 1: Kill Pod 1 (v1.1) --> Start Pod 1 (v1.2)
2 Pods on v1.1, 1 Pod on v1.2. Traffic continues.
Step 2: Kill Pod 2 (v1.1) --> Start Pod 2 (v1.2)
1 Pod on v1.1, 2 Pods on v1.2. Traffic continues.
Step 3: Kill Pod 3 (v1.1) --> Start Pod 3 (v1.2)
All 3 Pods on v1.2. Update complete. No downtime.
If v1.2 is broken:
kubectl rollout undo deployment/order-service
Kubernetes rolls back to v1.1 instantly.
ConfigMaps and Secrets
Services need configuration values and credentials. Kubernetes provides two mechanisms:
- ConfigMap — non-sensitive settings like database hostnames, feature flags, timeout values.
- Secret — sensitive data like passwords, API keys, TLS certificates (stored encrypted).
Pods read these values at runtime. Changing a ConfigMap does not require rebuilding the container image.
Namespaces
Namespaces divide a cluster into virtual sub-clusters. A common setup uses separate namespaces for different environments or teams.
NAMESPACE LAYOUT ================= Namespace: production - All production services Namespace: staging - All staging services Namespace: team-payments - Payment team's services isolated from other teams Network policies can restrict: team-payments namespace cannot access production namespace unless explicitly allowed.
Kubernetes in Practice
Major cloud providers offer managed Kubernetes services where they handle the control plane for you:
- Amazon EKS — Elastic Kubernetes Service on AWS.
- Google GKE — Google Kubernetes Engine, the most mature managed Kubernetes.
- Azure AKS — Azure Kubernetes Service.
With managed Kubernetes, your team focuses on deploying and running microservices. The cloud provider maintains the cluster infrastructure.
Kubernetes and Microservices Fit
WHAT MICROSERVICES NEED HOW KUBERNETES PROVIDES IT ============================ ============================== Run many services Manages thousands of Pods Service discovery Built-in DNS and Service objects Auto-scaling Horizontal Pod Autoscaler Self-healing Restarts failed Pods automatically Zero-downtime deploys Rolling updates Secret management Secrets objects Resource isolation Resource limits per Pod
Kubernetes and microservices are designed for each other. Most production microservices systems today run on Kubernetes.