ADAM GLICK: Hi. Welcome to the Kubernetes Podcast from Google. I'm Adam Glick.

CRAIG BOX: And I'm Craig Box.

[MUSIC PLAYING]

CRAIG BOX: It must be time for the Movie and Game of the Week. [CHUCKLING] Let's start with Game of the Week.

ADAM GLICK: Indeed. I decided to pick up a copy of "Old Man's Journey," which is, I guess, part puzzle game. It's not a terribly complex puzzle game, but it's fun, enjoyable.

What it really does a great job of is it's another one of these very immersive storylines. And the story of what happens to this old man as you kind of play through his journey is really the interesting part of it. It's kind of an interactive art piece. And that was an interesting one to pick up. It's also part of the Google Play. They've got a kind of you can buy a subscription thing. And so it's one of things you can just download in there.

CRAIG BOX: Right.

ADAM GLICK: And it was probably a couple hours' worth of fun to play through it.

CRAIG BOX: Well, a couple of hours is all it takes to watch a film, and having flown back to England last week, I managed to get a couple in.

I enjoyed "Rocketman," which was the Elton John sort-of-biopic-fantasy film, and it got me back into listening. If your entire familiarity with the work of Elton John is his piano ballads, I'd encourage you to listen to the first couple of tracks on "Goodbye Yellow Brick Road." There's a little medley on there of two songs, "Funeral for a Friend" and "Love Lies Bleeding," which are great '70s prog rock anthems in and of themselves.

And just on a whim, I thought I'll watch the new "Aladdin" movie. And well, I like Will Smith, and I liked Robin Williams in fairness. But--

ADAM GLICK: How did it hold up in comparison to the animated one? Because I hold that in very high esteem.

CRAIG BOX: Yeah. It's been a long time since I've seen it, and I think that it probably had pros and cons at the time. But I'm going to have to say that comparing them will be tough, especially with the performance that Robin Williams put in. But Will Smith managed to pull off a respectable Genie character, which I think is really the mainstay of the movie. He definitely had his name at the top of the credits.

ADAM GLICK: Excellent. Shall we get to the news?

CRAIG BOX: Let's get to the news.

[MUSIC PLAYING]

CRAIG BOX: KubeVirt has joined the CNCF as a sandbox project. KubeVirt allows you to provision and manage virtual machines from within Kubernetes. Yo, dawg, we heard you like VMs and containers, et cetera.

Other recently added sandbox projects includes Strimzi, an operator for Apache Kafka, and In-Toto, a framework to secure the integrity of software supply chains.

ADAM GLICK: Registration for the Kubernetes Contributors Summit at the San Diego KubeCon has now opened. The event is expected to focus on stability of the project and contributor growth while targeting over 450 attendees with a social gathering on Sunday and the summit all day Monday. The associated new contributor workshop has already hit capacity and a wait list has begun. So if you're interested in joining the summit, you should probably sign up soon.

The CNCF has also announced the schedule for ServiceMeshCon, another pre-day for KubeCon. The con will contain sessions on Istio, as well as other service mesh technologies. Tickets are on sale for $199, and pre-registration is open and required.

CRAIG BOX: Google Cloud has added an intranode visibility feature to GKE, a mode where all network traffic in the cluster is seen by the VPC network. This means you can enable flow logs for all traffic, even between pods on the same node. And network firewall rules can be applied to interpod traffic the same way as across other parts of your GCP infrastructure.

ADAM GLICK: Civo, a UK-based developer hosting company, has released a beta Kubernetes-as-a-Service offering. They're calling the beta program #KUBE100 with a K.

The service claims to be the first Kubernetes service running on K3s, the slimmed down Kubernetes release from Rancher. Civo's CTO Andy Jeffries has also a post suggesting that K3s, "keys," is better than K8s, "Kubernetes", ignoring the fact that it's clearly five less.

CRAIG BOX: Bill Mills from Docker has posted a five-part training series on getting started with your first application on Kubernetes. He walks through the basics of architecting an application with a focus on the Kubernetes objects you're going to need.

