Hi 👋. I'm Hung Anh.
In production, our system always needs to be deployed across many servers to ensure HA and keep uptime as high as possible even when the underlying infrastructure goes down. On top of that, the system also has to scale automatically when traffic spikes during peak periods. Kubernetes has long been the standard tool for this — but it's hard to truly understand Kubernetes without starting from real use cases, the core concepts, and the pain points of the infrastructure approaches that came before it.
In this series, let's take a closer look at Kubernetes by going from Linux basics all the way to the concepts, the architecture, and each component of Kubernetes. Each article will solve the problems the previous one left behind. I'll try to keep each article as clear and easy to follow as I can.
Start from the first one and read in order — it'll make a lot more sense that way. Hope you find plenty of it useful.
Happy reading! 🍵
Before getting anywhere near Kubernetes itself, the story has to start with the foundation of everything in this series: the Linux kernel. If you've never really sat down and thought about what a kernel does, what a driver is, or what "sandbox" actually means in Linux, this article is for you.
What does a physical server actually look like, and why can't we just keep deploying more onto the same one?
How does the Virtual Machine solve the physical server's "one machine, one environment" problem, and what does this approach cost you?
The container solves the Virtual Machine's weight and boot-time problem by dropping the private kernel every VM has to carry around.
What actually makes up a Kubernetes cluster? The control plane decides what runs where, the nodes run it, and the addons fill in the rest.
