TM-001: The Evolution of the App¶

Welcome to Zentari Labs, Cohort 4.

Before you deploy your first container, we need to ensure you understand the foundation. Kubernetes isn’t just a buzzword, it’s the orchestrator for the modern cloud, and to navigate it effectively, you’ll need to know not just how it works, but how we use it here at Zentari.

This module will cover:

How we got here: from physical servers to containers

The Travel Analogy: From Ownership to Orchestration¶

Let’s say you need to get to different cities regularly.
Here’s how your transportation, and application hosting has evolved.

Stage 1: Owning a Car (Physical Servers)¶

You buy your own car.
You're responsible for the cost, maintenance, fuel, repairs, and parking.
It’s always available, but expensive and often underused.

This is how we used to run applications:
One server per app. You owned, and managed it 24/7, even if it wasn’t doing much.

Stage 2: Leasing a Car (Virtual Machines)¶

You stop owning and start leasing a car when you need it.
You still drive it yourself, but the long term upkeep isn’t your concern.
It’s more flexible, and the same provider can lease multiple cars to different people.

This is like virtual machines:
Shared physical resources, isolated environments.

Stage 3: Taking the Railway (Containers + Kubernetes)¶

Now you use the railway system.
No ownership, no leases. You just show up, tap your card, and ride.
The train is ready, and everything you need is built in.
You don’t worry about infrastructure, just where you’re going.

That’s what containers bring:
Lightweight, portable environments that move easily across systems.

But trains alone aren’t enough…¶

Imagine thousands of people moving between cities every hour.

Who manages the schedules?
Who reroutes trains when tracks fail?
Who prevents overcrowding?

That’s what Kubernetes does.
It’s the railway system that is orchestrating thousands of apps (trains) across a system, automatically.

An image showing a car, lease, and railway

Let's revisit our railway analogy to understand the difference between containers and pods.

🚆 Containers = Train Cars¶

Containers are like individual train cars.
Each one carries passengers (your app) and has everything it needs onboard such as seats, lights, AC, power.

But:

A train car alone doesn't move
It doesn't know where to go
It needs to be assigned to a route and managed

🎫 Pods = Scheduled Train Assignments¶

A pod is like the logical train assignment that Kubernetes manages.
It wraps the container in everything it needs to run in the system:

A destination (which node)
A ticket (IP address and identity)
A platform assignment (scheduling info)
Luggage (volume mounts)
Instructions on how to travel with others (networking, probes)

Kubernetes never runs a container directly, it always wraps it in a pod.
Even if it's a single container, the pod gives it context inside the cluster.

"Here’s your train car... but now it’s on the schedule, with a route, a conductor, and a place to be."

✅ Summary¶

An image showing the difference between a container and a pod

But… as with any successful system, scale becomes the challenge. What happens when you need to manage hundreds or thousands of containers?

That we will discuss in the next Training Module.

Nova Knowledge Check¶

Pre-Case Readiness Verification

Before you move on, make sure you’ve absorbed the essentials.
Answer the following questions based on what you just read:

To continue your journey:

👉 Enter CASE 001 – The Scale Factor