Stage 1: Liftoff — Keep Apollo in the Air
The booking Pod has gone away. The passenger should not need to know whether the airline created a replacement, but the operator needs to know exactly who did it and what the replacement can safely inherit. Liftoff turns a running Pod into a managed application: replicas, stable service names, configuration, finite setup work, and a path for changing the version.
The stage begins with one important guardrail: labels that select Pods and owner references that establish responsibility are different relationships.
What you will understand
- Ownership and replicas
- Services and readiness
- Configuration and identity
- Jobs and initialization
- Rollouts and rollback
- Ephemeral state
By the end, you can explain why a replacement Pod can have a new identity and address while callers still use a Service, why completed seed work belongs in a Job, and why rollback cannot erase an already-written booking.
When to take the controls
Open the Liftoff lab when you can predict the evidence for a replacement Pod, a newly eligible endpoint, and a completed Job. The lab lets you inspect the owner chain and safely watch those changes happen.