What Is Kubernetes? Container Orchestration Explained

Kubernetes (often abbreviated K8s — eight letters between the K and the s) is the most talked-about and most over-applied tool in modern infrastructure. This post explains, in plain terms, what Kubernetes actually does, why so many companies adopted it, and when you should absolutely not bother with it.

The problem Kubernetes solves

Docker is great at running one container on one machine. But production rarely looks like that.

In production you usually want:

• Many copies of a container running for capacity and redundancy
• Automatic restarts when a container crashes
• Automatic rescheduling when an entire server dies
• Rolling updates that swap old containers for new ones without downtime
• A stable network address for a service whose underlying containers come and go
• Configurable resource limits so a runaway process does not starve its neighbours
• A way to declare all of the above in version-controlled files

Doing this by hand on a fleet of servers is tedious and error-prone. Container orchestration is the broad name for tools that automate it. Kubernetes is by far the most popular orchestrator — to the point where for many teams “orchestration” simply means Kubernetes.

Quick definition. Kubernetes is an open-source system for running containers across a fleet of machines, with built-in scheduling, self-healing, networking, and configuration. You tell it the desired state (“I want three copies of this app, exposed on port 80”), and it works out how to make reality match.

How Kubernetes thinks

Kubernetes is declarative. You do not write scripts that say “first do this, then do that.” You write YAML files that describe what should exist — three replicas of this image, a service of that shape, this much CPU — and Kubernetes continuously works to make the cluster match.

If a node dies, Kubernetes notices and reschedules its workloads elsewhere. If a container crashes, Kubernetes restarts it. If you change the YAML and apply it, Kubernetes rolls out the difference. The loop never stops running.

This is a big mental shift from docker run. With Docker, you are responsible for the state of the system. With Kubernetes, you are responsible for describing the state; the system enforces it.

The vocabulary

Six terms cover almost everything you will read in Kubernetes docs.

Cluster. The whole installation — one or more machines running Kubernetes together. A cluster has exactly one logical control plane (the brain) and one or more nodes (the workers).

Node. A single machine in the cluster. Could be a physical server, a virtual machine, or even your laptop in development. Each node runs a small agent (kubelet) that talks to the control plane.

Pod. The smallest deployable unit. A pod wraps one (usually) or more closely related containers that share a network and storage. Pods are ephemeral — Kubernetes creates and destroys them freely.

Deployment. A higher-level object that says “I want N copies of this pod, and I want updates to be rolled out gradually.” A deployment manages a ReplicaSet behind the scenes; you rarely deal with ReplicaSets directly.

Service. A stable network endpoint for a set of pods. Pods come and go; their IP addresses change. A service gives them a consistent DNS name and load-balances traffic across whichever pods are currently alive.

Namespace. A way to partition a cluster into virtual sub-clusters. Useful for separating environments (dev, staging) or teams. The default namespace is, helpfully, called default.

Internalise these six words and most Kubernetes tutorials become readable.

A typical workload, in pieces

Imagine deploying a small web API to Kubernetes. You would create three objects:

1. A Deployment that says “run three copies of my web-api:1.4.0 container, each requesting 100 millicores of CPU and 128 MB of RAM.”
2. A Service that says “give those pods a stable name (web-api) inside the cluster, on port 80.”
3. An Ingress or LoadBalancer Service that exposes the service to the outside world on a real domain.

You write three YAML files (or one combined file), run kubectl apply -f ., and Kubernetes figures out where to schedule the pods, how to wire up the networking, and how to keep three copies running even when nodes fail.

Here is the shape of the YAML — covered properly in the next post:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-api
  template:
    metadata:
      labels:
        app: web-api
    spec:
      containers:
        - name: web-api
          image: web-api:1.4.0
          ports:
            - containerPort: 3000

That is the declarative essence: you describe what you want; Kubernetes makes it true.

The command-line tool

Almost all interaction with Kubernetes happens through kubectl (pronounced “kube-control” or “kube-cuddle,” depending on who you ask). A few examples you will use constantly:

# Apply (or update) resources from a YAML file
kubectl apply -f deployment.yaml

# List things
kubectl get pods
kubectl get deployments
kubectl get services

# Look at one thing in detail
kubectl describe pod web-api-7d4f-xyz

