🛫 Meet Apollo Airlines
Imagine a passenger has found a flight and presses Book. They expect a confirmation and a reservation they can find again later. Apollo Airlines has several pieces of work to coordinate before it can deliver that simple result.
The frontend gives the passenger a way to interact with the airline. Behind the booking action, the booking service calls identity and flight, records the reservation in its database, and asks notification to handle confirmation work. This simplified picture follows that action; later, Guidance will explain the network routes connecting these pieces.
Booking sits at the meeting point of several dependencies. If its process is running but it cannot reach flight or its database, the passenger may still be unable to book. That distinction will return in Launchpad, Flight Control, and Mission Operations. (Diagram OR-02: a simplified passenger workflow.)
The same airline, new questions
In Launchpad, we ask how to run these programs together. At Liftoff, we ask what happens when a Pod disappears. Mission Data follows the reservation through a database Pod replacement. Mission Operations follows the clues when a booking slows down. You will already know the passenger’s goal when each new Kubernetes mechanism arrives.
🗺️ How Apollo Airlines Evolves (Macro-Architecture Map)
Rather than learning isolated Kubernetes features in the abstract, you will watch Apollo Airlines progressively evolve from a single-machine script into an enterprise-grade, observable, resilient cloud platform:
Stage-by-Stage Architecture Progression
| Stage | Infrastructure Boundary | Key Architectural Leap |
|---|---|---|
| 0. Launchpad | Single Docker Host | 10 containers on a local Docker bridge; learns process vs image vs container. |
| 0.5. Ignition | 3-Node kind Cluster | Control plane + 2 worker nodes; observes kubelet, API server, and bare Pod lifecycle. |
| 1. Liftoff | Single Namespace (apollo-airlines) | Controllers replace bare Pods; Deployments, ReplicaSets, Services, ConfigMaps, Secrets, tokenless ServiceAccounts, schema Jobs. |
| 2. Guidance | Multi-Namespace (apps + ui) | Production namespace boundary; eliminates NodePorts using MetalLB Layer 2 VIP and Envoy Gateway API HTTPRoutes. |
| 3. Mission Data | Dynamic Storage (local-path) | Replaces ephemeral emptyDir with StatefulSets, headless Services, and persistent PVCs that survive Pod deletion. |
| 4. Flight Control | Node Scheduling & Reliability | Zero-downtime rolling updates with preStop connection draining, multi-tier probes, and PodDisruptionBudgets. |
| 5. Payload | Automated GitOps | Consolidates raw YAML into parameterized Helm charts; deploys automated GitOps reconciliation with Argo CD. |
| 6. Operations | Dedicated apollo-observability | Correlates bookings across Prometheus metrics, Loki log streams, and OpenTelemetry/Tempo distributed traces. |
| 7. Scaling | Elastic Autoscaling | Combines Redis Cache-Aside query caching with HPA autoscaling, VPA recommendations, and topology-spread scheduling. |
You don’t need to memorize the whole application now. Keep one question in mind: can the passenger complete their booking, and can we explain why?