This 6-Hour Kubernetes Course Explains Why Everything Evolved

Here's what gets me about most tech courses: they start with the solution and expect you to care about the problem later. You're three hours into configuring YAML files before anyone bothers explaining why this particular nightmare exists.

FreeCodeCamp's new six-hour Kubernetes course—created by Saiyam Pathak from Kubesimplify—does something different. It starts with a question that actually matters: how did we get here?

And by "here," I mean a world where deploying a login page involves orchestrating containers across clusters with monitoring dashboards and gateway APIs. The course spends its first half-hour on computing history, which sounds boring until you realize it's the only way the rest makes sense.

The Actual Problem: Shipping Code Is Still Hard

Pathak frames the entire history of computing around one constant: enterprises need to ship software to users. That was true in the 1970s, it's true now, and it'll be true when we're deploying apps to Mars rovers.

"Always remember right now as well since we are going through a brief history. Now also the main aim is to deploy the application. Main aim is to deploy the application," he says, and he keeps returning to this throughline. Every technology that follows—virtualization, cloud computing, containers, Kubernetes—exists because the previous solution made shipping software harder than it needed to be.

Start with the old model: enterprises ordered physical hardware, waited months for delivery, hired network engineers to rack it, installed operating systems, configured dependencies, and finally—finally—deployed their Java application. Want to test a new version? Build another entire environment. Need staging and production? Double everything. Have a second application? Buy more hardware.

The resource waste was absurd. One server running at 20% capacity, another at 30%, a third at 40%. The rest just... sitting there, burning electricity and depreciating.

Why Virtualization Wasn't Enough

Virtualization solved the waste problem by slicing physical hardware into VMs. Instead of one server per application, you could run multiple VMs on the same metal, each with its own OS. VMware dominated this era because it did this well.

But virtualization created its own friction. Startups couldn't afford the upfront cost of server racks just to test an MVP. They needed infrastructure now, not in six months after hardware procurement.

Cloud providers—AWS, GCP, Azure, and smaller players like Exoscale—abstracted away data centers entirely. "These cloud providers have built a UI, CLI, all the interfaces through which this user can communicate and can create a VM... on demand," Pathak explains. Black Friday sale incoming? Spin up more instances. Traffic dies down? Scale back. Pay only for what you use.

Except cloud costs ballooned. The egress fees, the ingress fees, the surprise bills. Some companies are now reverse-migrating back to bare metal because cloud providers optimized for convenience, not economy.

The Monolith Problem That Containers Solved

Here's where the architecture shift enters. Traditional applications were monoliths—everything written in one language, deployed as one unit. Change the login flow? Rebuild the entire application. One feature breaks? Roll back everything.

Microservices split applications into independent pieces. Login is one service, checkout is another, the dashboard is a third. Each can be written in different languages (Node.js frontend, Golang backend, Python for AI), deployed independently, and scaled based on actual load.

Containers make this practical. They package code with its dependencies into lightweight, isolated units that start fast and run as processes on the host. Unlike VMs—which are slices of physical hardware—containers are slices of the operating system, using Linux namespaces, cgroups, and union file systems to create isolation without the overhead.

"Containers are the slice of the operating system to provide you with the look and feel of the operating system which uses a container runtime," Pathak says. Docker streamlined this entire ecosystem starting around 2013, making containers accessible to developers who didn't want to manually configure Linux namespaces.

The result: instead of one massive application, you have hundreds of small services talking to each other. Which creates its own problem—how do you manage hundreds of containers across multiple servers? Enter Kubernetes.

What This Course Actually Covers

The course is structured around deploying a real microservices application end-to-end. After the computing history primer, Pathak walks through:

• Self-managed versus managed Kubernetes clusters (using Exoscale's SKS as the managed example)
• Core architecture: how the scheduler, controller manager, and API server actually work
• The interfaces that keep Kubernetes flexible: CRI for runtimes, CNI for networking, CSI for storage
• Practical components: Pods, Deployments, StatefulSets, DaemonSets, Services
• Configuration management with ConfigMaps and Secrets
• Role-Based Access Control (RBAC) for security
• Kubernetes Volumes and CloudNativePG for stateful workloads
• The Gateway API for modern ingress
• Monitoring with Prometheus and Grafana

The final two hours bring everything together in a live demo of the complete application stack, plus basic monitoring setup. All the code and YAML manifests are available on GitHub.

The Tension Nobody Mentions

What's interesting is what Pathak doesn't say: Kubernetes is overkill for most projects.

He mentions that "there are a lot of scenarios where monolith is still relevant" but doesn't dig into when you should just deploy a single server and call it done. The course teaches you the orchestration layer for managing hundreds of microservices without really questioning whether you need hundreds of microservices.

This isn't a critique of the course—it's teaching Kubernetes, not debating whether you should use Kubernetes. But it surfaces a broader industry tension: we've built incredibly sophisticated tooling for problems that many teams don't actually have yet.

The course assumes you already know you need Kubernetes. It's teaching you the how, not adjudicating the whether. For someone joining a team that's already committed to this architecture, that's exactly right. For someone evaluating whether to introduce this complexity, the historical context actually makes the decision harder—you can see each technology solving real problems while creating new ones.

Who This Is For

Pathak's previous Kubernetes workshop got 1.7 million views, which suggests there's massive appetite for this content. This new course uses Kubernetes 1.33 and covers features that didn't exist in earlier versions, particularly the Gateway API.

The prerequisite is container knowledge—Pathak gives you enough primer to follow along but explicitly says "this course is not about containers at all." If you're still fuzzy on how Docker images become running containers, start there.

Six hours is a real commitment, but the structure lets you jump to specific components. Need to understand StatefulSets for work tomorrow? There's a timestamp. Want to see how RBAC actually works? Skip ahead. The course is modular enough to serve as reference material, not just a linear tutorial.

The value proposition is clear: learn enough Kubernetes to deploy real applications in production environments, with monitoring and security and all the pieces enterprises actually need. Not toy examples, not localhost demos—production-grade deployments.

Whether you should deploy production-grade Kubernetes is a question the course politely declines to answer. But if you're already going down that path, this is how you learn to do it properly.

— Zara Chen, Tech & Politics Correspondent