Kubernetes for Dummies: It's Just Objects All the Way Down

Kubernetes has a reputation: too big, too complex, too many YAML files. I remember staring at my first cluster thinking I'd never hold it all in my head.

Then the model clicked. And the model is embarrassingly simple.

Kubernetes is two things:

  1. A database full of objects.
  2. Robots that make reality match the database.

That's it. Everything else is detail.

You never command Kubernetes

This is the part nobody tells beginners, and it's the part that matters most.

You never tell Kubernetes to do something. You tell it what you want, by writing an object into its database. Then you walk away.

An object is just a record. A wish, written down. "I want three copies of my app running." You submit that wish. You don't start the app. You don't pick a server. You describe the end state and stop.

Compare that to every tool you've used before. A shell script is a list of commands: do this, then this, then this. If step four fails at 3am, the script is done and so is your app. Kubernetes doesn't work like that. There are no steps. There's only the wish, sitting in the database, forever.

The robots

So who does the actual work? Controllers. I think of them as small, obsessive robots.

Each robot has one job and runs one loop, forever:

  1. Read the wish. ("Three copies should exist.")
  2. Look at reality. ("Two are running.")
  3. Fix the difference. (Start one more.)
  4. Go back to step 1.

This loop is called the reconciliation loop, and it is the single most important idea in Kubernetes. Not pods. Not YAML. This loop.

Your home thermostat is a reconciliation loop. You set 21 degrees. It measures the room. Too cold, heat on. Warm enough, heat off. It never finishes. It never celebrates. It just keeps comparing wish to reality and nudging.

Now the 3am story again. A server dies and takes your app with it. No pager goes off. No script re-runs. A robot simply notices, on its next loop, that reality says two and the wish says three. So it starts a third. That's Kubernetes' famous "self-healing," and it's not magic. It's a thermostat.

Delete a pod by hand and watch it come back seconds later. People find this spooky at first. It's just the loop: you changed reality, but you didn't change the wish.

Never-ending objects, each with one tiny job

Here's what overwhelmed me early on: the sheer number of object types. Pod, Deployment, ReplicaSet, Service, Ingress, ConfigMap, Secret, Namespace, and on and on. It feels infinite. It basically is.

The relief comes when you notice each object has one small, boring purpose:

  • A Pod is a running copy of your app. The unit of "actually alive."
  • A Deployment is the wish "keep N copies of this pod running, and replace them gently when I ship a new version."
  • A Service is a stable phone number. Pods die and get new addresses constantly; the Service is the one number that always reaches whoever's alive.
  • An Ingress is the front door: it routes traffic from the outside world to a Service.
  • A ConfigMap holds settings. A Secret holds passwords. Pods reference them instead of hard-coding values.

None of these is complicated alone. A Deployment doesn't route traffic. A Service doesn't run anything. Small objects, small jobs.

How they relate: loose references, not ownership

The objects form chains, but they connect in the loosest possible way: mostly by labels, which are just sticky notes.

A Service doesn't contain a list of pods. It says "I point at anything labeled app: shop." Pods carry the label. That's the whole relationship. New pod appears with the right sticky note, the Service starts routing to it. Pod dies, it drops out. Nobody updates a registry, because there is no registry. Just labels and loops.

The chains look like this:

  • You write a Deployment. Its robot creates a ReplicaSet (the wish "exactly N of this exact pod"). The ReplicaSet's robot creates the Pods.
  • A Service finds those pods by label and gives them one stable address.
  • An Ingress points at the Service and opens it to the world.

Notice something: even the objects create objects. You wish for a Deployment, and robots write two more layers of wishes on your behalf. Objects all the way down.

How I actually learned it

I stopped memorizing kubectl commands. Commands are surface. Instead, every time I met a new object type, I asked the same three questions:

  1. What wish does this object express? One sentence. If I can't say it in one sentence, I don't understand it yet.
  2. What does it point to, and what points to it? Labels, names, references. Draw the arrows.
  3. Which robot watches it, and what does that robot do when reality drifts?

Three questions, every object, no exceptions. Ingress? Wish: route this hostname to that Service. Points to: a Service by name. Robot: the ingress controller, which reconfigures the actual load balancer. Done. Next object.

This works because Kubernetes has exactly one design pattern, reused everywhere. Learn the pattern once and every new object is fifteen minutes instead of a weekend.

Why "never-ending" is the point

The object list isn't just long. It's deliberately open. Kubernetes lets anyone define new object types (called Custom Resource Definitions, or CRDs) and write new robots to watch them.

That means the pattern extends beyond Kubernetes itself. Want a "PostgresDatabase" object, so developers can wish for a database the same way they wish for three pods? You can build that: define the object, write the robot. This is exactly how the platform tooling in my previous post works under the hood. Crossplane, Kratix, all of it: new objects, new robots, same loop.

Which is why the mental model matters more than any command. Kubernetes isn't a container tool that got out of hand. It's a general machine for turning written-down wishes into reality, and containers were just the first wish.

The whole post in four lines

  • Kubernetes is a database of objects plus robots that make reality match it.
  • You never command it. You write wishes and walk away.
  • Every robot runs the same never-ending loop: read the wish, check reality, fix the gap.
  • Every object has one tiny job, and they connect with sticky notes.

Hold onto that, and the YAML is just paperwork.