In unrelated news, an internal memo from Docker CEO Rob Bearden leaked this week saying that they are looking to raise funds, but they are having challenges in doing so. Docker has already raised over $200 million in previous rounds, and was valued at 1.3 billion in 2017. Bearden mentions that Docker is in talks with two investors, and that the hopes to share more details soon.

ADAM GLICK: IBM has announced an operator for Apache CouchDB, the open source document database that runs on, quote, a "Cluster Of Unreliable Commodity Hardware", or COUCH. Ah. I learned something new!

CouchDB is the open source database behind IBM's cloud and distributed database and is itself free platforming on top of Apple's FoundationDB in an upcoming release.

In separate news, IBM Cloud claims to be all in on Kubernetes with 90% of their PaaS and SaaS services now running on their managed Kubernetes environment, according to a recent interview.

CRAIG BOX: Kubernetes decides how many pods to schedule on a node based on resource requests and limits set on the containers within the pods. Setting these is imperative to keeping your bill down and your workloads happy, but few people get it right first time.

Startup Kubecost's founder Webb Brown has posted a guide to setting container requests and limits. And their commercial tools now support making recommendations for where they should be set.

ADAM GLICK: Kubernetes must be too expensive, as there's a second startup working on optimizing it. That company, Magalix, with an X, has released KubeAdvisor 1.0. KubeAdvisor is a tool that scans your Kubernetes configurations and environment using an ML algorithm looking for optimizations that can help increase security, decrease costs, and avoid container throttling.

KubeAdvisor is a free download. And the agents can be installed through the Google Cloud or Azure marketplaces.

CRAIG BOX: Finally, fields you can set on a pod in Kubernetes include Liveness and Readiness probes. Liveness probes tell Kubernetes when to restart a container. Readiness probes tell it when a container is ready to start accepting traffic. It turns out many newcomers to Kubernetes don't correctly learn this distinction, and so the Pfaltzgraf of Pfailure. Henning Jacobs of Zalando, has shared some of their internal documentation to help make sure you don't end up on his famous list of failure stories.

ADAM GLICK: And that's the news.

[MUSIC PLAYING]

ADAM GLICK: Daniel Smith is co-chair and co-technical lead of the Kubernetes API machinery SIG, as well as the TL of the corresponding Google team. Daniel has been working on Kubernetes since before it was open sourced, and is one of the top overall contributors to the code base. Welcome to the show, Daniel.

DANIEL SMITH: Thanks for having me.

CRAIG BOX: DevStats suggests you're either the number two or number three contributor to Kubernetes, depending on how you slice it. You've said before that's because you were there right from the beginning. What was life like at the beginning? How did you get involved with the Kubernetes project?

DANIEL SMITH: Early on in the beginning I was top because I sent a bunch of code. I guess I must still be high, because I comment on a lot of things. So yeah, my wife came up to me last night. She was like, why are you not in bed? "Somebody on the internet is wrong, related to Kubernetes!" So yeah, I felt that way a lot since this project started. That's probably why I say so much. I try to be very nice.

I'd been at Google for about a year when Kubernetes was getting off the ground. Most of that I'd been working on Borg, which is Google's internal container management system. Specifically, I was on the control plane of that effort, and then I spent a few months working on App Engine. I optimized some scheduling there.

And then they were trying to spin up Kubernetes. And I think Tim Hockin was the one who approached me. He was like, hey, do you want to come join this project? It's kind of risky. I'm like, yeah, OK, sure.

It sounded interesting. It wasn't clear what exactly we were going to build at that point. So there was a very rough prototype.

But the first thing I did was actually I added a feature so you could run a container on just a regular old GCE VM, which was interesting, and not super useful. But it was our first step into the space. And then it became clear, like we got permission to do Kubernetes. It wasn't called Kubernetes then. But we got permission. So then we all started hacking on this code base.

I think it was Brendan [Burns] who wrote the original draft. When I got involved, like all of the Go files were in one big package. There wasn't any division at all. So it was super confusing. Nobody would've been able to follow it.

