Ten years ago, the Kubernetes project was first announced, and then soon after, the Cloud Native Computing Foundation (CNCF) was formed to become the home for it. Chris Aniszczyk was the founding executive director at the time, and has been around for the project’s entire history once it was donated by Google to the CNCF.
ITOps Times news editor Jenna Barron recently spoke with Aniszczyk about how the project has evolved over the last decade. Their interview, initially done for the “Get with IT” podcast, has been edited for clarity and length.
Jenna Barron: As many people already know, Kubernetes was born out of Google in 2013, and was first announced to the public in 2014. Can you talk a little bit about what the idea of containerized apps looked like at that time?
Chris Aniszczyk: In those days, there were very, very few companies that were running at crazy scale, and they just weren’t exposed to running infrastructure that required you to make things as efficient as possible. People would have their own data centers and you partitioned out machines for different functions – for databases, or caching servers, or compute. And so, a lot of companies are trying to run things at scale, and how do they make things more efficient? Google figured this out very early, because they were kind of one of the early companies that built scaled-out data centers. That was the impetus of how this all started. There’s no way to efficiently run infrastructure at scale without partitioning out your workload and having it orchestrated by something that is able to intelligently place the workload and take advantage of resources. Containerization lets you cut up the server and use it both for running memcache, for example, and maybe compute-based workloads and a bit of a dupe, so you utilize 80% to 90% of that machine instead of like 20%.
JB: So as I mentioned before, the CNCF formed to be the home for Kubernetes. Back in those early days, what was it like forming the organization around this project and what led to the decision to ultimately do that?
CA: I will credit some of the early folks involved – Craig McLuckie, Brian Stevens, Sarah Novotny, Joe Beda and a whole lot of these folks that Google knew wanted to go build an orchestrator to change how compute workloads are run. They knew that if they were going to truly build an ecosystem, you can’t do it alone, right? If you want to get partners with you, you need to make sure that you have open governance, that things are hosted in a foundation –, which, you know, there’s a lot of them, but they wanted to build a custom one, particularly for modern cloud native and compute workloads. And also, in building the foundation, they also wanted to make sure that there was end user representation. The original mission of CNCF was always to have three pillars – you had the governing board, which is mostly comprised of vendors; you had our technical board, which is mostly maintainers and developers; and an end user board, which is end users.
And, you know, there’s a reason it’s not called the Kubernetes Foundation and it’s called the Cloud Native Computing Foundation, because they had enough of a vision to think that we’re going to have to host more things than potentially just Kubernetes. At its core, it helps orchestrate workloads – there’s an API server, there’s a way to describe your application and what you need to orchestrate and YAML. In terms of stuff that you actually need to run a modern application, you need to be able to observe it, you need to be able to secure it, all these things are external components that are built outside of Kubernetes. So they always knew that other projects would eventually come along.
JB: So looking back over the past 10 years, what were some of the most significant events that happened with the project?
CA: The project was announced at DockerCon in 2014, and the building of CNCF was announced at OScon, I think, sometime over the summer 2015. Over time, a couple of things that stick out to me is we ended up building a conformance program for Kubernetes, which means we wanted to guarantee that wherever Kubernetes exists as a service or product, there would be compatibility, and we really wanted to ensure that this conformance program was API-based, driven by the community. Now I think there’s over 100 conformant Kubernetes distributions, and that really lets it blossom.
Another interesting bit of history for me was when Kubernetes made it pluggable for different container runtimes. Initially, Kubernetes, basically baked in the Docker engine, and there was a lot of competition and fighting between CoreOS, Docker – there was even a company called Joint that was putting together its own little engine. Eventually what happened is Kubernetes built an interface called CRI, which basically allowed different container runtimes to plug in and take advantage of the Kubernetes ecosystem. I think that that helped alleviate a lot of politics in the ecosystem. So instead of people fighting, they got together and worked together to build these interfaces.
JB: So now looking forward, what can we anticipate over the next 10 years?
CA: In this industry, technology changes extremely quickly. And anything that lasts a long time is a testament to the people in the community that built that project. And I guarantee you, when we talk about the 20th anniversary of Kubernetes, maybe the underpinnings are going to look a little different. Maybe there’s more Rust in there, maybe more WebAssembly in there. Who knows? But the same community values around being included, valuing community over company, will be there and will guarantee the long-term success of this project and community.
