Why orchestration?
Ignition · Ask the cluster to fly
Launchpad can run Apollo Airlines on one machine. A person starts containers, checks logs, and restarts a process when it fails. That arrangement is useful, but it puts the person at the centre of every recovery. Now imagine booking is needed on several machines, one machine goes away, and a passenger request still arrives. We need a durable description of what should be running and a group of actors that continuously work toward it.
That is the problem Kubernetes orchestration addresses.
Desired state is a promise we can inspect
Instead of telling a machine “start booking now,” you describe a desired result: Apollo should have a chosen number of booking copies with a particular container template. Kubernetes stores that request in its API. Controllers observe the stored request and the current cluster, then take small actions to reduce the difference between them.
This model is called reconciliation. It is a loop, not a single deployment moment. A controller may create a Pod, later notice that it disappeared, and create another one because the desired count still says it should exist.
Diagram CL-01 — reconciliation compares a recorded request with observed state and takes another small step toward the request.
What orchestration changes
A controller can create a replacement Pod after the old one is deleted. A scheduler can choose a suitable node. A kubelet can start and monitor containers on its node. Those capabilities give the cluster a way to restore processes without an operator typing the same restart command each time.
They do not make every application concern disappear. Kubernetes can recreate a booking Pod but cannot recreate a reservation stored only in its memory. It can send traffic toward a ready Pod but cannot guarantee every downstream service will work. It can start a new image but cannot undo an external side effect from an old one. The rest of Apollo’s journey names these boundaries instead of hiding them behind the word “self-healing.”
A useful way to read every mechanism
When you meet a new Kubernetes object, ask five questions:
- What application problem does this object help describe?
- What part of the object records the desired state?
- Which running actor observes that object or condition?
- What action can that actor take?
- What evidence says the result is useful, and what does the mechanism not guarantee?
For the missing booking Pod, the desired replica count is the intent; a controller observes the gap; it creates a replacement; and a passenger booking is stronger evidence than merely seeing a new Pod name.
What comes next
The next chapter introduces the API objects that hold these requests. Then we will meet the components that turn an accepted object into a running Pod. Only after those concepts are established does the Ignition lab ask you to observe them in a local cluster.