#020 – Kubernetes for Humans Podcast with Kelsey Hightower

Kelsey Hightower
Independent Tech Voice / Author / Speaker (formerly Google Cloud)

Listen to the Podcast

Episode Overview

In this special episode of Kubernetes for Humans, host Itiel Shwartz sits down with Kelsey Hightower for a wide-ranging conversation on how Kubernetes won, where it's going, and what it takes for an infrastructure project to last. Kelsey traces his path from configuration management and Confd through CoreOS and into the early Kubernetes community, and explains why Kubernetes resonated with the infrastructure-as-code crowd in a way that Mesos and Docker Swarm never did. The two unpack the platform's API-first design, the role of CRDs and extensibility in fostering community, the parallels between Kubernetes and Linux, and why today's noisy ecosystem of operators and add-ons is a sign of healthy experimentation rather than decay. Kelsey closes with a characteristically grounded view of what comes next: most of the world still doesn't run Kubernetes, and the next platform shift is likely to come from people free to ignore backward compatibility entirely.

In this episode we discuss:

  • Kelsey's path from configuration management and Confd through CoreOS into early Kubernetes contributions
  • Why Kubernetes won over Mesos and Docker Swarm: API design, IaC compatibility, and meeting Docker users where they were
  • Whether Kubernetes should be more opinionated, and the 'grocery store vs. restaurant' framing of platforms
  • Kubernetes as a stable foundation (like Linux) with a fast-moving ecosystem of CRDs, operators, and add-ons on top
  • What comes after Kubernetes: mini-platforms, Lambda/Cloudflare Workers/Vercel, and the people free to ignore backward compatibility

Key Takeaways

1
Kubernetes succeeded because its API was a natural step up from Docker and resonated with the Terraform/Puppet infrastructure-as-code crowd, not because it was simpler than Mesos.
2
Successful infrastructure can't change much once adopted - Kubernetes is the freeway, and the trucks (workloads, tooling, abstractions) are what evolve on top of it.
3
Extensibility - CRDs, admission controllers, CNI, CRI - is the single biggest reason Kubernetes keeps absorbing new use cases instead of being forked or replaced.
4
Today's overwhelming ecosystem of operators and add-ons is the experimentation phase; expect consolidation around protocols (like Prometheus and Postgres-wire) rather than implementations.
5
The next platform shift likely won't come from inside the Kubernetes community - it will come from people free of backward-compatibility constraints, building on serverless, edge, or AI-native primitives.

Itiel Shwartz:  Hello, everyone, and welcome back to another special episode of Kubernetes for Humans. With me on the show, we have a guest that I’m not sure needs an introduction. Kelsey, maybe introduce yourself?

Kelsey Hightower:  I’ve been learning Kubernetes for a little while now, just hanging out with the folks in that space.

Itiel Shwartz:  I’m really happy and excited to have you here. I think a lot of the people I grew up learning Kubernetes with have followed the work you’ve done. It’s a great opportunity to have this conversation. Let’s start by talking about how you ended up in the Kubernetes space, especially from the early days. Could you give us a bit of background?

Kelsey Hightower:  I got into this space from the configuration management world. Like a lot of people doing DevOps in the 2010-2012 era, a lot of the work was about infrastructure as code. This was before HashiCorp was a thing and before Docker. When Docker came out, it showed there was a better way to handle infrastructure and automation. Docker brought new abstractions to the table. Around that time, Terraform also appeared. That’s when I started writing things in Go and created an open-source project called Confd, which was about rethinking configuration management. Eventually, I joined CoreOS, where I learned a lot about etcd, distributed systems, and of course, Kubernetes, which came out from Google while I was at CoreOS. At the time, Docker was king, and other bigger projects like Mesos were more popular. But contributing to Kubernetes made the light bulb go off for me. It was the perfect design even in those early days. Since then, I’ve been part of the community and helped make it a community-oriented project. Here we are almost ten years later, and it’s still going strong.

Itiel Shwartz:  It’s huge. It’s still going and growing every day as more companies migrate to Kubernetes. So why Kubernetes and not Mesos or Docker Swarm?

