Kubernetes: The Documentary [PART 1]

Kubernetes: The Documentary [PART 1]

Show Video

All right thank you. Sounds okay. Do I look  at you? Look at the camera? I think the reason   that the cloud was so important, around 2013,  was every company was an internet company. The environment of Silicon Valley in 2013, you're  kind of on the heels of the devops movement.

We're moving from just pure virtualization   into infrastructure as a service  AKA the cloud. And so at that point,   automation tools are all the rave. People  are now trying to abstract away the servers. Cloud was starting to become important at Google.  

We realized this was a space  that we had to participate in. Cloud was becoming real in a very material way. We're starting to see the ascendance of Amazon  as certainly something that was becoming   mainstream enterprise technology.

AWS was this behemoth that  was on everybody's mind. By far you know AWS is the dominant, you know,   cloud provider. They were early into the game  with S3. They built a great ecosystem - like,   nailed it, you know. It's a great kind  of business at the end of the day.

The main issue is they were so dominant that  other people were like, 'hmm, maybe we should   have potentially a cloud-based business,'  right? Whether it's like Google or Microsoft   or other companies out there. The problem  was they were so kind of ahead that you...   if you want to change the game, you  know strategically, like what do you do? We knew that we had really good computer   technology because everything that  we had been doing was cloud first. Everybody was kind of feeling  like, 'hey, yeah, no that's cool.' They got a, they got a head start, right?  Okay cool, we're out here to compete. Incrementalism wasn't gonna actually make  Google successful with GCE. How do we   change things up? How do we shake the snow  globe in a way that, you know, may not be   all about Google, but at least gives Google a  fighting chance to be able to start grabbing some   of these customers and to start being that balance  against the dominance that AWS had at the time? Google was looking for ways to apply its  internal infrastructure expertise to the cloud.

If we could leverage that  expertise in that technology,   then that would accelerate our  entry into the cloud space. So around 2013, I think the world was kind  of primed for some new abstractions. This   kind of set the stage for things like Docker,  containerization and eventually Kubernetes. Docker is pretty special because almost  immediately it got a lot of buzz, right.  

People got really excited about it. I personally  am really excited about Docker. I think it's,   you know, probably the most important project I've  worked on, but because of the buzz, because of   the excitement, I get a lot of questions. People  come to me and they say, 'what the what the hell   is Docker in the first place? I heard about it.  I don't get it, you know. What's the big deal?' It is a big deal. I'll start by saying that  and I think containers - the concept of   containers and the implementation behind  it - will be a big deal for all of us.

I think it will affect the way we  work, the way we create software,   the way we distribute it in big ways in the  coming months and years, and I think that's   really exciting. So that all has to do with the  problem of shipping software, specifically... The vision for Docker, the vision of Solomon Hykes  for Docker, was always to be about building tools   for mass innovation. Back then there was already a  lot of frameworks languages that allowed engineers   to build stuff on their own in their own basement  and do something that could really, really matter,   but the next step was really getting those  things into production in a way that would scale. You know, to the Google scale or Uber  scale and those things were not accessible   to anyone. Really, this was really the unfair  advantage of any sizeable company that had the   expertise to run this kind of services at  scale. And this was the idea behind Docker.

I also get this other question which is basically,  'what the hell is a container? why should I care?'   Before Docker many companies  knew about containers,   but that was kind of the secret  sauce. It's the kind of stuff that   the 90% of engineers would never know about,  but it actually was running the big names.   It was it was running under the hood at  Google, at Heroku, at all those companies. Google for example have been using  containers for, I don't know,   15 years and they had this system called Borg  that was actually the inspiration for Kubernetes.   What I think was really unique at that time is  that Docker Inc, created Docker and it made this   technology of containers so accessible,  so easy to use with immediate benefits. The whole idea was, 'how can we build the OS  that will allow people to program the cloud   in a way that abstracts away  the differences? In a way that   basically puts all the power in their hands,  without having to bother with the hardware?' What Docker did that was innovative was  it took all those different mechanisms you   needed and kind of bundled  it up into a single tool   that you could run locally, or you could  run it in a data center or in the cloud.

For me, coming from the configuration management  world, treating infrastructure as code but without   the right abstractions, and you see Docker for  the first time, you look at that container image   as a universal solution to the building  and packaging of an application problem. Docker succeeded in bridging  the gap between dev and ops. It's a tool that had attracted both people with an  ops background and people with a dev background,   and that was, I think, something  that was very very new.

