Why Microservices Need an Orchestrator
Once a system has dozens of containerized microservices, manually deciding which host runs which container, restarting crashed instances, and rolling out new versions without downtime becomes unmanageable by hand. Kubernetes is a container orchestrator that automates exactly this: given a declarative description of the desired state ("run 4 replicas of payments-service v2.3"), its control plane continuously reconciles the actual cluster state to match, scheduling pods onto available nodes, restarting failed ones, and rolling out changes gradually.
Cricket analogy: This is like a franchise's head coach continuously adjusting the playing XI to match a target strategy, substituting injured players and rotating bowlers automatically rather than a captain manually re-deciding the whole lineup every single over.
Deployments, Pods, and ReplicaSets
A Pod is the smallest deployable unit in Kubernetes, typically wrapping one container (or a container plus a sidecar). A Deployment describes the desired state for a set of identical pods — image version, replica count, resource limits — and manages an underlying ReplicaSet that ensures the specified number of pod replicas are always running; if a node crashes and takes two pods with it, the ReplicaSet controller notices the discrepancy and schedules replacement pods elsewhere within seconds. Deployments also drive rolling updates: when you change the image tag, Kubernetes gradually replaces old pods with new ones according to a configurable strategy, keeping the service available throughout.
Cricket analogy: This is like a franchise maintaining a fixed squad size of exactly 15 contracted players at all times — if an injury reduces the count, the franchise immediately signs a replacement to restore the squad to its required strength.
Example: A Kubernetes Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: payments-service
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
selector:
matchLabels:
app: payments-service
template:
metadata:
labels:
app: payments-service
spec:
containers:
- name: payments-service
image: registry.example.com/payments-service:1.4.2
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
readinessProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 5
maxUnavailable: 1 and maxSurge: 1 mean Kubernetes will take down at most 1 old pod and bring up at most 1 extra new pod at a time during a rolling update, keeping at least 3 of the 4 replicas serving traffic throughout the deployment.
Services and Load Balancing
A Kubernetes Service provides a stable virtual IP and DNS name in front of a set of pods selected by label, so other services can reach payments-service reliably even as individual pods are replaced during scaling or rolling updates. The kube-proxy component on every node programs iptables or IPVS rules that load-balance incoming connections across the healthy pod endpoints, and readiness probes ensure a pod only receives traffic once it has actually finished starting up and can serve real requests — a pod that's running but not yet ready is automatically excluded from the Service's endpoint list.
Cricket analogy: This is like a fixed team jersey number, say '18', always representing 'the current wicketkeeper' regardless of which specific player is wearing it this season, so fans and teammates always know who to look for by role.
Always set both resource requests and limits on every container. Without requests, the scheduler can't make good placement decisions and may overcommit a node; without limits, a single misbehaving pod can consume all of a node's CPU or memory and starve its neighbors, an incident commonly called the 'noisy neighbor' problem.
Scaling and Self-Healing
A HorizontalPodAutoscaler watches a metric like CPU utilization or a custom metric such as queue depth, and automatically adjusts the replica count within a configured min/max range to match load, scaling out during traffic spikes and back in during quiet periods to save cost. Self-healing happens continuously through liveness probes: if a container's liveness check fails repeatedly, the kubelet kills and restarts it automatically, and if an entire node goes unreachable, the control plane reschedules all of its pods onto healthy nodes — this reconciliation loop is what lets Kubernetes maintain the declared desired state without a human intervening for routine failures.
Cricket analogy: This is like a franchise's squad rotation policy automatically resting and rotating fast bowlers based on workload data during a packed tournament schedule, bringing in reserves without a human manually recalculating fatigue every match.
- Kubernetes is a container orchestrator that continuously reconciles actual cluster state to match a declared desired state.
- Pods are the smallest deployable unit; Deployments manage ReplicaSets to keep the desired replica count running.
- Rolling updates gradually replace old pods with new ones according to maxUnavailable and maxSurge settings.
- Services provide a stable virtual IP/DNS name that load-balances traffic across healthy pods.
- Readiness probes exclude not-yet-ready pods from receiving traffic; liveness probes trigger automatic restarts.
- Resource requests and limits are essential to avoid scheduler mistakes and the noisy neighbor problem.
- HorizontalPodAutoscaler adjusts replica count automatically based on CPU or custom metrics.
Practice what you learned
1. What is the primary role of a Kubernetes Deployment?
2. What happens if a node running two pods becomes unreachable in a healthy Kubernetes cluster?
3. What is the difference between a readiness probe and a liveness probe?
4. Why should containers always have both resource requests and limits configured?
5. What does a HorizontalPodAutoscaler do?
Was this page helpful?
You May Also Like
Containerizing Microservices
Learn how to package microservices into efficient, portable container images using Dockerfiles, multi-stage builds, and layer caching.
Service Discovery Explained
Understand how microservices find and communicate with each other dynamically, using service registries, health checks, and DNS-based discovery.
Service Mesh Explained
Explore how a service mesh uses sidecar proxies to manage traffic, security, and observability between microservices without changing application code.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics