Kubernetes: Pods, Deployments, Services & Scaling

Kubernetes

Kubernetes (K8s) is a container orchestration platform: you give it containers and a description of the desired state, and it handles deployment, scaling, networking, and self-healing across a cluster of machines. It's effectively a distributed operating system for containers.

The core idea is declarative reconciliation — you declare what you want (3 replicas of this image, exposed on this port), and controllers continuously work to make reality match. That power comes with real operational complexity, so it's worth using only when you actually need orchestration at scale.

TL;DR

Orchestrates containers across many machines: scaling, networking, self-healing.
You declare desired state in YAML; controllers reconcile toward it.
Deploy with Deployments (not bare Pods); expose with Services.
Powerful but heavy — for small workloads, a PaaS or Compose is simpler.

Quick Example

A Deployment declares the desired state — "keep 3 replicas of this image running" — and K8s maintains it:

Core Concepts

Cluster / Node — a set of machines; each node runs workloads.
Pod — the smallest deployable unit; one or more containers, ephemeral.
Deployment — declarative management of Pods and rolling updates.
Service — a stable network endpoint (and load balancing) for a set of Pods.
Namespace — virtual partitioning of cluster resources.
ConfigMap / Secret — non-sensitive config / sensitive data for Pods.
Ingress — HTTP(S) routing into Services.

💡 Pods are disposable — they're created and destroyed constantly. Services give you the stable address; controllers replace failed Pods automatically.

When to Use It (and Not)

Use it for: microservice platforms, autoscaling workloads, multi-team/multi-tenant clusters, ML training/serving, multi-region apps.
Skip it for: simple monoliths, tiny teams, or while you're still learning containers — the operational overhead rarely pays off. Start with managed PaaS or Docker Compose.

Best Practices

Use Deployments, not bare Pods, so failures self-heal and updates roll.
Set resource requests/limits so one workload can't starve the node.
Add liveness and readiness probes so K8s knows when a Pod is healthy.
Isolate environments/teams with namespaces and lock down access with RBAC.
Prefer managed clusters (EKS, GKE, AKS) over self-managing the control plane.

Common Mistakes

Running bare Pods

No resource limits or probes

FAQ

What problem does Kubernetes actually solve?

Running many containers across many machines reliably — scheduling them onto nodes, restarting failed ones, scaling with load, networking between services, rolling out updates, and managing config/secrets. Doing all that by hand doesn't scale; Kubernetes automates it behind a declarative API.

Do I need Kubernetes?

Often no. For a monolith or a small number of services, a managed PaaS (Cloud Run, App Runner, Fly.io) or Docker Compose is far simpler. Adopt Kubernetes when you have many services, need autoscaling and self-healing, or run multi-team infrastructure at scale.

What's the difference between a Pod and a Deployment?

A Pod is the running unit (one or more containers); it's ephemeral and not self-healing on its own. A Deployment manages Pods declaratively — it maintains the replica count, replaces failures, and performs rolling updates. You almost always create Deployments, not Pods.

Should I self-host or use a managed cluster?

Use a managed control plane (EKS, GKE, AKS) unless you have a strong reason not to. Operating the control plane, etcd, and upgrades yourself is significant work; managed services handle that so you focus on your workloads.