So one of the larger changes I made initially was splitting things up into different packages. And I misunderstood some things. There were some clients. And one of those clients was a client of the API. And one of those clients was a client of kubelet. And it wasn't obvious that they were different clients. And they went into the same place, even though they were completely opposite directions. So that was wrong in the code base for like two years after that.

CRAIG BOX: You've got to watch out for those people who are wrong on the internet.

DANIEL SMITH: Yeah.

So at the very beginning, it was a super intense project. There was a good month prior to its being open sourced where I'm disappointed that we had a name change late. So we didn't open source the original stuff, like we copied. So the first commit that you see in open source, that's not actually the first commit. There is a bunch of stuff before that. That's prior to the name change. So I'm a little disappointed that nobody gets to see all the stuff I did before that first commit.

ADAM GLICK: What was that first name?

DANIEL SMITH: The first name was Project 7. And there was a second name, too. And then there was a third name, which is Kubernetes.

ADAM GLICK: What was the second name?

DANIEL SMITH: I think it was Carina after the star constellation, which has like seven stars in it. I think this showed up as a trivia at some point at one of the KubeCons. So I don't think this is not public information.

CRAIG BOX: Yeah. I don't think we're breaking this news, because I think I've heard Brendan mention that before.

DANIEL SMITH: Yeah. So I'm pretty sure that was the second name. So yeah, we changed the name to that, and then we changed the name again. So it's too bad, but that's why sometimes some obscure historical detail comes up, and I'll go search through the "kubernetes-old" repo looking for that.

CRAIG BOX: Do you think Kubernetes has succeeded because of its name, or in spite of it?

DANIEL SMITH: I think it succeeded partly because of Google's name. So it didn't matter that much what we called it. And this was just the thing that got through all of the various review processes. It was so weird that nobody could object, I guess.

I think it was just the right product at the right time. And it did the right things. And the usage was phrased in the right way. It didn't really show too well on the first day, like it was super complicated to get set up. It's only a little complicated to use. But what mattered was you could really see yourself building a bulletproof system out of this.

ADAM GLICK: One of the key pieces that you hear people talk about is the Kubernetes resource model. How would you describe that?

DANIEL SMITH: When you think of Kubernetes, you think of like container scheduling or machine management or workload deployment. But I think the key innovation that Kubernetes brought is actually the API and the model of that API.

So many APIs are like imperative calls. And by imperative, I mean I'm sending you a call across the network, and I want you to do a thing immediately and tell me if it worked or not, right? That is not at all how Kubernetes works. And it's kind of a shock if you're not used to this.

Kubernetes is much more like a database than an ordinary API, if that makes sense. So instead of like telling the system to go do things, you record your intent, like you write to the system, but you're not sending an instruction. You're sending an, I would like the world to look like this.

And then there's a bunch of other actors-- controllers, we call them-- operating on the API as well. And the controllers are watching the intent that users have sent or possibly intent that's set by other controllers. So controllers are watching this and reacting. And this is the key innovation of Kubernetes, as I see it, is scaling complexity, right? You've got a big system. There's a bunch of complicated things. Like, how do you decompose that into understandable bits?

And usually, the failure mode of big projects is it gets so complicated that nobody can hold it all in their head at one time. And the innovation behind Kubernetes, in my view, is that you don't have to hold it all in your head at once. The controllers individually can be quite complicated, but that complexity is limited to a small slice of the system. And the Kubernetes resource model lets the controllers communicate with each other in a standardized way such that you don't really have to have a detailed model of what the other controllers are doing in order to get them to do what you want. So that complexity is split up-- I call it sharded-- by controller, which is super useful and lets you scale out the system to do more and more complex things.

CRAIG BOX: Now we have a database for storing the desired state, and we have the API server, which is the thing that takes in the requests from the users, and the controllers that act on it. These things collectively we think of now as API machinery. How did you evolve from the initial API server to having a full suite of API machinery?