Docker containers totally changed  container technology. People's   perspective on container  technology. It used to be like,   some bunch of the nerds had to create  something, and now it's kind of,  'oh it's so easy to use and we  can deploy,' but what's next? As Docker was catching up success, commercial  interest all over the world started looking   at this. Why? Because we were starting to gain  the mindsets of the engineers both dev and ops. Docker gathered a lot of momentum. It presented  a developer experience that was really unique   and really clean and really  simple, and so you couldn't   read Hacker News on any given week  without finding some article on Docker.

As we started looking at technologies like Docker   we were like impressed by the strength of  what they'd accomplished in solving a very   specific problem which was packaging  up software and making it accessible. But just having a recognition or a realization  that a lot more was going to be required, that,   as we thought about this future  of being able to start creating   more progressive ways of organizing,  operating and managing workloads,   there was more there. We didn't know  what it felt like yet. We didn't know   at the time what it really meant, but  we knew there was something there. What a incredible year. It is really hard  to believe how much has happened in the past  

year. I feel really privileged to be at a company  that is changing the world, making a huge change. So solomon, I think we're on to  something. I think it this is good How do you explain containers? Yeah, so if you take some real  world examples around us...

Let's say, the holidays are coming up and you want  to ship something to a loved one as a present.   So let's invent the post office. And the post office says: 'we can ship things,  but we don't want you to bring loose things   to us. We don't want loose books and jewelry  and money. No no. You need to put in a box.' So if we extend this analogy,  let's put an envelope.

Now there's going to be a cost for me  to move this from one place to another,   and depending on how far it is and how  much it weighs, I'm gonna give you a price   and you can think about that like your stamp. Now, whatever you put inside of it is up to you. So the container can support  any programming language. Ruby,  

Python, Java, Golang, it doesn't matter. To make Kubernetes efficient as the post  office, we need to ask you to put it in the box. Now, the key is you now have to describe where  it needs to go. We need to put an address on it.

Where does it run, who's it destined  for and how long would you like   to take, or are willing to  wait for it to get there? And so, if you think about it, the post  office abstracts all that away from you.   You show up with your envelope  and your stamp and the address,   and they'll tell you, 'well, this  will get there in two or three days'. Planes can break down. Cars can break down,   but no one at the post office calls  you when any of those things happen. They make a promise to you, right? They  promise that this letter will get there   in two days. How they do it is not a concern.   So Kubernetes is built on this thing  we call 'promise theory'. Even though  

you have lots of machines in your Kubernetes  cluster, any of them can break at any time, but Kubernetes' job is to make sure that  application is always running, just like the   post office's job is to make sure that letter  keeps moving until it gets to its destination. Kubernetes does that for infrastructure. We abstract away all the details and allow  developers to just put their app in a box,   give us an address and, if they can  afford the postage, we'll run it for them. I don't think Kubernetes was  possible without Docker. 100%.

If Solomon hadn't done that demo in 2013,  if Google hadn't needed to catch up to AWS,   if core OS hadn't believed that, you know,  Linux needed a good kick to the cloud,   if Red Hat hadn't needed to think  about what comes next after Linux... There's a lot of what-ifs. It looks inevitable in retrospect. It did not feel  that way at all, throughout the entire process. So Google getting into cloud was an  interesting experience in and of itself,   and the story of cloud has really  been answering that question of,   'Now what? Now that I have a machine,  how do I make that machine useful?' With all of the containerized platforms, with  Borg, that have been built up for so long,   we knew that there was a better  way to offer developer platforms. If we built the orchestration technology  that would enable you to build real-world   distributed systems, as Docker was  becoming a well-used and well-known thing, we could create something quite  powerful and for me it was really just   perfectly. I'm always more the business guy. I  was always more the business voice in the room   but a recognition that we needed to  disrupt that, for us to be able to   make inroads against Amazon's leadership  in the sort of raw computer space,   and that sort of strength of ecosystem, I really  knew we had to find that - that innovation   step that would allow us to bring something  to market, that we didn't have to control   but that we could really make shine on Google's  kind of more sophisticated infrastructure.

Our idea was you know, can we create a  Borg-ike system in a way that applies to cloud? And the question there was one question around,  do we use Borg itself or do we do something new, or do we adapt an open source project that's  already out there, something like Mesos? We're playing with these ideas around what  container orchestration would look like. We were   playing with the idea of Docker. One of the key moments, the most distinct moments  in my mind at least, was asking Brendan to just   put together a little demo, because he was such  a a fast mover. Like, Brendan could, you know,  

