Cloud Native

What a Reddit Thread Taught Me About Teaching Kubernetes

Diagram of Kubernetes learning material as vertical strokes of depth with the horizontal bar of broad context missing
0

Six months ago, one of my engineers asked if I could help him understand Kubernetes. He was new to the tech and wanted to better understand it as his job entails building a product in the Kubernetes ecosystem using Kubernetes-based development systems.

He tried some training material on his own but felt overwhelmed due to the immediate level of detail and depth. He felt the only option to learn was the firehose. But he just wanted it explained to him through a manageable trickle, a down-to-earth pace, in an informal manner, with only the concepts and level of detail that mattered, and none that didn’t.

So, instead of forcing him to dive deep, I wrote down what I thought he needed to learn, in the order that makes sense for a newcomer. And I decided to share it. I posted ‘KubeSchool’, as I dubbed it, to the r/kubernetes subreddit, and they loved it: 75,000 views, hundreds of positive comments, so so many thumbs up, and people asking me to extend it to other topics.

This enthusiastic reaction from the community sparked a thought: people that are learning need to be given an overview at a high-level altitude first, so they can build the mental scaffolding that can then be used to dive deeper into various topics. Without that scaffolding, the level of detail is overwhelming, and the learner gets lost, just like my coworker.

Building a mental model like that requires careful thought and planning what to do first, and what to keep from the reader for now. It’s a step-by-step process of building that scaffolding, starting from the concepts that are crucial for all other understanding, and going from there, topic by topic, filling in the gaps. Wide at first, more technical depth later.

Generalist first, expert later

There’s a name for this sort of knowledge: the T-shaped expertise model, originally used to describe designers and consultants who could hold their own across an entire domain but had real depth in only one or two areas. The horizontal bar of the T is breadth: enough working knowledge to understand the breadth of a landscape, knowing what exists and how pieces relate, and knowing enough to be able to dive deeper when needed.

The vertical stroke is depth: deep expertise, but only in one or two areas.

Hand-drawn T-shape: a horizontal arrow labeled broad context across several columns and a vertical arrow labeled deep expertise

Most Kubernetes learning material feels lopsided; only vertical strokes, without the context and scaffolding of the horizontal bar. Certification objectives, deep-dive docs, and reference architectures are all, implicitly, asking a newcomer to become an expert in the whole system before they’ve had a chance to become merely competent across a wider landscape.

I think that’s an unreasonable ask, and not what most people need.

An application developer doesn’t need to be a networking expert to ship a service. An IT generalist migrating off virtualization doesn’t need to understand every admission controller to run a reliable cluster. They need the top of the T: a working mental model wide enough to orient themselves in the cloud-native landscape, with the option to grow a stroke of real depth in the one or two areas their job requires them to.

That’s what the scaffolding is for.

Learn horizontally before going vertical.

For Kubernetes specifically, there’s plenty of material out there. Most of it is comprehensive, technically accurate, and written by people who clearly know what they’re doing. The problem is that most of it dives deep from the get-go and lacks the careful step-by-step building of the horizontal scaffolding.

Diagram of Kubernetes learning material as vertical strokes of depth with the horizontal bar of broad context missing

What’s missing is altitude control. Official docs are reference material, organized by feature, not by the order a newcomer needs to encounter ideas to build that scaffolding. Certification paths are organized by exam objective, which optimizes for passing a test, not for building a working mental model. And “top resources” listicles solve discovery, not comprehension — they hand someone forty links and call it a curriculum.

The result is a strange kind of abundance-scarcity: people drowning in knowledge while still not being able to see the full picture.

What resonated, and why

Looking back at which parts of that original write-up people quoted back to me in the comments, three things stood out.

First, permission to be overwhelmed. So many people replied with a sigh of relief, because someone acknowledged the usual learning curve was too steep, instead of implying everyone should ‘just’ learn Kubernetes the hard way.

Second, sequencing matters more than depth. People don’t want everything explained all at once. They need to learn in a certain order, building on what came before, and explicitly leaving out the rest for later. The T-shaped model works well to build the scaffolding before diving deep.

Which brings me to the third, map knowledge to what they already know. Learning new tech doesn’t happen in a vacuum and works best if new knowledge is mapped to existing (older) concepts. A scaffolding approach can be specifically structured to take advantage of an existing mental model of comparable or older technology to increase the pace of understanding.

Scaffolding before depth

Now, none of this argues against what’s already out there: formal or third-party training, books, documentation, certification. Those still do the job they were built for: depth, rigor, and a shared baseline across an organization.

But the reactions on Reddit I got proved that people are interested in informal, practitioner-written explanations that build that scaffolding. To leave out technical depth and detail in favor of context, scaffolding and broad knowledge. To map new knowledge to existing mental models.

If there’s a lesson for anyone building learning material in cloud native right now, it’s this: altitude is a feature, and breadth isn’t a lesser form of expertise — it’s the shape most people need first. The vertical strokes can wait.

That’s also, not coincidentally, the shape of a good conference talk. If you’re at KubeCon this November, come join me in my session ‘KubeSchool – Learn the Easiest Way Possible’ on November 10, 11:00AM.

KubeCon + CloudNativeCon is taking place in Salt Lake City from November 9 to 12. Register Now!

AI made the war room faster. It didn’t make the outage shorter.

Previous article