How Things Work

Containers & Kubernetes

How containers and orchestration run microservices at scale — declarative desired state, the reconciliation loop that self-heals, Pods and Services, and zero-downtime rolling updates.

How It Works

Containers package applications into portable, lightweight units; Kubernetes orchestrates them across a cluster. Its core idea is declarative: you describe the desired state, and controllers continuously reconcile reality toward it — restarting failed Pods, scaling, and rolling out new versions automatically. This is what makes microservices operable at scale, with self-healing and zero-downtime deploys built in.

Containers: Package Once, Run Anywhere

A container bundles an app with its exact dependencies into a portable image that runs identically on any host — solving 'works on my machine'. Unlike VMs, containers share the host kernel, so they're lightweight, start in seconds, and pack densely onto machines.

Orchestration: Why Kubernetes

Running a handful of containers is easy; running hundreds across many machines — scheduling them, restarting failures, scaling, networking, and rolling out updates — is not. Kubernetes is the orchestrator that automates all of this across a cluster of nodes.

Declarative State & Reconciliation

You declare desired state ('run 3 replicas of v2') in a manifest; you don't issue imperative commands. Controllers in the control plane continuously compare desired vs actual state and act to close the gap — if a Pod dies, a replacement is started automatically. This reconciliation loop is what gives Kubernetes self-healing.

Pods, Services & Rolling Updates

A Pod is the smallest deployable unit (one or more containers). A Deployment manages a replica set of identical Pods. A Service gives them a stable DNS name and load-balances across them. A rolling update surges new-version Pods up and drains old ones gradually — keeping capacity available throughout for zero-downtime deploys (with instant rollback if a new version misbehaves).

Key Concepts

📦Container

A lightweight, portable package of an app + its dependencies sharing the host kernel. Starts fast, runs anywhere.

🫛Pod

Kubernetes' smallest deployable unit — one or more tightly-coupled containers sharing network and storage.

📋Deployment

Declares a desired number of identical Pod replicas and manages rollouts/rollbacks of new versions.

🔁Reconciliation Loop

Controllers continuously drive actual state toward declared desired state — the source of self-healing.

🌐Service

A stable DNS name + virtual IP that load-balances across a Deployment's healthy Pods.

🚀Rolling Update

Gradually replacing Pods with a new version while keeping capacity, enabling zero-downtime deploys.

Deployment + Service manifest

tsx

1# Declare DESIRED state — Kubernetes continuously reconciles toward it.
2apiVersion: apps/v1
3kind: Deployment
4metadata: { name: orders-api }
5spec:
6  replicas: 3                      # keep exactly 3 Pods running
7  strategy:
8    type: RollingUpdate            # zero-downtime deploys
9    rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }
10  selector: { matchLabels: { app: orders-api } }
11  template:
12    metadata: { labels: { app: orders-api } }
13    spec:
14      containers:
15        - name: api
16          image: registry/orders-api:v2     # change to v2 → triggers rollout
17          readinessProbe:                    # don't send traffic until ready
18            httpGet: { path: /health, port: 8080 }
19          resources:
20            requests: { cpu: 100m, memory: 128Mi }   # scheduler placement
21            limits:   { cpu: 500m, memory: 256Mi }
22---
23# A Service gives the Pods one stable DNS name + load-balanced virtual IP.
24apiVersion: v1
25kind: Service
26metadata: { name: orders-api }
27spec:
28  selector: { app: orders-api }
29  ports: [{ port: 80, targetPort: 8080 }]

💡

Why This Matters

Containers and Kubernetes are the de facto runtime for microservices, and understanding declarative state, reconciliation, Pods/Services, and rolling updates is essential for deploying and operating modern systems — and increasingly expected in interviews. The mental model (desired vs actual state) explains nearly everything Kubernetes does.

Common Pitfalls

⚠No readiness/liveness probes — traffic hits Pods before they're ready, or dead Pods aren't restarted.

⚠Missing resource requests/limits — the scheduler can't place Pods well and a noisy Pod starves neighbors.

⚠Treating Pods as pets with local state — Pods are ephemeral; persist state externally (volumes, DBs).

⚠Rolling updates with maxUnavailable too high (or no surge), causing capacity dips and dropped requests.

⚠Adopting Kubernetes' full complexity for a tiny app that a single container or PaaS would serve better.

Real-World Use Cases

1A Crashed Node at 3 AM — and Nobody Paged

Scenario

A node hosting several service Pods dies overnight. In the old VM world this meant a pager alert and manual recovery. With Kubernetes, by the time anyone looked, the affected Pods were already running again on healthy nodes.

Problem

Hardware and processes fail unpredictably. Manual recovery is slow, error-prone, and doesn't scale across hundreds of services — and it always seems to happen at the worst time.

Solution

Because the Deployment declares 'keep N replicas running', the controller detected the lost Pods (actual < desired) and rescheduled replacements on other nodes automatically. The Service updated its endpoints to the new healthy Pods, and traffic kept flowing.

💡

Takeaway: Declarative desired state + reconciliation gives self-healing for free. You describe what should be running; Kubernetes makes reality match it continuously, turning node failures into non-events.

2Shipping 20× a Day Without Downtime (and Safe Rollback)

Scenario

A team wants to deploy frequently, but each release used to require a maintenance window because restarting all instances dropped requests, and a bad release meant a scramble to revert.

Problem

Replacing all instances at once causes downtime, and rolling back a faulty manual deploy is slow and risky — discouraging frequent, small releases.

Solution

Use a RollingUpdate strategy with readiness probes: Kubernetes brings up new-version Pods, waits until they pass their health check before sending traffic, then drains old Pods one batch at a time. If the new version misbehaves, kubectl rollout undo instantly reverts to the previous ReplicaSet.

💡

Takeaway: Rolling updates with readiness probes give zero-downtime deploys and one-command rollback, making frequent, low-risk releases routine instead of a scheduled event.

Join the discussion

Comments

Loading comments...

Cookie preferences

We use essential cookies for sign-in and preferences. With your permission, we also use basic analytics to improve lessons.