Kubernetes Engineering Insights

Kubernetes exists because running containers reliably at scale is a fundamentally different problem than running one container on one machine.

Once you have more than a handful of containers across more than one host, you need answers to: which host runs which container, what happens when a host dies, how do containers find each other, how do you deploy a new version without downtime, and how do you scale up under load. Kubernetes is a standardized, battle-tested answer to all of these at once.

These aren't competitors — Kubernetes orchestrates containers, and those containers are typically built and run using Docker (or another OCI-compatible runtime).

Docker answers "how do I package and run this application as an isolated process?" Kubernetes answers "given many such containers across many machines, how do I keep them running, route traffic to them, and update them safely?" You need both concepts even if a cluster today uses containerd directly instead of the Docker daemon.

A container is a single isolated process; a Pod is Kubernetes' unit of scheduling — one or more containers that always run together.

Most Pods run exactly one container, so the distinction can feel academic — until you need a sidecar (a logging agent, a service mesh proxy) that must share the same network namespace and lifecycle as the main container. That's precisely what a multi-container Pod is for.

A ReplicaSet's only job is keeping N Pods running. A Deployment's job is managing transitions between different generations of ReplicaSets.

In the Kubernetes Service vs Ingress choice, a Service load-balances at the connection/IP level; Ingress adds HTTP-aware routing (hostnames, paths, TLS) in front of one or more Services.

A ClusterIP Service alone has no concept of URL paths or hostnames — it just forwards to whichever Pods match its selector. Ingress sits a layer above, inspecting HTTP requests and deciding which Service (and therefore which set of Pods) should handle them.

Liveness answers "should this be restarted?"; readiness answers "should this receive traffic right now?" — conflating them can cause outages.

Structurally near-identical — both inject key-value data into Pods — but Secrets exist for a different purpose and carry different handling guarantees.

ConfigMaps are plain text, meant for non-sensitive values. Secrets are base64-encoded (not encrypted by default) and typically subject to tighter RBAC — but base64 is encoding, not encryption, so production systems usually pair Secrets with encryption-at-rest or an external secret manager.

Kubernetes shines for stateless, horizontally-scalable workloads; stateful workloads are supported but require more deliberate care (StatefulSets, PVCs, careful storage choices).