DANIEL SMITH: I think back-- this would've been like maybe six months to a year into the project. The team at Google was growing, and we were trying to figure out, OK, how do we scale this? And clearly, you can't have everybody do everything. You're spread too thin. And it gets really hard to make progress, right? You have to kind of specialize a little bit.

So we kind of split up along the natural lines in the code base. And we actually had a really hard time thinking of a name for the thing that I was doing. For a while we called it the client-server infrastructure. But the storage team eventually stole that name for a container storage interface. But really the name that stuck more was API machinery.

And when we first envisioned it, it included the pathway from client library to API server and from API server back to our storage backend, which was and still is etcd, the database started by CoreOS. So that's where the name came from.

CRAIG BOX: Two months after the open sourcing of Kubernetes, you made one of the first proposals for API plugins. It's so old it has a three-digit issue number on GitHub. What was the problem you were looking to solve at that time?

DANIEL SMITH: I think the problem I was trying to solve is just churn, right? I want to write a really excellent API server that takes care of all of the details, but I don't necessarily want to be the person who exhaustively reviews every API, right? So the idea is anytime in software engineering when you want something to work the same, you basically have to run the same code or find some way for it to actually function the same, because otherwise it just will be different.

And one of the key benefits of the Kubernetes API model is that it's the same, right? Like if you understand how to work with one API resource, you basically understand how to work with all of them. All you need to know is the individual differences, right? The way that the author of the API modeled their problem.

But there's a lot of like standard stuff that you don't want them to differ on, right? Like we want the same metadata. We want the same sort of conversion between versions. We want the same wire formats, like Protocol Buffers or JSON, like we want all the stuff the same. Otherwise, users just will have to learn a bunch of different things every time they go to a different API object.

So basically the motivation from my perspective is to try and let people write all the unique parts for their API without having to worry about the parts that should be the same. And there's a couple ways you can do that.

One is to actually have them build it into their own binary. And so we try to do as much as we can in the main binary, which turned out-- eventually, we called it the Aggregator.

And the other way is to directly build in some sort of way of like you describe the shape of your object, and then API server just start serving that. Sort of like you'd give a schema to a database, right?

ADAM GLICK: Were you thinking more about extensibility or consistency of experience as you put that together?

DANIEL SMITH: I was probably thinking about both. It's a little bit difficult to know what I was thinking in 2014, because that was a long time ago at this point. But I was probably thinking about both.

It was already clear at that time that the API was an important part of the system and that people were going to want to use that style of API for more things. We gave people out of the box this deployment resource which can coordinate replica sets, which can coordinate pods, which run the user's workloads. So people already had this great model of how to compose things in this API style. And it was clear that they were going to want other abstractions for other kinds of software.

CRAIG BOX: And that was a few releases in, if you recall. There were obviously replication controllers and things before that. These things took time to evolve. Were you seeing other people who wanted to move quicker than that?

DANIEL SMITH: Yeah. Definitely, the velocity was a huge concern at the time, because we knew we had a lot to do. There were a bunch of debates going on through the early days of the product.

One of the debates going on was we want to make things really easy for users, but we also want them to be able to have this power, right? So there was this tension between I want to be able to deploy my stateless application with like three lines of YAML, versus I have this really complicated setup and I want to be able to describe it in detail.

And the solution we kind of came up with is objects that do the work for you. And you get this base layer that can do everything, like the pod abstraction, but then you build up vertical things on top of it that automate some of the aspects of various types of application. So it was clear very early on that that was the route that Kubernetes was taking, because a lot of the criticism of Kubernetes is, like, you've got too many resource types. What do all these things do? How do I put it together? And we're like, yeah, I know it's a lot of stuff, but actually, that's a feature, not a bug.

CRAIG BOX: One of the early patterns that implements the thing you're describing was CoreOS's operator platform, where they would take an API extension resource called a Third-Party Resource, and couple it with a custom controller. This now introduces a new object in Kubernetes, which many people today may not be familiar with, because it's been deprecated since 1.7, I understand. What was the story about third-party resources?