you could ask him to do something and the next day  he'd come back and you know something would exist. I'm Brendon Burns. I'm one of the co-founders  of the Kubernetes open source project. I think Brendon is a creative genius. Like  if you spend two days with Brendan, he will   throw off 10 ideas any of which could actually  change the world. Like he's a very creative soul.   Brendon stitched together something  which I looked at and I was like,   'holy smokes you've created a personal Borg cell'.  It was just scripts and whatnot, but I could feel   it at that point. And for me that was that moment  of recognition that there was something here.

We started working together on these ideas and   you know I don't know which of the two  it was that had the crazy idea of, like,   well what would it look like if we  built this as an open source technology? What if we actually built the  whole orchestration system   as an open source project? What if we made  that the thing that people could then deploy   and use? What if it wasn't only available  on Google but was available everywhere? Building a community via open source was going to   be our best way to essentially  establish a de facto standard. I just wanted an opportunity to put  forth an open source community that would   generate a lot of attention  and garner a lot of support   and then I wanted to be able to  run it better than anyone else. I wanted to build out you know GKE as being an  industry-leading destination for workloads, but I   knew that the preconditions for media having some  success there were to get the whole programming   model accepted by the industry, really garner  innovation and strength around the the technology.   The idea behind open source is the fact  that everything should be available for   anybody to go ahead and use and,  more importantly, also to modify. Let's say you buy a piece  of software off the shelf,   right? You go in and you buy,  like I don't know, Angry Birds.

Then you're like, well I kind of love the game,  but I would like there to be another bird. I want to, I'm going to write my  own bird. I'm going to call it   Jigglypuff. Okay great, that's a trademark.  That's Pokemon, I think, but anyways,   I want to go and add another bird into the  game, right? And you really can't do that   because you basically buy the software,  you buy the right to use the software.

With the open source, right, that's where  the developers sit down and write the code,   right? That is what makes the software go. And so with the open source the  idea is that anybody can go ahead   and, you know, download or get the source  code, and then they can also modify it. Many times, especially in the  thriving open source projects,   there's a lot of contributors who  actually work on that all the time,   so it's not just like, 'okay, well  here's the software. It's done,' right? There might be bugs. There might be  new features you want to put into it,  

so these contributors then come together and they  go ahead and improve things all the time. So the   open source basically means that you have  the ability to view and modify the software - you know the source code, right,  again, what makes it software - and then be able to go ahead  and use it however you see fit. An interesting thing to understand  is each of us brought our own kind   of vision and goals to what we were trying  to do, and also our own ideas and proposals.   So there was an initial prototype. It was just  Brendan, Joe and Ville that worked on that.   Yeah, so those three of us hacking on it.  So Joey and Brendan there's only so much,   you know, three developers can do so we're kind  of like showing it around the company, just kind   of like getting some feedback on it. Like, 'what  do you think about this one? Take it for a spin'.

The Mountain View team was where Borg was  centered, and the Seattle team is where cloud   was centered, and so we started communicating on  a regular basis and bringing the unique experience   of the cloud folks, who know how to build that  product and work within that technology stack, and   the unique experience of the Borg people, who knew  how Borg worked, and meld those things together. We did need to have a credible plan   for a cloud product, thus we needed  a credible plan for differentiation,   and we needed to assure management that  we weren't enabling the competition. The Seattle folks had written this  prototype that they called Seven - and it was it was a very much a prototype - going to someone like Urs and saying, 'we want  to open source this'. Urs is very analytical.   He said, 'why? What do we get out of this? What  is the advantage that this brings to Google?'   and so his initial response was,  I don't think we need to do this. We, you know, we went through a series  of reviews with the executive team   where we pitched and they were,  like, 'you're crazy. You're crazy.' Getting a big company like Google to do something  new is always really difficult. Things work on  

sort of, like, well, we'll have a meeting next  week. We'll have a meeting the week after. It was stressful because you're, you know,   it's obvious. It was obvious to the  three of us what needed to be done. There were new projects, new ideas, coming  out every week and so there's this real fear   that if we didn't get on this, if we didn't get it  out there, then the world was gonna pass us by and   we're gonna be trying to adapt to something  that we didn't have a lot of influence on. Leadership of course had  real concerns about Google   funding our competitors through open source. We knew what we could accomplish if unlocked to  do this. There were a couple of kind of points   in time I think that were really important  you know for the success of the project.

