Kubernetes 101: The One Idea, Then the Nouns

Most introductions to Kubernetes start with a list of nouns — Pod, Deployment, Service, Ingress — and by the end you can recite them without being able to predict what the cluster will do. The nouns are the easy part. The idea underneath them is what makes Kubernetes behave the way it does, including the parts that seem perverse at first.

Here is that idea, and then the nouns, in an order that makes them stick.

Who this is for

You can recite Pod, Deployment and Service and still cannot predict what the cluster will do. You do not need to have run one. The nouns are the easy part and they come second here.

The one idea

You do not tell Kubernetes what to do. You tell it what you want to be true, and a control loop spends the rest of its life making reality match.

That is the whole model. You write "three replicas of this image", and a controller notices there are two, and starts one. You delete a pod by hand and something puts it back — not because it is being stubborn, but because you never told it to stop wanting three.

This is why Kubernetes uses desired state rather than commands, and it explains a lot of behaviour that is otherwise baffling:

• Deleting a pod that a Deployment owns does nothing permanent. The controller recreates it. A bare Pod you created yourself has no controller, so it is simply gone.
• To actually stop something, you change what you asked for — scale to zero, or delete the Deployment.
• A "failed deploy" often is not failing. It is trying, repeatedly, and telling you so.
• Nothing is ever "done". The loop keeps running.

Hold that, and the rest follows.

Pods

A Pod is the smallest thing Kubernetes schedules. It wraps one or more containers that share an IP address and can share storage.

apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    app: web
spec:
  containers:
    - name: web
      image: nginx:1.30-alpine
      ports:
        - containerPort: 80

The thing to internalise immediately: you almost never create a Pod directly, and pods are ephemeral. They get rescheduled, replaced, moved between nodes. A pod has no identity worth attaching to, no stable IP, and nothing written to its own filesystem outlives it. Only what goes to a persistent volume does.

Coming from servers, this is the biggest adjustment. A server is a place. A pod is a process that happens to be running somewhere at the moment.

Deployments

A Deployment is how you say "I want N of these, and here is how to replace them when the image changes".

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web          # which pods this Deployment owns
  template:
    metadata:
      labels:
        app: web        # the labels the pods will carry
    spec:
      containers:
        - name: web
          image: nginx:1.30-alpine
          ports:
            - containerPort: 80

Note the two label blocks. selector.matchLabels is what the Deployment claims; template.metadata.labels is what the pods it creates actually carry. They have to agree, and the distinction between "labels on the Deployment object" and "labels on the pods" causes a specific, common failure further down this page.

When you change the image, the Deployment does not edit the running pods. It creates new ones and removes old ones gradually, which is what a rolling update is.

Services

Pods come and go and their IPs change, so nothing can usefully address a pod directly. A Service gives you a stable name and address in front of a set of pods.

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web            # must match the POD labels, not the Deployment's
  ports:
    - port: 80          # what callers connect to
      targetPort: 80    # where it forwards on the pod

A Service selects pods by label and maintains the list of their addresses. Two things must be true for a pod to be in that list: it matches the selector, and it is Ready.

This is where a classic early failure lives. If the selector is written against the Deployment's own labels rather than the pod template's, it matches nothing, the Service exists, DNS resolves, and every connection goes nowhere with no error anywhere. That failure has its own page: Service has no endpoints.

What you will actually meet first

Nobody's first week is spent admiring the object model. It is spent on these:

CrashLoopBackOff — the container starts, exits, and Kubernetes retries with increasing delay. The backoff is the loop being polite, not the error.

ImagePullBackOff — it cannot fetch the image. Check the image name and tag, then the registry credentials, then the network.

Pod stuck in Pending — either no node has accepted it yet, or it has a node and is still pulling its images. In the first case there is no container and no logs; the scheduler records why, per node, and that message is the diagnosis.

OOMKilled — the container exceeded its memory limit and was killed outright. Exit code 137, which is 128 + 9, signal 9, SIGKILL.

If you learn to read those four, you can operate a cluster long before you understand all of it.

The two settings that decide most behaviour

Requests and limits. A request is a reservation the scheduler honours; a limit is a ceiling the kernel enforces. They do different jobs, so set each deliberately: requests equal to limits is what gives a pod the Guaranteed QoS class, and a limit set without a request is silently copied into the request. requests vs limits covers what each controls, and why a cluster can be full at 10% utilisation covers what happens when everyone rounds their requests up.

Readiness and liveness probes. Readiness decides whether a pod receives traffic; liveness decides whether it gets restarted. Confusing them produces either a pod that is killed for being slow to start or one that receives traffic before it can serve it. readiness vs liveness is the distinction.

Getting a feel for the loop

Two commands teach the model faster than any diagram.

# Watch the controller work. Delete a pod in another terminal and see what happens.
kubectl get pods -w

# Ask why something is the way it is. The events at the bottom are the answer
# to almost every "why is this not working" question.
kubectl describe pod <pod>

kubectl describe is the single most useful command in Kubernetes and it is chronically underused by people new to it. The Events section is the cluster telling you, in plain language, what it tried and what happened.

If you are starting in 2026

Added 1 November 2026. Three things older tutorials will not tell you:

• Ingress still works, but it is finished. The Kubernetes documentation calls the Ingress API frozen: generally available, with no plans for removal, and no new features. New work goes into Gateway API, which is installed separately as CRDs plus a controller.
• The ingress-nginx controller was retired on 24 March 2026. Existing installs keep working but get no more security fixes, so do not choose it for a new cluster.
• Nodes need cgroup v2. From Kubernetes 1.35 the kubelet refuses to start on a cgroup v1 host unless told otherwise. stat -fc %T /sys/fs/cgroup/ prints cgroup2fs on a node that is ready.

The differences between the two routing APIs are on Ingress vs Gateway API, and what breaks between 1.33 and 1.37 is on the Kubernetes upgrade checklist.

What to skip for now

Kubernetes has an enormous surface and most of it is not load-bearing for a beginner. You can defer StatefulSets, operators and custom resources, network policies, service meshes, and most of the storage model until you have a reason.

What you cannot defer: the control loop, labels and selectors, and reading events. Everything else is built on those three.