DANIEL SMITH: Early on we came up with this API aggregation model. And Brendan Burns was like, no, that's too slow. It's going to take you forever to write that. So he started this third-party resource effort, got something that mostly worked, and people built stuff with it.

Let me go back to something you said, which is you called it an operator. I think operator is really just a controller, right? We've got a new name for it, because now it involves a specification object, too, right? But the innovation there is the packaging, I think, not necessarily what it does, because we had lots of examples in the Kubernetes code base of controllers that do basic things. So there's good examples. And that's the logical next step. So congrats to CoreOS for actually putting that all together.

ADAM GLICK: The most common extension mechanism that people use today is the CRD, or Custom Resource Definition. How would you define that for someone who is unfamiliar?

DANIEL SMITH: A CRD, a Custom Resource Definition, describes to the API server how to present a resource to a user, right? It provides a schema, the name of the resource, properties that you want it to have. And the API server takes that resource definition and it describes a Custom Resource, or a CR. And it begins exposing the API endpoints that let users interact with the custom resource. And the custom resource then supports all of the typical Kubernetes API patterns.

CRAIG BOX: So I can effectively type 'kubectl get foo' in the same way I would type 'kubectl get pods'.

DANIEL SMITH: Exactly. Yes.

CRAIG BOX: Did kubectl have to change in order for that to be possible?

DANIEL SMITH: Yeah. Back in the day when we had TPRs, kube-control, kube-c-t-l-- I say "Kube Control." That's my vote on that.

CRAIG BOX: "Potato, potahto."

DANIEL SMITH: Yes. Back in the day when we had TPRs, kubectl did have a bunch of if statements to make the whole thing work. It might still have a few, but we're evolving to a state where kubectl just reads the schema doc.

So API server publishes this thing called an OpenAPI spec, which contains like information about all of the types in the system. And kubectl can read that, and then know how to interact with that, even to the point where you kubectl can locally implement the validation until you-- before you even submit your YAML manifest if this object is going to be accepted or not. So we're evolving into a state where kubectl doesn't actually have to know anything about the resources that it's acting on, which is really the only way it can work, because the server is the only thing that is going to know the full extent of the types available, right? Because you could have aggregated API servers. You could have CRDs. You've got built-ins. Only the API server knows what's available in this particular cluster.

ADAM GLICK: How did we get from those third-party resources to the CRD work?

DANIEL SMITH: It's been a long journey, actually. I think back in 1.7, which was a while ago now, David Eads, my co-TL for SIG API machinery, looked at this code base. It was clear that people want this functionality. It's becoming vital for the ecosystem. Like CoreOS has its etcd operator out by then. There's definitely people that are coming out with more.

So we've got this problem where people are using this feature, but the code base wasn't really written with this in mind. And as a consequence, there's a bunch of like if statements scattered all over that try to give the same behavior for TPRs as they gave for the built-in resources. And so David Eads is like, we can't maintain this. This is not working. And really, we need to refactor things to get this right.

So due to that, we knew we had to start an effort to really do it for real, right? And there was a ton of people that helped with that. I think specifically Nikhita did a bunch of the early work. So we got CRDs to an alpha, and then a beta. And then people could use it. And they were tied into the system. And then we started adding the features that people wanted, like the ability to specify a schema so that it wasn't just an untyped blob of stuff, but you could kind of have expectations about the data that users would write there.

Then that kept growing. And users have this expectation that all of the API works the same, whether they're built-in resources, or CRDs, or they're hosted from some aggregated API server. And it was a huge effort to get this to GA.

CRAIG BOX: Yeah. It has taken a large number of releases.

DANIEL SMITH: Yes.

CRAIG BOX: And was it incremental in that you were discovering new things each time you needed to improve?

DANIEL SMITH: It was somewhat incremental. But for the most part, we knew the problems that we had to solve, I would say, multiple releases ago. But it wasn't clear how to solve them. So we finally came up with an explicit list maybe-- it might have been the release before this one. And like we had a plan.