Kelsey Hightower:  Mesos was very popular, especially among larger companies like Apple. But Kubernetes resonated with people because it was a step up from Docker. Docker met people where they were, which was more important than Mesos or Swarm, which were heavy, complicated projects. Kubernetes’ API was compatible with the ideas of infrastructure as code, which made it appealing to people coming from tools like Terraform or Puppet. Even though people say Kubernetes is complex, it was simple to get started with. `kubectl apply` and you’re watching something run. That simplicity attracted people and kept them there.

Itiel Shwartz:  I think you hit the point that the best thing about Kubernetes is the abstraction. It abstracts the world with an API-first approach. But a lot of things have changed since then. People now complain about the abstraction – whether it should be more or less opinionated. What’s your take on that? Should there be another layer of abstraction on top of Kubernetes?

Kelsey Hightower:  This is natural; it’s called maturity. Over time, as you gain more experience, you find opportunities for improvement. The same was true for Docker. Kubernetes has brought people from running scripts on VMs to where we are now. I’d rather people complain about this level of abstraction than what we had before. When people say it should be easier to use, we now have the right level of abstraction to build that new thing. Some think Kubernetes should get more opinionated, but I think about it like a restaurant. Kubernetes is more like a grocery store where you can buy all the ingredients and make food just the way you like it. But, if you go to a restaurant, you’re limited to what’s on the menu. Kubernetes gives you the flexibility to build what you need.

Itiel Shwartz:  That’s an interesting way of viewing it. Docker hasn’t changed much, but Kubernetes feels like it’s constantly evolving – CRDs, operators – it’s like the ecosystem is different now than it was six years ago.

Kelsey Hightower:  I don’t think Kubernetes has changed much; it’s the ecosystem around it that’s evolving. Kubernetes was designed for change. CRDs were created because we knew there had to be extensions. The fundamentals of Kubernetes are still the same. You declare an API, give it a controller, and it makes things happen. Kubernetes, like Linux, needs to be a stable foundation, but the tools around it can evolve.

Itiel Shwartz:  So what’s the future? In five or ten years, will it be better trucks on top of the same Kubernetes roads, or will it be something else?

Kelsey Hightower:  The people deep in Kubernetes might be too focused to create the next big thing. Those who complain often have the best opportunity to make the future because they see the problems. I think the future will involve mini-platforms built on top of Kubernetes. Whether Kubernetes will still be part of it is another question. Some people will build the future on top of Kubernetes until it no longer makes sense.

Itiel Shwartz:  For me, Kubernetes is like Linux in that the community drives a lot of what happens. But setting up a new Kubernetes cluster feels like you need to install so many operators – it’s different from setting up a basic Linux machine.

Kelsey Hightower:  Kubernetes is still in the experimentation phase. We’re seeing people trying out new features, forking projects, and creating new tools. Eventually, things will consolidate, just like in the Linux world. The standards will take over, and we’ll have fewer logging daemons, for example. Right now, we’re still figuring out all the different levels and components.

Itiel Shwartz:  It comes down to what you said about Kubernetes’ APIs making it flexible and allowing for growth and innovation. That’s what made Kubernetes so successful.

Kelsey Hightower:  Exactly. Kubernetes is a manifestation of a specific philosophy – moving from automation to orchestration. That philosophy has set the stage for the next wave of thinking. It’s going to take time for people to rebase and set a new baseline for what the minimum bar should be.

Itiel Shwartz:  Okay, Kelsey, I think we’re running out of time. It was a pleasure having you. This was a super interesting episode. Thanks a lot!

Kelsey Hightower:  Awesome. Thanks for having me.

This is an AI generated transcript of the conversation

About the Guest

Kelsey Hightower
Independent Tech Voice / Author / Speaker (formerly Google Cloud)
Kelsey Hightower is an independent technologist, author, and speaker, and one of the most recognizable voices in the Kubernetes community. He came up through the configuration management world of the early 2010s, wrote the open-source project Confd, and joined CoreOS where he worked deeply on etcd and distributed systems. He began contributing to Kubernetes when it was still very small and Docker, Mesos, and Docker Swarm dominated the conversation, helped shape KubeCon into a community-driven event, and authored the widely used 'Kubernetes The Hard Way' tutorial. He spent years as a Principal Developer Advocate at Google Cloud before retiring from full-time work to focus on community, writing, and speaking. He is widely known as a minimalist.