Happy birthday Kubernetes, from K8s Co-Creator and Chainguard Co-Founder Ville Aikas

At Chainguard, when we say that Kubernetes and containers are in our DNA, we quite literally mean it. Chainguard co-founders Kim Lewandowski and Dan Lorenc co-created Sigstore, SLSA and other open source projects that laid the groundwork for the newly-minted “software supply chain security category.”

‍

But a lesser known fact is that Chainguard co-founder Ville Aikas was also one of the original co-creators of Kubernetes while at Google, where he saw the core principles that powered Google’s homegrown “Borg” system (that ran the world’s most popular cloud services like Gmail, YouTube and Adwords) inspire an open source project that made operating containers at scale possible.

‍

To celebrate Kubernetes’ 10 year anniversary this week, we caught up with Ville to hear his retelling of the genesis story of one of distributed computing’s most influential technologies of all-time, and how K8s together with containers have disrupted the security paradigm along the way.

‍

Sarah O’Rourke (SO): In its earliest days, what were the conditions that you and other technologists at Google saw driving the need for Kubernetes?

‍

Ville Aikas (VA): With the previous model of virtual machines (VMs) running on big Linux boxes, developers had a lot less freedom than they do today. With VMs, developers had to ask sys admins for resources or upgrades, and they’d hear about all kinds of dependencies and other pushback for why it would take days or weeks.

‍

Virtual machines aren’t immutable — so you can come in and screw with things, SSH into things, and twiddle with things. But that’s how you end up with unique snowflake server environments, and that’s how you jam up developers with infrastructure that’s too hard to reason with. I still know people that run VMs that they built 12 years ago, that are running core services where they are terrified to touch any of it. VMs led to bad practices in how not to serve developers infrastructure.

‍

At the time the idea for Kubernetes came about, I had just finished working on my first project at Google — Google Voice. Joe Beda was coming off a major project with Google Chat. We were both heavily involved with the effort to build Google Cloud in Seattle, and our first steps were breaking out the big pieces of shared infrastructure in a model that allowed distributed engineering to happen against a common resource. My piece was storage. Joe was focused on compute.

‍

Quite often, I stated that we should not be designing a system that gave users virtual machines as the interface, and that we should instead be giving them containers like we ourselves used at Google with Borg. But we had to meet customers where they were, and at that time that was on VMs.

‍

Tick-tock — time went by — and finally Brendan Burns delivered his Saltstack demo using Docker, which, at that time, was a little prototype that allowed you to go in and launch containers and coordinate them a little bit. The beauty of Docker was that they got the developer interface right. No one at Google cared about internal developer experience. The attitude is — you’re smart, go and figure it out. But Docker’s format, together with Brendan’s prototype — it all just came together at the right time, and that’s how Kubernetes was born.

‍

SO: At the time Kubernetes was introduced, there were already some predecessor container orchestration projects in Apache Mesos, Docker SWARM, and CoreOS. Why do you think Kubernetes was met with such success?

‍

VA: It was a lot of things. First, I really think Kubernetes got the reconciler model right. Kubernetes handles the “desired state” versus the “current state” extremely well. The API-first approach to API was also huge from a technical standpoint.

‍

I would also argue that Kubernetes was uniquely successful from a community standpoint. Kubernetes has grown in complexity today, but in its early days they made the mental model very straightforward, so the cognitive load was very simple. It started engineers with the right abstractions that are still in place 10 years later.

‍

SO: Containers and Kubernetes completely changed the rules around networking and storage, but their disruptive impact on security may have been even greater. What would you say about the progress that’s been made around container security, and particularly in the last few years since Chainguard launched?

‍

VA: I remember early on when we were shopping the idea of Kubernetes around, and people at Google were asking “How do you validate these things, people are going to just run these containers off the Internet?” And I was saying, “No way, no one is going to do that — they’ll only use containers from people they know and trust.” It turns out I was wrong.

‍

Containers really sidestepped the security model that was in place with containers. If you go to a shipping yard and you want to ship a container from Iceland to Finland — the nice thing is that you can put anything inside of it. But if there’s no customs, how do you know you aren’t shipping something illegal? The industry’s evolution to containerized applications happened so fast — and was much different to the traditional approach to how software was packaged, secured, and shipped — that some majorly important steps never happened.

‍

We’ve really done some tremendous work in recent years, both as an industry, and here at Chainguard. With important foundational open source mechanisms like Sigstore and SBOMs, we now can understand what’s inside of that container. We can give the scanning tools the information they need to figure out whether what’s inside is good or bad. We have all this new tooling that acts like the equivalent of a virtual “customs” — where policy control from Sigstore and other tools can limit what’s allowed to run.

‍

We have the provenance data of where these containers come from, and whether build systems have been tampered with. And, most importantly, we have secure base container images — Chainguard Images — that have been redesigned to ship without a bunch of cruft and known vulnerabilities so that there’s finally an “easy button” you can hit so you can use Kubernetes and containers without having to become an expert in security.

SO: What’s your birthday wish for Kubernetes?

‍

‍VA: We have this massive Cloud Native Computing Foundation landscape that has bloomed, which is a wonderful thing in terms of all the diversity of tooling and infrastructure options it gives to platform teams. But I think it also creates a bunch of choices that have to be made in order to operate Kubernetes — and that landscape has gotten huge. I always felt that one of the core reasons why Kubernetes became so popular was because its API is so simple and that the cognitive load to using it is so relatively low. As K8s continues to mature, it needs to somehow retain the simplicity of its mental model and usability of its API.