Lesson one ended with a list of five things you would have to build to run containers seriously. Lesson two handed you the second item on that list and made you do it by hand.
The thing that does all five already exists, and it is called Kubernetes. The loop you just ran by hand sits in the middle of it.
One pool, split in two
A clusterClusterA set of machines that Kubernetes manages as one pool of compute. is a set of machines managed as one pool of compute. You stop addressing individual servers and start addressing the pool: you ask for ten copies, and you do not say where they go.
The pool splits in two, and that split explains most of what follows.
The control planeControl planeThe components that decide what should run and where. is where decisions happen. It holds what you asked for, runs the loops that compare that against what exists, and works out what should change. It does not run your containers.
A nodeNodeA single machine, virtual or physical, that runs workloads. is a machine that does. Something on every node takes instructions about what should be running locally, makes that true, and reports back what is actually happening.
Deciding on one side, doing on the other. Almost everything else in this track sits on one side of that line or the other.
Where your five things went
You do not need these names yet. They are here so that the list you built in lesson one has somewhere to land:
| What you would have had to build | What does it here |
|---|---|
| a note of what should be running | etcd, on the control plane |
| something that checks the note and fixes gaps | a controller |
| a scheduler that places copies on machines with room | the scheduler |
| a rollout that goes gradually and can stop | another controller |
| a name that resolves to live copies | a Service, plus work on every node |
A controller here is simply a loop reading things, just like you did.
The last row is different. Deciding which copies are alive is a loop like the others, but it needs more machinery around it, so it gets its own lesson later.
Here is the whole thing on one map. You are not expected to remember any of these names yet. The point is that every one of them sits on one side of the line or the other, and that most of them are a loop you have already run.
Cluster
Control plane
decides what should happen
Nodes
run the containers
Pick any part of the cluster to see what it does.
-
API server control plane
The only door. Every read and every change goes through it, whether it comes from you, from a controller, or from a node. Nothing in the cluster talks to the store directly.
Covered properly in a future lesson.
-
etcd control plane
Holds what you asked for, and it is the only thing that does. Lose every other part of the cluster and you can rebuild; lose this and the cluster has forgotten what it was supposed to be.
Covered properly in a future lesson.
-
Controllers control plane
The job you did by hand. Each one watches one kind of thing, compares what was asked for against what exists, and changes what it has to. There are many of them and they do not coordinate.
Covered properly in a future lesson.
-
Scheduler control plane
Decides which node a new copy goes on, by looking at what room is left and what the copy said it needs. It only decides. Something on the node does the starting.
Covered properly in a future lesson.
-
kubelet on every node
The thing on every node that takes the list of what should be running here, makes it true, and reports back what is actually happening. It is the other half of every loop in the control plane.
Covered properly in a future lesson.
-
Container runtime on every node
Starts and stops the containers, pulls the images. This is the part that was already there in lesson one, doing what `docker run` did.
Covered properly in a future lesson.
-
Networking on every node
Gives every copy an address, and makes one stable name resolve to whichever copies are alive right now. Decided centrally, made real on every node, which is why it takes a phase of its own.
Covered properly in a future lesson.
What the split explains
The division between deciding and doing is by design. It basically defines how the system handles failures.
If the control plane goes down, your containers keep running. Nothing is deciding anything new, nothing new can be asked for, and nothing is repairing anything, but the nodes carry on with the existing processes. A cluster with a broken control plane is not the same thing as a cluster with a broken application.
If a node goes down, what you asked for survives, because it was never kept there. The different loops will see a gap between expectation and reality, and place the missing copies somewhere appropriate.
And the coolest part about it, is that it’s simply a consequence of the design.
Where this goes next
The next phase will talk about the control plane: what you write down, where it goes, what remembers it, the loops that read it, and why an event is still not an instruction. The things that actually run your containers come back in phase three.