What Is Kubernetes? A Clear, Accurate Guide for Developers

Kubernetes is an open-source platform for running containerized applications across a cluster of machines. You declare the state you want, and Kubernetes works continuously to make the running system match that state, restarting failed containers, replacing unhealthy nodes, and rescheduling workloads as conditions change.

What Kubernetes actually is

Kubernetes (often abbreviated K8s, the "8" standing for the eight letters between K and s) is a container orchestrator. It was originally developed at Google, released as open source in 2014, and is now governed by the Cloud Native Computing Foundation. A single container engine like Docker or containerd can run containers on one machine; Kubernetes coordinates many containers across many machines and keeps them running as a group.

The defining idea is the declarative model. Instead of issuing step-by-step commands ("start this, then that"), you submit a description of the desired end state — for example, "run five replicas of this web service." Kubernetes compares that desired state against the observed state and takes whatever action closes the gap. This loop runs constantly, which is why a crashed container comes back automatically without anyone intervening.

If you already understand containers and have used a tool like Docker Compose to run a few services together on one host, Kubernetes solves the same coordination problem at a much larger scale, with self-healing and scheduling across multiple machines. Our Docker configuration guide covers the container layer that Kubernetes builds on top of.

How it works: the control plane and worker nodes

A Kubernetes cluster has two kinds of machines. Worker nodes run your application containers. The control plane makes global decisions about the cluster — scheduling, scaling, and responding to events.

Control plane components

• API server — the front door to the cluster. Every command and every internal component communicates through this REST API. If you understand what an API is, the API server is exactly that: the single interface through which all reads and writes flow.
• etcd — a consistent key-value store that holds the entire cluster state. It is the source of truth; losing etcd means losing the cluster's memory.
• Scheduler — decides which node a new pod should run on, based on resource requests, constraints, and available capacity.
• Controller manager — runs the reconciliation loops that drive observed state toward desired state.

Worker node components

• kubelet — an agent on each node that starts and monitors the containers assigned to it and reports their status back to the API server.
• kube-proxy — maintains the network rules that let traffic reach the right pods.
• Container runtime — the software (such as containerd or CRI-O) that actually runs containers.

The core objects you work with

You rarely manage individual containers directly. Instead you work with higher-level objects, almost always defined in YAML manifests. (Kubernetes manifests are plain YAML; a YAML to JSON converter is handy when you need to inspect or transform them programmatically.)

• Pod — the smallest deployable unit. A pod wraps one or more tightly coupled containers that share a network address and storage. Pods are designed to be disposable.
• Deployment — manages a set of identical pods (a ReplicaSet) and handles rolling updates and rollbacks. This is how you run most stateless services.
• Service — gives a stable network identity and load-balances traffic across a changing set of pods. Because pod IP addresses come and go, Services provide a fixed name that other workloads can rely on.
• ConfigMap and Secret — inject configuration and sensitive values into pods, keeping them out of the container image.
• Namespace — a logical partition for grouping and isolating resources within one cluster.

Inside the cluster, components find each other by name through Kubernetes' built-in DNS. A Service named payments in a namespace is reachable at a predictable DNS name, which is why understanding how DNS works helps a lot when debugging service-to-service traffic.

Why teams use it

Kubernetes earns its place when applications need to be resilient and elastic without constant manual effort.

• Self-healing — failed containers restart, unresponsive ones are replaced, and pods on a dead node are rescheduled elsewhere.
• Declarative rollouts — Deployments roll out new versions gradually and can roll back automatically if health checks fail, reducing risky deploys.
• Horizontal scaling — you can scale replicas up or down by changing one number, or let the Horizontal Pod Autoscaler adjust based on metrics like CPU usage.
• Portability — the same manifests run on a laptop, a data center, or any major cloud, which reduces lock-in to a single provider's proprietary services.
• A consistent extension point — the API can be extended with Custom Resource Definitions, so the same declarative workflow manages databases, certificates, and other infrastructure.

When you actually need it (and when you don't)

Kubernetes is powerful, but it is not free of cost. It adds real operational complexity: networking, storage, security policy, upgrades, and monitoring all become things your team must understand.

It tends to pay off when you run many services, need high availability across nodes, deploy frequently, or have variable load that benefits from autoscaling. It is usually overkill for a single small application, an early-stage prototype, or a static site. For those, a single container host, a managed container service, or a platform-as-a-service is simpler and cheaper. A reasonable progression is: start with a Dockerfile to containerize the app, run it locally, and only adopt Kubernetes once coordinating multiple services and machines becomes the actual bottleneck.

Most teams that do adopt it use a managed Kubernetes service (such as the offerings from the major cloud providers) so they don't have to operate the control plane themselves. Self-hosting the control plane is a significant undertaking.

Common pitfalls

• No resource requests or limits. Without CPU and memory requests, the scheduler can't place pods well; without limits, one workload can starve others. Set both deliberately.
• Missing health probes. Liveness and readiness probes are how Kubernetes knows whether to restart a container or send it traffic. Skipping them undermines self-healing and can route requests to pods that aren't ready.
• Treating pods as permanent. Pods are ephemeral and get IP addresses that change. Always reach a workload through a Service, never a pod IP.
• Storing state in pods. Stateless workloads fit the model naturally; databases and other stateful systems need StatefulSets and persistent volumes, and are often better run as managed services.
• Putting secrets in manifests or images. Secrets belong in Secret objects (and ideally an external secret manager), not committed YAML or baked-in images.
• Underestimating the learning curve. The breadth of Kubernetes is its biggest hidden cost. Budget time for the team to learn it before betting production on it.

Frequently Asked Questions