One was a bus ride. We were doing an offsite summit with  a lot of the leadership group around   Google's technical infrastructure teams, and had   a chance to address the team around  you know cloud and what it meant etc. Ironically on the way back, I  was sitting behind Eric Brewer   and you know I was basically just  framing up what we were trying to do. Craig and I were discussing this  on a bus ride from an off site   at least the beginning Kubernetes felt too  core - like too precious to open source - so I would say the starting position was no.

I was, like, you know this is the vision,  this is what we can accomplish, et cetera,   and he got it. Like, he got it quite deeply. One of the big reasons to open source it is  this change in the industry that we want,   which is to shift the agenda of cloud - huge agenda - Google is not big enough to  do that by itself to pull off. To pull off that agenda, you have  to have a lot of fellow travelers,   right? And open source is the way to do that,  if you can get people to actually participate.

We hadn't yet got to a point where there  was a sort of critical mass of influential   individuals that got it enough to dissuade  the kind of consensus of the executive group,   and at that point it really looked like Google  wasn't going to okay it. It really looked like,   you know, there was too much uncertainty about  what this whole open source thing would mean   and how were we gonna monetize it by  the end of it. Like, it was funny. Like   we put together the sort of last final attempt  and we were gonna have a meeting with Urs down in   Mountain View, and I was at a point where I was,  like, 'look, I'm not even in travel for this.   Like I know how this is going to go,  so I'm going to be in Seattle. I'll be   providing moral support.' I think actually  Brendan led the conversation with Urs. Brendan and I flew down there to have a  meeting with some of the senior leadership and,   if I remember correctly, there  were two other folks in the room: the decision maker at the time  which was Urs and another VP,   who was pretty, pretty senior. And that VP was  very much against us open sourcing this stuff.

I was actually on the video conferencing session  and i saw Urs just like playing on his, playing on   his phone for most of the talk, and I was like  holy smokes. We actually, like, we've got it. There was a turning point in the meeting where  it's clear that you know Urs was going to do it.   If he disagreed with us, he'd be like educating us  like you know telling us why he disagreed with us.   And so I did not see that one coming.  It was a pretty high moment actually.   We were surprised and we were able to  get it out there. And then afterwards,   you know, we don't get that  much sun up here in Seattle, so   it was nice to be able to go and relax in the  sunshine and just you know think about, okay,   now what do we do and start that whole planning  phase now that we got the the okay to go ahead.

Finally. It's such a right thing  to do that I think it was just   more of a relief where I was like, 'okay, good.' We got the go-ahead to open source it and   then we had to scramble to actually get  the thing ready and get it out there. Once our plans were relatively concrete,  we needed approval relatively quickly   or to be able to launch at Dockercon. It took us about six months to  get approval and then we had about   three months between approval and  actually announcing it at Dockercon.

By the time we actually had it  announced, we had 27 Googlers'   fingerprints on it. Actually took us less time  to build the dot one release of it than it did   to get approval to release it. We may have been  working on it a little bit before we got approval,   but I think we formally had about  seven people assigned to the project,   but it was sufficiently exciting that  people just wanted to participate. We needed more people to join on so we  reached out around our organization found   some some people who were loose, grabbed  them, brought them into the project.

We just got excited and everyone  just jumped in to do the development. Now it was time to actually start  getting the thing ready to release, so   we did a rewrite of the of the thing in Go.  And then some of the early work that we did   was creating a declarative layer on top  of Docker that was written by Tim Hockin   and that was part of the scramble of  getting stuff ready for Kubernetes.

As you all know, the hardest problem  in computer science is naming, right? So here we are, again, we have this project that  we're trying to name it and yada yada yada... So Seven M9 is basically a spin-off of Borg,   right, because again we were looking  at the the kind of user experience. It was impossible to release with that name.

Honestly we were desperately looking for a name  and it was Craig, I think, said he was driving,   and with the steering wheel, and was like  you know, 'hey maybe there's some sort of   other language for you know "pilot" or   somebody "steering". And we ended  up picking Kubernetes out of that. Kubernetes. Kubernetes. Kubernetes was the name that came out because it  ticked all the boxes in a sense that if you're   punching Kubernetes into Google at the time,  it's not like you're going to get a lot of hits. Early on Tim Hockin actually  created the Kubernetes logo.   We asked our marketing department, they're  like, 'open source? We don't give a crap,   just do whatever you want.' I think they  used more colorful language than that. And so Tim, who actually has a degree in  graphic design I believe, actually did the logo.

So we were off to the races.

2022-01-23 13:00

Show Video

Other news