There were still some problems to solve, because Kubernetes API server is not a static system, right? We're working on CRDs, but we're also working on some other extensibility work, like the ability to inject your own policy through admission webhooks, which is also super important to people. You want be able to add some business logic that applies across the ecosystem.

And so while we're paddling on CRDs to try and get those to GA, we're also adding features to everything else, too. So a lot of the final stuff we had to do in this release was making those all consistently work together. Specifically if you have this admission webhook, this thing that can modify objects as they come into the system, and you operate that on a CRD, and you want to do this, and then somebody else has another one, which wants to make another change, how do you order those changes so that you get the result that the admission webhook author and the CRD author-- you want them to arrive at a state that they both agree on. But it's very difficult.

And we don't actually love our solution. We might try to come up with a better one at some point. Right now, our solution is just call things twice. I think that was Jordan Liggitt that came up with that one.

CRAIG BOX: Another extension type is the aggregated API server, where you have a complete implementation of a Kubernetes API server that you are responsible for writing yourself. What are the pros and cons of these two approaches?

DANIEL SMITH: We definitely recommend that if you're a typical user-- you just want to get a new API type in the system-- use a CRD. It's much easier.

If you want to do something more advanced or something like use a custom storage backend or produce a synthetic resource, such as the Metrics API in Kubernetes does this, then you need to do some more work. And we have the aggregated API server model for that.

And basically what that is is you register yourself with the system. And the aggregator, which is the first thing that a user request hits when it comes into the Kubernetes API server, the aggregator recognizes that the request is for the aggregated API server. And it will proxy that request, right? So it gives you complete control over the request. But it also has the downside in that you have to maintain an entire binary and stay up to date. And so it's not super user friendly. It is super powerful.

CRAIG BOX: Kubernetes has been doing a lot of work to support extensibility in many different forms. We've got the container storage interface, and similar for networking, CNI. A lot of new functionality that is API driven is now being previewed or introduced as CRDs rather than in the core of the code. Do you think that that is an offshoot of the fact that it is now possible or was that a conscious decision that the project made to shrink the central space of the APIs?

DANIEL SMITH: There's multiple inputs into what drives our API system. One consideration is we want it to be easy for people to write their abstractions, to write their new features. Another is we want it to be scalable. There's only so many people that can review these things. And so it's much more scalable and simpler if people write a CRD, right? That's kind of a self-contained unit.

Whereas if you have to put it into the default API server, that's kind of a big deal, right? You're potentially breaking every cluster everywhere. If you want to turn this thing off, you have to have a flag. The cluster administrator has to get involved to toggle this flag if you want to turn off some broken resource or something.

If you have a CRD, you just go in there and remove the CRD from the system. And you're not breaking the system anymore.

So there's a bunch of good reasons why we want things to be done more like CRDs in the future, but there's still some blockers. One of the blockers is how do we-- like suppose we have a bunch of CRDs that we want to ship with the default Kubernetes. How do we install those in a cluster on startup? We don't have a great answer for that just yet.

Another problem that is blocking this is CRDs don't have a place for you to run the same sort of validation logic as the built-in resources. You can call out to a webhook. That adds a path. So I think we can add more features in the future. Just because it's GA doesn't mean we're done. We can add more features in the future, especially around the schema and adding types of pre-canned validation functions that you can reference in the schema so that we can provide more of the features and make it more rare that you need to actually call out to a webhook to get the validation that you want.

ADAM GLICK: You've talked a bit about the growth of the project and scalability as the project has grown. How have the human factors of the growth of the project influenced the extensibility decisions?

DANIEL SMITH: When people are making changes to Kubernetes, there's a series of things that have to happen before those changes can get merged and go live, right? You make a change. Somebody reviews it. It gets merged. It goes through the testing. We cut a release. It goes out, right? So there's a series of things that have to happen.

And some of those gates are harder than others, right? The skill level to make a change might be somewhat high, but not that high. But to review it and know for sure that it's a good idea is maybe a little harder. And to review it and know that it's going to work in the context of the system as a whole takes a lot of experience.