# View logs from a pod
kubectl logs web-api-7d4f-xyz

# Open a shell inside a pod
kubectl exec -it web-api-7d4f-xyz -- sh

kubectl is the universal translator between your terminal and the cluster. Every operation is either reading state (get, describe, logs) or pushing new desired state (apply, delete).

When Kubernetes is overkill

This is the most important section in this post.

Kubernetes is genuinely useful when you have:

• Many services that need to be deployed independently
• Real production traffic that requires self-healing and rolling updates
• A team large enough to invest in operating a cluster
• Or you are paying a cloud provider to operate one for you

Kubernetes is overkill when:

• You have a single application that fits on one server
• A docker compose up would solve your problem
• A managed PaaS (Fly.io, Render, Railway, Cloud Run) would solve your problem
• You are the only developer and you would rather build features than YAML

The default state of the internet is “one Docker container is enough.” Reach for Kubernetes when you have concrete pain that Kubernetes is known to solve — not because it is on a CV checklist.

This is not contrarian; the Kubernetes community largely agrees. Even the DHH essay on leaving the cloud is, in part, a story about not needing K8s.

Managed Kubernetes

Operating Kubernetes yourself is a serious commitment — patches, upgrades, certificate rotation, networking, storage drivers. Most teams that “use Kubernetes” actually use a managed offering, where a cloud provider runs the control plane and you just bring workloads.

The big three:

• Amazon EKS — Elastic Kubernetes Service on AWS
• Google GKE — Google Kubernetes Engine, the original managed K8s
• Azure AKS — Azure Kubernetes Service

Smaller but excellent:

• DigitalOcean Kubernetes — friendly, cheaper, great for learning
• Linode/Akamai Kubernetes Engine — similar profile to DO
• Civo, Vultr — budget-friendly managed K8s

For local development and learning, you do not need any of these. Tools like Minikube, kind (Kubernetes-in-Docker), and k3d run a small cluster on your laptop in seconds. Docker Desktop even ships with an optional single-node cluster you can enable in settings.

What Kubernetes is not

A few common misconceptions are worth clearing up.

Kubernetes is not a replacement for Docker. It runs containers — usually built with Docker — across many machines. The container runtime underneath has shifted away from Docker itself (most clusters use containerd directly now), but the images are the same.

Kubernetes is not a PaaS. It is closer to a toolbox than a finished product. You typically layer extra tools on top — Helm for templating, Argo CD for deployment, Prometheus for metrics, cert-manager for TLS — to turn a cluster into a usable platform.

Kubernetes is not “the cloud.” You can run Kubernetes on bare metal in your basement. The cloud just happens to be the most convenient place to run it.

Kubernetes is not simple. Anyone who tells you otherwise has either internalised the complexity or is trying to sell you something. The flip side: once you learn the vocabulary, an enormous amount of cross-vendor knowledge becomes portable.

Why Kubernetes won

A few reasons turned Kubernetes from “Google open-sources their internal tool” into the default orchestrator:

• It is declarative. Files in Git describe the system; the cluster makes reality match
• It is extensible. Custom Resource Definitions let you add new object types without forking the project
• It is portable. The same YAML runs on AWS, GCP, Azure, on-premises, and on your laptop
• It has a massive ecosystem. Almost every infrastructure tool now has a “how to run it on K8s” page
• It is governed neutrally by the CNCF, which made enterprises comfortable adopting it

The cost is operational complexity. The benefit, for teams large enough to absorb that cost, is a common substrate for everything they run.

Recap

You now know:

• Kubernetes is a container orchestrator — it runs containers across many machines with scheduling, self-healing, and networking built in
• The core vocabulary is cluster, node, pod, deployment, service, and namespace
• It is declarative: you describe desired state in YAML and the cluster enforces it
• kubectl apply, get, describe, logs, and exec cover most everyday work
• It is overkill for small projects — reach for it when concrete pain demands it
• Managed offerings (EKS, GKE, AKS, DOKS) remove most of the operational burden

Next steps

The next post is hands-on with YAML: you will write a pod, a deployment, and a service, apply them to a local cluster, and watch Kubernetes keep your app alive even when you delete the underlying pod by hand.

→ Next: Kubernetes Pods, Deployments, and Services

Questions or feedback? Email codeloomdevv@gmail.com.