What Is Kubernetes? Container Orchestration, Explained

Kubernetes (abbreviated K8s — K, eight letters, s) is an open-source platform for automating the deployment, scaling, and management of containerized applications. If you want the one-sentence definition: Kubernetes is a system that runs your containers across a cluster of machines, keeps them healthy, and scales them up or down — automatically, according to rules you declare.

Where Docker packages your application into a container, Kubernetes answers the harder question: how do you reliably run hundreds of those containers across dozens of machines, keep them healthy, and scale them without manual intervention?

Google open-sourced Kubernetes in 2014, drawing on lessons from its internal cluster management system, Borg. It was donated to the newly formed Cloud Native Computing Foundation (CNCF) in 2015 and has since become the de facto standard for container orchestration.

The problem Kubernetes solves

Running a single container in development is straightforward. Running a production service is not:

• What happens when a container crashes at 3 a.m.?
• How do you roll out a new version without taking the service down?
• When load spikes, how do you add more instances automatically?
• How do containers find and talk to each other across many machines?

Kubernetes handles all of this. It continuously reconciles the desired state you declare (say, “run 5 replicas of this container”) against the actual state of your cluster and takes action to close the gap.

Core concepts

Pods are the smallest deployable unit in Kubernetes. A pod wraps one or more containers that share a network namespace and storage. In practice, most pods contain a single container.

Nodes are the machines (virtual or physical) that actually run your pods. A cluster typically has many nodes.

Deployments are the standard way to declare how many replicas of a pod you want. You define a deployment in YAML and Kubernetes creates, monitors, and restarts pods to match:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: my-org/web-app:v2.1
          ports:
            - containerPort: 8080

Apply this file with kubectl apply -f deployment.yaml and Kubernetes ensures three instances of web-app:v2.1 are always running.

Services give a stable DNS name and IP to a set of pods. Because individual pods are ephemeral (they crash, get rescheduled, get new IPs), you don’t address pods directly. A Service sits in front and load-balances traffic across healthy pods — the in-cluster cousin of a load balancer.

A few more objects round out the everyday vocabulary: Namespaces partition one cluster into logical environments (say, staging and production); ConfigMaps and Secrets inject configuration and credentials into pods without baking them into images; and an Ingress routes external HTTP traffic to the right Service. We walk through the big three in detail in Kubernetes pods, deployments, and services, explained.

Declarative YAML and self-healing. Kubernetes is declarative: you describe what you want, not how to achieve it. If a node fails and takes two pods with it, Kubernetes notices the desired count is no longer met and schedules replacements on healthy nodes. This self-healing behavior is built-in. (All that YAML has trade-offs of its own — see JSON vs YAML for why config formats matter.)

Autoscaling. The Horizontal Pod Autoscaler watches CPU or custom metrics and adjusts the replica count automatically. Under load, your deployment grows; when load drops, it shrinks.

What the control plane actually runs

The control plane is the brain of the cluster, and it’s worth knowing its four main pieces by name:

• API server — the single entry point for every cluster operation; kubectl, CI pipelines, and the cluster’s own components all talk to it.
• etcd — a distributed key-value store holding the entire cluster state. Lose etcd and you lose the cluster’s memory.
• Scheduler — decides which node each new pod lands on, based on resource requests, affinity rules, and available capacity.
• Controller manager — runs the reconciliation loops that compare desired state with reality and fix the difference.

Each worker node runs a kubelet (the agent that starts and monitors pods), a container runtime such as containerd, and kube-proxy (which wires up Service networking).

Day to day you interact with all of this through a handful of kubectl commands:

kubectl get pods              # list running pods
kubectl describe pod web-app  # inspect one pod's state and events
kubectl logs web-app-7f9c4    # read a container's logs
kubectl apply -f app.yaml     # declare desired state
kubectl rollout undo deploy/web-app  # roll back a bad release

Kubernetes vs Docker

Docker and Kubernetes are complementary, not competing. Docker (or another container runtime) builds and runs individual containers. Kubernetes orchestrates them. A common mental model: Docker is how you package and run one container; Kubernetes is how you run a fleet of them reliably in production. The full story — including why Kubernetes dropped Docker as a runtime while your Docker-built images kept working — is in Kubernetes vs Docker: what’s the difference.

You can explore deeper ecosystem tooling — such as the observability capabilities unlocked by eBPF in the Linux kernel — to understand how Kubernetes platforms are instrumented at scale.

Do you actually need Kubernetes?

Kubernetes is powerful, but it comes with genuine operational complexity. A small team running a handful of services should honestly consider simpler options first: managed container services (AWS ECS, Google Cloud Run, Fly.io), a PaaS, or even a well-tuned single server.

Kubernetes pays off when you have:

• Many services that need independent scaling and deployment lifecycles.
• A team with platform capacity to maintain the cluster (or you use a managed service like GKE, EKS, or AKS that handles the control plane for you).
• Requirements around multi-tenant isolation, custom networking, or workloads that don’t fit serverless constraints.

The rise of Internal Developer Platforms is partly a response to Kubernetes’ complexity — teams build abstractions on top of it so application developers can deploy without needing to understand every YAML field.

Common questions

What does K8s stand for?

It’s a numeronym: K, then the eight letters “ubernete,” then s. The name Kubernetes is Greek for “helmsman” — the person steering a ship.

Is Kubernetes free?

Yes. Kubernetes itself is open source under the Apache 2.0 license. What costs money is the infrastructure it runs on and, optionally, a managed control plane from a cloud provider (GKE, EKS, AKS).

What’s the difference between Kubernetes and Docker Swarm?

Swarm is Docker’s built-in orchestrator — simpler to set up, far smaller ecosystem. Kubernetes won the orchestration race years ago; Swarm survives mostly in small deployments that value its simplicity.

Who created Kubernetes?

Google, in 2014, based on its internal Borg system. It’s now maintained by the community under the Cloud Native Computing Foundation, with contributions from every major cloud vendor.

The takeaway

Kubernetes solves the hard operational problems that appear when you need to run containerized workloads reliably at scale: scheduling, self-healing, scaling, and service discovery. Its declarative model — describe desired state, let the system reconcile — is a significant conceptual shift from scripting deployments manually, and a genuinely better model for production systems. The honest caveat is that Kubernetes is substantial infrastructure. Start with a managed offering (GKE, EKS, AKS) rather than running your own control plane, and consider whether a simpler platform fits your scale before committing to the full Kubernetes operational model.