Kubernetes — by definition — is a container orchestration tool. That is really all there is to it at the highest level. But unpacking what that means requires a quick primer on Docker first, because the two technologies are deeply intertwined and understanding one makes the other much easier to grasp.
This article is written as an accessible, plain-language introduction to both technologies. It is not an exhaustive reference — think of it as the foundation you need before diving into the official documentation or a hands-on tutorial.
What Is Docker?
Docker is software that packages applications into portable, self-contained units called images. To appreciate why that matters, consider what it takes to share an application you have written.
Suppose you write a To-do app in Node.js. On your machine you have the right runtime installed, the right libraries, and the right environment variables set. You hand the source code to a friend who runs a different operating system. Immediately, problems appear: missing dependencies, wrong library versions, a different file-system layout. The code that works perfectly on your laptop does not run on theirs.
Docker solves this by bundling your application together with everything it needs to run — the OS filesystem, runtime, libraries, and configuration — into a single artefact called a Docker image. That image can be executed on any machine that has a Docker runtime installed, regardless of the underlying operating system.
Images vs. Containers
- Image: A read-only blueprint that describes what your application and its environment look like.
- Container: A running instance of an image — an isolated process on the host machine.
A common concern is that shipping an entire OS filesystem sounds heavy. In practice, minimal Linux distributions such as Alpine Linux are only a few megabytes, so images can remain very lean.
The workflow is straightforward:
- Write a
Dockerfilethat describes how to build your image. - Run
docker buildto produce the image. - Push the image to a registry (such as Docker Hub or a private registry).
- Anyone with Docker installed can pull and run the image with a single command.
So Where Does Kubernetes Come In?
Docker is excellent at packaging and running a single container. But real-world production services are rarely a single container running on a single machine. They involve many containers, many machines, traffic spikes, failures, rolling updates, and dozens of other operational concerns. Managing all of that by hand does not scale.
Returning to the To-do app example: you have packaged it as a Docker image and you want to expose it as a public web service. Now you face a new set of questions:
- What happens when the container crashes? Does it restart automatically?
- How do you handle a sudden surge in traffic without manually provisioning more servers?
- How do you roll out a new version without downtime?
- How do you route traffic to healthy instances only?
- How do you restrict which parts of your system can talk to each other?
Kubernetes answers all of these questions. It orchestrates your containers — deciding where they run, restarting them when they fail, scaling them up or down based on load, and exposing them to the network in a controlled way.
Core Kubernetes Concepts
You do not need to memorise every Kubernetes primitive before getting started, but the following four concepts form the foundation of almost everything else.
1. Clusters and Nodes
Kubernetes operates on a cluster — a group of machines (physical or virtual) that work together. Each machine in the cluster is called a node.
Nodes come in two roles:
- Control-plane nodes (formerly called master nodes): Run the Kubernetes system components that make cluster-wide decisions — what to run, where to run it, and whether the current state matches the desired state.
- Worker nodes: Run your application workloads. They receive instructions from the control plane and report back their status.
2. The Control Plane
The control plane is the brain of the cluster. Its core components include:
- kube-apiserver: The front door to the cluster. Every interaction — from the CLI, from internal components, from external tooling — goes through the API server.
- kube-scheduler: Watches for new workloads and decides which node they should run on, based on available resources and constraints.
- kube-controller-manager: Runs control loops that continuously reconcile the current state of the cluster with the desired state you have declared.
Worker nodes run two key agents:
- kubelet: Ensures containers described in Pod specs are running and healthy on that node.
- kube-proxy: Manages network rules on the node to enable service-to-service communication within the cluster.
3. Declarative Configuration
You interact with Kubernetes by describing what you want, not how to achieve it. You write a configuration file — in YAML or JSON — that declares the desired state, and Kubernetes works continuously to make reality match that declaration.
A minimal example of a Kubernetes Deployment manifest:
apiVersion: apps/v1
kind: Deployment
metadata:
name: todo-app
spec:
replicas: 3
selector:
matchLabels:
app: todo
template:
metadata:
labels:
app: todo
spec:
containers:
- name: todo
image: your-registry/todo-app:latest
ports:
- containerPort: 3000
This tells Kubernetes: run three copies of this container image and keep them running. If one crashes, Kubernetes automatically starts a replacement.
4. kubectl — The CLI Tool
The primary way to interact with a Kubernetes cluster is through kubectl, the official command-line interface. Common operations include:
kubectl apply -f deployment.yaml— apply a configuration file to the cluster.kubectl get pods— list running pods.kubectl logs <pod-name>— stream logs from a container.kubectl describe pod <pod-name>— inspect a pod’s events and status.
What Kubernetes Handles for You
To make the value concrete, here is a summary of what Kubernetes manages once your application is deployed:
- Self-healing: Failed containers are restarted automatically. Nodes that become unresponsive cause their workloads to be rescheduled elsewhere.
- Horizontal scaling: Increase or decrease the number of running replicas with a single command or automatically via a Horizontal Pod Autoscaler.
- Rolling updates and rollbacks: Deploy a new version gradually, with automatic rollback if health checks fail.
- Service discovery and load balancing: Kubernetes assigns DNS names to services and distributes traffic across healthy pods.
- Secret and configuration management: Sensitive data (API keys, passwords) and configuration values can be injected into containers without baking them into the image.
- Storage orchestration: Automatically mount storage systems — local disks, cloud volumes, network file systems — to containers that need them.
Getting Started: Practical Advice
Before standing up a full production cluster, use local tooling to learn the concepts without cloud costs:
- minikube — runs a single-node Kubernetes cluster inside a VM or container on your laptop. Ideal for development and experimentation.
- kind (Kubernetes IN Docker) — runs Kubernetes clusters using Docker containers as nodes. Fast to start and popular for CI pipelines.
- k3s — a lightweight, production-grade Kubernetes distribution suited to edge, IoT, and resource-constrained environments.
For production deployments on AWS, tools such as kops (Kubernetes Operations) and managed services such as Amazon EKS, Google GKE, or Azure AKS significantly reduce the operational overhead of managing the control plane yourself.
Further Reading
The official Kubernetes documentation is thorough and well-maintained. The interactive tutorial at kubernetes.io/docs/tutorials/kubernetes-basics walks you through deploying, scaling, and updating an application against a live cluster — all from the browser, no local setup required.
Once you are comfortable with the basics, explore the concepts reference at kubernetes.io/docs/concepts to understand the full object model and how the scheduler, controller manager, and kubelet interact.
Kubernetes has a steep-looking learning curve from the outside, but once the mental model clicks — declare what you want, let Kubernetes figure out how — the pieces fall into place quickly.