 Hi, Red Hat developers. This is Jason with the Red Hat Developers Program. This morning, we're introducing John Osborn from Red Hat. He's going to be talking about Kubernetes, Past, Present, and Future at Summit 2017. All right, everyone, thank you. This lightning talk, I'm going to focus around Kubernetes, Past, Present, and Future. So what really what that means is I'm going to focus on how we got here. So Google really shook up a lot of people when they said a couple years ago that they've never run virtual machines. They've been running only containers at scale for the past 10 years. And when they spun out Kubernetes, Kubernetes is really their third orchestration management tool. So I'm going to focus a little bit on the Past and Present on the lessons learned by Google into creating Kubernetes, what they learned out of their first two systems, Borg and Omega, the types of things they did well, didn't do well, how those rolled into Kubernetes and how we got here today, what the community is doing on top of Kubernetes now, and kind of where it's going, integrating with things like the Open Container Initiative and the Open Service Broker API, things like that. So first, we're talking about containers. And many people don't realize, but containers really aren't new. The first container technology really came around, you could argue, even 20 years ago, with Change Root. And most people are all familiar with that. Even today, a lot of people use Change Root to break into their Linux or Windows machine if they need to change the password, for instance. But each time, the technology iterated more and more. So BSD introduced a lot of concepts around isolation of the namespaces and PIDs. Solaris had Solaris zones. Fast-forward C groups is actually a technology most people don't realize came out of Google. So one thing that Google did was that they realized they were trying to eke out all the performance they could. Because when you have a minor performance problem at scale, that becomes a very large problem. So C groups was designed to isolate resource limits. So at Google, for instance, when you go spin up your Gmail, that actually is spinning up a container in the back end. But they also have a ton of batch processing jobs. So they want to be able to run batch processing. And your Gmail container on the same physical server without having any latency or interference or basically denial of service attack on that container. So Google came out with C groups. They open sourced it. That came into Linux kernel. Red Hat, of course, has worked on almost all the Linux namespaces at this point. And I think there's eight of them total. IBM contributed with LXC. And then the initial release of Docker, most people don't realize, it actually just took LXC and built a format and API and a runtime on top of that. But it was really actually just connecting into the LXC, which was the first open source kernel, the Linux container, that first open source Linux container back in 2008. Since then, Docker has re-architected into several other components. And LXC is actually not a part of it. But their initial release was based around that. So in parallel to that, Google, as I mentioned, has been running just containers in their data center. They've never run a virtual machine. So before Docker, they were using just containers called, if you're familiar with that, there's a website called LetMeContainerizeThatForYou. Or LetMeGoogleThatForYou, which is if someone asks you a silly question, you can send them this link and you click on it. And then it'll Google the thing that they should have just looked up on Google in the first place. So they actually had their own container format called LetMeContainerizeThatForYou, which is based around that joke. But they have been running containers at scale, and they learned a lot of important lessons learned in that time. And I'll just go through a few of these. There's several white papers out there. And if you come to KubeCon last year, it was in Seattle, and it was a ton of fun. You get to meet a lot of the core developers that build it this year, or be in Austin in December. So I'll highly recommend if you're interested, register for it. It's a great time. It's an OpenShift Commons event, where we normally have a lot of the key developers to Kubernetes come the day before KubeCon. So you can talk to the engineers about some of these things. But they're very critical into the lessons learned, because Google, their first crack at orchestration, was called Borg. The second one was called Omega. And the third one, Kubernetes, to work with Docker, and now OpenContainerInitiativeContainers, there's lots of key things that they learned what not to do, essentially. So the first thing was they really wanted consistent APIs and object structures. And this was really important, because their first tool called Borg didn't really have a very well consistency. A lot of things grew at Hock. And by the end of Borg's lifespan, it was becoming very hard to manage. They also wanted to decouple a separation of concerns, but make sure everything shares the same building blocks. And this is really critical, because they really wanted to avoid building a large centralized management tool that we can come brittle. So the way that they built it was to essentially create a lot of different microservices that work in control loops. And why this is really important is because if the whole system crashes, so if OpenShift just crashes, or Kubernetes crashes, if the masters just go down, it doesn't matter. It doesn't have to try to figure out or pick up where it got left off. It's literally just going to start back up, and it's going to start running control groups and checks against all these different microservices. And that separation of concerns was also really important, too, because by not getting too tied into opinions, you're able to swap in and out different ideas. So for instance, within Kubernetes, there's all sorts of different ways to run containers. There's replication controllers. There's jobs. There's demon sets. By having a similar look and feel, you can learn how these things all work very seamlessly. And you don't necessarily have to worry about getting too tied in or things breaking as you go forward or as you want to make changes. Other lessons learned that are really important. So labeling the first iteration at Borg, they actually just use numbers to identify their containers. And that's not very scalable, right? Because as you do more and more containers, you need a way to group those together. So the idea of using labels is actually really important. And believe it or not, the first iteration at Borg, all the containers did not have their own IP addresses. They actually just shared the IP of the host, and they just kept changing the port numbers on their apps. So if I had a database connecting or find an application connecting to a database, I'd find out which container that database is running in. And then they needed another tool to tell the app what port number that database is running on. And then if the database died and got moved somewhere else, well, then they had some other orchestration tool or some other management tool that find out what the new port was for the database and sent that port to update the application. So it was really a lesson of what not to do. And when they developed Kubernetes, having one IP per pod is really one of the most crucial design decisions that they made. Finally, this is one that's very important, too. So everybody comes in through the front door in Kubernetes. That means nobody is accessing at CD directly. Everyone's coming in through the Kubernetes API if you're using OpenShift. So OpenShift API accessing at CD. Nobody is able to access the data store directly, because ultimately that's just going to lead to bad things. So by pretty much any objective measure right now, Kubernetes is de facto standard to run containers. I did some analysis using Google BigQuery. It's the most popular project on GitHub by just about every single measure at this point in terms of contributors and comments and stars and all those things. So it's an extremely popular project. If you use just containers by itself, there's lots of things that you don't get, right? You don't get auto-scaling. You don't get health and status and recovery. You don't get the ability to mount configurations and secrets to your containers at runtime so that your actual images themselves don't contain data that might only apply to one specific environment. And I mentioned by pretty much any objective measure, Kubernetes is by far the most popular orchestration technology out there. Now this is two or three months old now, but since then it's even gotten higher, right? So actually you can see the job postings is actually from October 2016. Every time I go to check for Kubernetes repo in GitHub, there's more contributors, there's more coders, and so forth. This was actually a study where they took the number of lines. This is pretty straightforward math, but they just took the number of lines in Kubernetes, the average developer salary, and did the math, and they came out with, if you actually wanted to create a Kubernetes from scratch, you'd need $120 million to do so. And one thing that most people don't realize is Kubernetes is actually managed by the Cloud Data Compute Foundation, which is under the Linux Foundation. And there's all sorts of companies that are now contributing projects to there. It's grown from just Kubernetes to all sorts of other projects as well, so GRPC, Influx Database, Prometheus is under the Cloud Data Compute Foundation, Container D, which was contributed by Docker, as well as RunC to run containers. These are all projects that are becoming managed by the Cloud Data Compute Foundation, and these are all different companies that contribute as well. So it was really interesting, last year at KubeCon, I got to meet a lot of people from Disney and Samsung that are actually using this running on that scale. For Red Hat, I work in the public sector, so I've actually worked with about 25 federal agencies that have adopted Kubernetes in OpenShift in some capacity. So this is a technology that, even though it's only about three years old now, it's actually because of the development and velocity of the community, it's actually been proven out there in industry. So we're all we going, so there's a few things. So one, the Open Container Initiative, everyone says, oh, Docker containers, but there's actually a standardized format now, so if you go build a container with Docker Build, it's actually creating an OCI-compliant container. The Open Container Initiative was to avoid vendor lock-in, and it has buy-in from pretty much, well, actually 100% of the vendors that are out there. So Red Hat's the number one contributor right now, Docker's the second biggest contributor, IBM contributes, VMware, and so forth. It really specifies or standardizes two things. One is the runtime, so that's how you interact with the container, and two, the format. So if I ship around a container between different machines, I know I have a standardized format that I can use. So if I use Docker Build or some other tool to create a container, it doesn't matter because I'm creating a standard OCI-compliant container. And where Kubernetes is going with Cryo, the CRI-show there, called Cryo, is a way to run any OCI-compliant container within Kubernetes, so in the first iteration of Kubernetes, they actually had custom code to run Docker containers, and then when they wanted to adopt Rocket, they had to have more custom code to hook in the Kubernetes lifestyle stuff, or lifecycle hooks into Rocket. That doesn't really scale because as you wanna move things like Intel Clear Containers or other different containers, you don't wanna have custom code that you're maintaining for every different container format. So with Open Container Initiative and Cryo, it's a way to run any OCI-compliant container without custom code. So that's what we're working on right now, we're just about there. And then you'll be able to plug in any OCI-compliant container, and Kubernetes will have to carry around custom code for specific to Docker and Rocket. With Windows Server, so that's another thing that we've been working on as well. We do have some alpha functionality right now where we're actually running Kubernetes on Windows. So hopefully that'll be more mature as the year goes on. And then the Open Service Broker API, which is actually something, an idea that came out of the Cloud Foundry space, and something that we're contributing as well, where it's basically gonna be an open standard to expose your containers inside a service catalog. And if you actually look on the Red Hat, or the OpenShift GitHub account, you can see some of the work we're doing there as well. So this is my last slide. I think, I've been working at Red Hat for four years. I think one of the things we always tell our customers is that no vendor lock-in is critical. So when you're talking about containers, or Kubernetes, you can run containers anywhere you want. And OCI, the open container initiative is very important to everything we do for no vendor lock-in. So again, that's standardizing the runtime and the format, and Kubernetes can run any OCI-compliant container, which is almost all of them at this point. The ones that aren't OCI-compliant yet are working to get there. So we think that this has a lot of benefits to all our customers. So that's all I have for today. Thank you, my name's John Osborn, and I hope you enjoyed this talk and the rest of Red Hat Summit.