Kubernetes Explained Simply 2026 - Orchestration, Networking & K8s vs Docker Swarm

Once you have containers, you need something to run, scale and heal them automatically. That is Kubernetes - the industry-standard way to operate containerised apps at scale.

This page assumes you already know what an image and a container are. If not, start with Docker explained for beginners - Kubernetes runs containers, it does not build them.

What is Kubernetes?

Kubernetes (K8s) is a container orchestration platform that manages the deployment, scaling and availability of containerised applications across a cluster of machines.

Why DevOps uses Kubernetes

It provides high availability, automatic scaling, self-healing (restarting failed containers), and rolling updates with zero downtime.

The underlying idea is worth stating once, because it explains everything else: Kubernetes is a control loop. You declare the state you want - three replicas of this image - and a controller continuously compares that against reality and acts to close the gap. Kill a pod and one reappears, not because something detected a crash, but because the count no longer matched.

Core concepts

• Pod: the smallest unit - one or more containers running together.
• Deployment: manages how many pod replicas run and how they update.
• Service: a stable network endpoint that routes traffic to pods.
• Cluster: the set of machines (nodes) Kubernetes runs everything on.

What that looks like in YAML

A Deployment and a Service - between them, the minimum to get an application running and reachable inside a cluster.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: myapp:1.2.0
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 256Mi
          readinessProbe:
            httpGet:
              path: /healthz
              port: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 3000

Two fields there do more than beginners expect:

• The label selector. The Service finds pods by matching app: web, not by name or address. Labels are the entire routing mechanism - a typo in a label is the most common reason a Service returns nothing.
• The readiness probe. Without it, Kubernetes sends traffic to a pod the moment the container process starts, which is usually before the application can serve requests. That is why deploys that "should be zero downtime" produce a burst of errors.

Resource requests tell the scheduler how much to reserve; limits cap usage. Setting a memory limit and no request is a common misconfiguration - the scheduler then packs pods onto nodes that cannot actually feed them.

Debugging a pod that will not start

This sequence handles most cases, in this order:

kubectl get pods
kubectl describe pod web-7d9f8b-xk2p1
kubectl logs web-7d9f8b-xk2p1
kubectl logs web-7d9f8b-xk2p1 --previous

get gives the status, and the status name is usually the answer. ImagePullBackOff means the cluster cannot fetch the image - wrong tag, or missing registry credentials. CrashLoopBackOff means the container starts and exits repeatedly, so read the logs, and use --previous because the current attempt may not have logged anything yet. Pending usually means no node has enough free resources to satisfy the requests, which describe will say at the bottom under Events.

Reading the Events section of describe before anything else will save you more time than any other Kubernetes habit.

How Kubernetes networking works (basics)

Every pod gets its own IP, and pods can talk to each other directly within the cluster. Because pods come and go, you do not target them by IP - a Service gives a stable address and load-balances across the healthy pods behind it. An Ingress then exposes services to the outside world and routes external HTTP traffic by host/path. This is what lets apps scale and move without breaking connections.

Kubernetes vs Docker Swarm

Docker Swarm is simpler to set up and fine for small deployments, but Kubernetes is far more powerful - richer scaling, self-healing, a huge ecosystem, and support on every major cloud. The industry has standardised on Kubernetes, which is why it dominates job postings; Swarm is now a niche choice.

When not to use Kubernetes

Worth being able to say out loud in an interview, because it signals judgement rather than enthusiasm. A single application with modest traffic, run by a small team, does not need a cluster. A managed container service or even a couple of virtual machines behind a load balancer will be cheaper, easier to reason about and faster to debug at 2am.

Kubernetes earns its complexity when you have many services, several teams deploying independently, and real scaling or availability requirements. Adopting it before that mostly means someone now maintains a cluster instead of shipping features.

Industry usage

Startups and enterprises alike use Kubernetes to run containerised applications reliably at scale, which is why K8s skill is one of the biggest salary levers in DevOps.

For learning, a local cluster with kind or minikube is enough to cover everything on this page. Managed services - EKS, AKS and GKE - are what you will use at work, and they remove the hardest part, which is running the control plane yourself.