What is Kubernetes?

Kubernetes is an open-source system that runs and manages your containers across a group of servers for you. A container is a lightweight package that holds your app and everything it needs to run. Once you have more than a handful of containers — spread across several machines, restarting when they crash, scaling up when traffic spikes — managing them by hand becomes painful. Kubernetes (often shortened to “K8s”, because there are 8 letters between the “K” and the “s”) was built to do that work automatically. It is the dominant container orchestration platform in 2026, which is why almost every DevOps role expects at least a working knowledge of it.

Where Kubernetes came from

Kubernetes was created by Google and released as open source in 2014. For over a decade before that, Google had been running its own internal system called Borg to manage billions of containers across its data centers. Kubernetes is the public, cleaned-up descendant of that experience. It is now governed by the Cloud Native Computing Foundation (CNCF), a neutral non-profit, so no single company owns it. That vendor-neutral ownership is a big reason every cloud provider supports it.

The name “Kubernetes” is Greek for “helmsman” or “pilot” — the person who steers a ship. The logo is a ship’s wheel. The idea is that you tell Kubernetes the destination (“I want 3 copies of my app running”), and it steers the cluster to keep you there.

What Kubernetes actually does

You describe the desired state of your system in a YAML file — for example, “run 3 copies of my web app, expose it on port 80, and restart any copy that dies.” This is called declarative configuration: you declare what you want, not the steps to get there. Kubernetes then constantly compares the real world to your desired state and fixes any difference. This loop is the heart of Kubernetes.

Concretely, it handles:

Job	What it means
Scheduling	Deciding which server runs which container, based on free CPU and memory.
Self-healing	Restarting crashed containers and replacing ones on a dead server.
Scaling	Adding or removing copies of your app as load changes.
Service discovery	Giving your app a stable internal name and IP so other apps can find it.
Load balancing	Spreading incoming traffic evenly across your app’s copies.
Rolling updates	Swapping in a new version gradually, with no downtime, and rolling back if it fails.

The core vocabulary

You only need three words to start reading any Kubernetes guide.

Cluster — the whole system: all the machines plus the Kubernetes software tying them together. When people say “deploy to the cluster”, they mean this.
Node — a single machine (a physical server or a virtual machine) inside the cluster. Your containers actually run on nodes. A cluster usually has several worker nodes.
Control plane — the “brain” of the cluster. It is the set of components that make global decisions: where to schedule containers, and how to react when something breaks. The control plane gives the orders; the nodes carry them out.

You almost never run a single container directly on Kubernetes. Instead, the smallest thing you deploy is a Pod — a wrapper around one (sometimes more) containers that share a network address. We cover Pods, Deployments, and Services on their own page.

        ┌─────────────────────────────┐
        │      Control plane (brain)  │  ← schedules, watches, decides
        └──────────────┬──────────────┘
                       │ orders
        ┌──────────────┼──────────────┐
     ┌──▼──┐        ┌──▼──┐        ┌──▼──┐
     │Node │        │Node │        │Node │   ← run your Pods/containers
     └─────┘        └─────┘        └─────┘

A first taste with kubectl

kubectl (pronounced “cube-control”) is the command-line tool you use to talk to a cluster. You will not have a cluster yet, but here is what the very first commands look like once you do. On Ubuntu you can install the client like this:

sudo apt update
sudo snap install kubectl --classic
kubectl version --client

Output:

Client Version: v1.33.1
Kustomize Version: v5.6.0

Once you point kubectl at a running cluster, asking for the nodes looks like this:

kubectl get nodes

Output:

NAME           STATUS   ROLES           AGE   VERSION
minikube       Ready    control-plane   2m    v1.33.1

That single Ready line is the cluster telling you it is healthy and waiting for work.

When to use Kubernetes — and when not to

Be honest with yourself here, because this is where most teams go wrong. Kubernetes is powerful, but it is also genuinely complex. It adds many moving parts, its own networking model, and a steep learning curve. Running it well usually means learning concepts you would never need for a single small app.

Your situation	Use Kubernetes?
One small app, one server, low traffic	No — use Docker Compose or a single systemd service.
A hobby project or MVP	No — a managed platform (PaaS) is faster and cheaper.
Many microservices that must scale independently	Yes — this is exactly what it is for.
Need zero-downtime rolling deploys across many machines	Yes.
A small team with no ops experience and tight deadlines	Probably not yet — start simpler, grow into it.

Gotcha: Kubernetes does not make a small app faster or more reliable on its own. For a single container on one server, it adds cost and risk, not value. Reach for it when the number of containers and machines becomes the problem — not before.

If you are unsure, that is normal. We dedicate a whole page to honestly answering “do you actually need Kubernetes?” — read it before committing.

Best practices

Learn the three core nouns — cluster, node, control plane — before touching any YAML; everything else builds on them.
Start on a local single-node cluster (Minikube or kind) so mistakes cost nothing.
Always describe what you want in version-controlled YAML files, not one-off kubectl commands, so your setup is repeatable.
Use a managed Kubernetes service (EKS, GKE, AKS) in production so a cloud provider runs the control plane for you.
Resist adding Kubernetes “to look modern” — adopt it only when scale or multi-service complexity genuinely demands it.
Keep your kubectl client version close to your cluster version to avoid subtle compatibility bugs.