Despite our attempts to scale the project as rapidly as possible, or maybe because of it, we got into the situation where there's more people sending changes than there are to review the changes. And this led to a lot of anguish. I don't know that it was explicitly recognized the way that I just described it, but there was definitely this view like, oh, it's hard to contribute to Kubernetes. How can we improve this?

And so if you can come up with a technical solution to a human problem, that's usually-- it's easier to change the technology than it is to change people, right? So splitting up the code base into smaller pieces so that we can more effectively shard the human effort, right? Making it so that to review a change you don't have to know the entire system. Maybe you just have to know a subsystem, right?

So I would say like the human factors of this enormous amount of interest and uptake in contributors showing up from very early on in the project before we really had enough high level reviewers ramped up, like that definitely had an effect on how we thought we wanted to evolve the system.

CRAIG BOX: You've given a number of KubeCon talks, most recently a trilogy, with the last talk in that trilogy entitled "The Kubernetes Control Plane for Busy People who like Pictures." How much can you describe there in this audio only medium we're on now?

DANIEL SMITH: I had so much fun putting the talk together. It's so much work, but it is fun.

CRAIG BOX: It actually looks like hand drawing slides is probably less work than putting them together in a slide tool like PowerPoint or Google Slides.

DANIEL SMITH: That was honestly how I got onto that style at first. I'm like, I need some boxes with arrows and text. And it's soul crushing to draw boxes with the little rectangle tool and drag the arrows around. And you've got to arrange it. It would be so much easier just to draw this on paper. So that's what I did. And that's how the first talk ended up like that. And people seemed to really enjoy the style of those diagrams, so I just kept doing it.

Yeah. So I had a lot of fun. I'm not a great artist at all. So the slides are like very poor art, but it's enough to get the point across. I try to like at least write very legibly.

CRAIG BOX: Have you petitioned Tim to become the number two contributor to custom Kubernetes logo T-shirts?

DANIEL SMITH: It's never come up, although Tim did say he needed ideas. So maybe.

ADAM GLICK: In July 2016, you won the first Kubernetes community award for being, quote, "the nut that ties everything together" for the 1.3 release. Do you still have the trophy?

DANIEL SMITH: It's on my desk. Yes. That's the first thing I get out when I move desks, which we do frequently here at Google.

CRAIG BOX: A number of projects that are not necessarily about infrastructure or containers are adopting the Kubernetes resource model and the API machinery in order to describe their own things. How does that make you feel?

DANIEL SMITH: I'm super happy to see that. I feel like there is a bit of a race between the-- like there's a couple of niggling details that we need to fix strategically, and the race that we want to make this easy for people. And I know examples of people starting up like building systems with this resource model. So I think it's just amazing. I'm super happy about that.

It's a little surprising, because you never expect something like that to happen to you. But it did.

CRAIG BOX: How would you sum up your experience with the Kubernetes project so far, and where would you like to see it go?

DANIEL SMITH: The Kubernetes project has just been an incredible experience for me. It's amazing to see a project start from five of us-- I was the fifth active person when I joined-- to like the shape that it's in today, where it's affecting so many companies and people. I walk past people and they're wearing Kubernetes shirts like just out and about. And it's pretty weird. That doesn't happen to very many tech projects. So I feel really honored to have been a part of this. And I look forward to continuing to contribute to this project in the future.

ADAM GLICK: Thanks, Daniel. It's been great having you on the show.

DANIEL SMITH: Thanks for having me. This was great.

ADAM GLICK: You can find Daniel Smith on Twitter, @originalavalamp.

[MUSIC PLAYING]

ADAM GLICK: Thanks for listening. As always, if you enjoyed the show, please help us spread the word by telling a friend and giving us a rating on iTunes.

If you have any feedback for us, you can find us on Twitter, @KubernetesPod, or reach us by email at kubernetespodcast@google.com.

CRAIG BOX: You can also check out our website at kubernetespodcast.com, where you will find transcripts and show notes. Until next time, take care.

ADAM GLICK: Catch you next week.

[MUSIC PLAYING]