Kubernetes Fundamentals

Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services. The name comes from Greek for "helmsman" or "pilot" — K8s counts the eight letters between the K and the s. Google open-sourced it in 2014, distilling over fifteen years of experience running production workloads at scale, and it is now maintained by the Cloud Native Computing Foundation with one of the largest ecosystems in open source.

The useful mental model: Kubernetes is a desired-state machine for containers. You declare what you want — "run three replicas of this container image, give each half a CPU, expose them behind one stable address" — and Kubernetes continuously works to make reality match your declaration. If a container crashes, a node dies, or traffic shifts, the system converges back toward what you asked for without anyone being paged to restart things by hand.

Why Kubernetes exists

Containers solved packaging: an application and its dependencies bundled into one portable, isolated unit that runs the same everywhere. But containers alone don't answer production questions. If a container goes down, who starts a replacement? When traffic doubles, who adds capacity? How do a hundred containers across dozens of machines find and talk to each other?

Kubernetes is the framework that answers those questions for distributed systems. Out of the box it provides service discovery and load balancing (a DNS name or stable IP for a changing set of containers), storage orchestration (mounting local or cloud storage automatically), automated rollouts and rollbacks (changing actual state toward desired state at a controlled rate), automatic bin packing (fitting containers onto nodes based on their CPU and memory requests), self-healing (restarting failed containers and withholding traffic until they're ready), and secret and configuration management.

Equally important is what Kubernetes is not: it is not a traditional all-inclusive PaaS. It doesn't build your application, doesn't ship a message bus or database, doesn't dictate a logging or monitoring stack, and doesn't limit the types of applications you can run. It supplies the building blocks and deliberately leaves the opinions to you and to its ecosystem.

The architecture in one paragraph

A Kubernetes cluster is a control plane plus one or more worker nodes. The control plane manages overall cluster state: the kube-apiserver exposes the Kubernetes HTTP API (the front door for everything), etcd stores all API data in a consistent, highly available key-value store, the kube-scheduler assigns Pods that don't yet have a node to a suitable one, and the kube-controller-manager runs the controllers that implement API behavior (an optional cloud-controller-manager integrates with a cloud provider). On every node, the kubelet ensures the containers described by Pods are running and healthy, a container runtime actually runs them, and kube-proxy (optional, depending on the network setup) implements Service traffic routing.

Objects, declarations, and controllers

You interact with Kubernetes almost entirely by creating and updating objects through the API — usually written as YAML manifests and applied with kubectl. Every object carries a spec (the state you want) and a status (the state it currently has). Controllers are control loops that watch objects and act to move status toward spec — the pattern the whole system is built on.

The atom of the system is the Pod: one or more tightly coupled containers that share network identity and storage, always scheduled together onto one node. You rarely create Pods directly; you create higher-level workload objects — a Deployment for stateless replicated services is the workhorse — and their controllers create and replace Pods for you. Pods are deliberately disposable; everything durable about your application lives in the declarations, not in any individual Pod.

Three organizing mechanisms matter from day one: namespaces partition one cluster into virtual sub-clusters (teams, environments); labels are key/value tags on objects that queries and controllers select on (this is how a Service knows which Pods belong to it); and annotations hold non-identifying metadata for tools.

Who uses it, and for what

Kubernetes is the de facto substrate for cloud-native platforms: web services and APIs, batch and machine-learning jobs, event-driven systems, and increasingly databases and stateful systems too. Application developers deploy onto it; platform and DevOps engineers build the paved roads on top of it; operations teams run the clusters themselves. Every major cloud sells a managed control plane (EKS, GKE, AKS and friends), which is how most teams consume it — you still need to understand the concepts, but not necessarily to operate etcd.

Limits and honest caveats

Kubernetes trades simplicity for capability. For a single small application, it is usually overkill — a container on a VM or a simpler PaaS may serve better. Its flexibility means many decisions (networking plugin, ingress strategy, storage, observability) are yours to make, and the ecosystem's size is itself a navigation problem. Clusters are also not a security boundary by default: multi-tenancy, network segmentation, and workload hardening all require deliberate configuration. This course gives you the map; the rest of the series covers each territory — workloads, networking, storage, security, scheduling, observability, operations, and operators — in its own right.