Why the right question isn't "where do I start with Kubernetes", but "what problem am I actually solving".
The claim that tends to bother people
Every time someone asks me "where do I start to become a Platform Engineer", the answer they expect is "Kubernetes". The answer I give is: no. Kubernetes is the tool you use once you already know what you're trying to solve. Platform Engineering is about the problem, not about the orchestrator.
What actually separates someone who "knows Kubernetes" from someone doing Platform Engineering
After years running and evolving Kubernetes platforms in production — with hundreds of workloads and thousands of pods running in a regulated corporate environment — the difference I see in practice isn't in kubectl. It's in three questions most tutorials never make you ask:
- Who is your platform's customer? It's not the cluster. It's the development team that needs to ship without pinging you every time. If you can't name who uses what you're building, you're operating infrastructure, not building a platform.
- What happens when something breaks at 3am? A tested rollback, a defined RTO, a clear incident owner — that's a design decision made long before any YAML manifest exists. A platform that wasn't designed to fail well, fails badly.
- How do you measure whether the platform is helping or getting in the way? If the answer is "I don't know", you have a cluster, not a platform. Capacity planning, adoption metrics, reduced cross-team rework — that's what turns operations into an internal product.
Where Linux comes in
This is the connection the "Linux from Zero" series has been building since the first post: every abstraction Kubernetes gives you — pods, namespaces, resource limits, network policies — is an elegant repackaging of concepts that already exist in plain Linux: processes, kernel namespaces, cgroups, iptables/nftables. Once you understand the process before the pod, the kernel namespace before the Kubernetes namespace, you stop treating the cluster as a magic black box and start debugging like someone who understands the engine, not just the dashboard.
It's not a coincidence that the worst production incidents I've had to solve had their root cause one layer below Kubernetes — disk I/O, DNS, kernel limits — not in the orchestrator itself. Someone who only knows how to operate Kubernetes is blind exactly where the problem lives.
The path I advocate for (and the one this series follows)
Linux → processes → networking → containers → Docker → containerd → Kubernetes → observability → SRE → Platform Engineering → architecture.
That order isn't arbitrary. It's the order that gives you solid ground before it gives you altitude. Each layer explains the one above it. Jumping straight to "Kubernetes from zero" is like learning to fly a plane without understanding what makes it fly — you can memorize the controls, but you can't diagnose it when something goes off-script.
Where this takes you in practice
If you're trying to move from operations into Platform Engineering — or from Platform Engineer to Staff/Principal — the real test isn't "how many YAML manifests have you written". It's: can you explain, in one sentence, to a non-technical executive, why the platform you're building reduces risk and speeds up delivery? If yes, you're already thinking like a Platform Engineer. Kubernetes is just the tool you chose to execute that vision today — tomorrow it might be something else.
Full track (free, in Portuguese): github.com/roger-oliveira86/kubernetes-do-zero-ptbr
Agree or disagree? Curious to hear whether, in your experience too, the worst incidents also started "one layer below" Kubernetes.
Top comments (0)