 As mentioned, I'm Josh Wood, I'm a developer advocate for OpenShift and Kubernetes at Red Hat. I was formerly responsible for documentation at CoreOS, so I've had the opportunity to see my monitor decide to stop working. Huh. You know, we tested this very thoroughly. The clock also isn't running, so is there maybe actual trouble with the AV system? Yeah, that's exactly what we have to do. I was there already. Sorry, folks. Smooth is key, right? I actually have to do this by hand because control f doesn't work to give us full screen like we want. All right, let's start over for 59. I'm Josh Wood. I'm from Red Hat. I was formerly responsible for documentation at CoreOS, so I've had the opportunity to see the sort of initiation of the operator pattern there at CoreOS and to see that sort of grow up and launch a framework in an SDK around building these things since our acquisition of CoreOS at Red Hat earlier this year. So, I'm going to try to tell you a little bit about why you care about Kubernetes operators. And that's because every application on any platform has to be installed, configured, managed, and upgraded over time. I want to highlight specifically when thinking about this idea of long-term lifecycle management of applications running on Kubernetes, an old CoreOS idea that continues to be a key principle at Red Hat, and that is that patching, upgrading software, is critical to security. In the arms race we currently find ourselves in, in fact, patching is our only real antidote to security flaws as they become known. I heard something in a previous talk that I like so much. I decided to steal it. Anything not automated is slowing you down. That's exactly what operators are all about. Operators are automated software managers for Kubernetes clusters, and that means both installing and managing the lifecycle of applications running on those clusters. You can use operators right now to make deploying software and keeping it running and up to date easier. Let's say you find a killer new database that implements things in some way that's absolutely perfect for an application that you're working on, but one of the things you don't want to do is inherit a bunch of technical debt of selecting team resources to figure out how to configure that new database, keep it running, connect it to monitoring systems or to deploy it in some kind of its own cluster configuration that it may have its own notions about. That's one of the intensive operators and one of the things that makes them most useful to users of software on Kubernetes. You can also build operators today with the operator framework SDK to make your applications Kubernetes native. Why do we need this stuff? Let's take a look really quickly for a refresher at what scaling stateless applications looks like on Kubernetes. It's easy. If we have a web server or something and it's completely stateless, we just ask the controller to give us more replicas of it. It's easy to restart that application if it fails. It looks a little something like this. The controller takes a look at the real world. Does it match our desired state? No, we wanted three replicas of our stateless application running. The controller takes steps, starts some new pods and gets three copies of that thing running on our cluster. But what about those weird apps that occasionally write data or record something about their state? Creating a database is very easy on Kubernetes. Pick some database image like MySQL or Postgres, run it with a kubectl run command and you have a database running on Kubernetes. However, running it over time can be considerably harder. If you want to resize or upgrade that database, if it has its own notions of clustering, that requires a significant amount of administrator knowledge specific to that application. Reconfiguring a database in any way, the same concept applies. Backing up databases in their data stores have specific procedures and especially coordination requirements to keep the service the database is providing available while that backup goes on. And then perhaps most intriguingly, the idea of healing these kinds of complex applications, how do you restore backups? What's the data store look like? And how do you rejoin the cluster and provide authentication tokens, certificates, and other knowledge you may need of the database system's own ideas of clustering? So if only Kubernetes knew all the things that an expert human operator of that software knew, how can we teach Kubernetes all of those things? Well, we can extend the Kubernetes API to manage more complicated applications. The goal looks something like this. This is an idealized bit of YAML snippet for a database cluster. We have three members of our cluster for a cluster size of three and we know that a couple of them are read-only replicas, leaving one of them as some sort of right controller. Operators are application-specific controllers that extend the Kubernetes API, as we're just giving an example in that manifest, to manage instances of complex stateful applications on behalf of a Kubernetes user. They work by using the custom resource definition mechanism in the Kubernetes API to describe the desired state of your application so that your custom controller can take actions to make that desired state the reality on the cluster. So I'm actually going to skip ahead a little bit in the interest of time here. Databases are a great example of this. They're not the only thing that operators are about. We have some in the wild from third parties and we've seen a lot of uptake of this pattern. File storage, block storage, object storage, anything with its own notion of clustering, all common uses of operators, and especially apps for distribution natively on Kubernetes. If you take a look at Red Hat's operator framework org on GitHub, you'll find a list of awesome operators that you can use today to bring these things into your Kubernetes apps very easily and continue managing them over time. And you can build operators today with the operator SDK, which is a set of APIs and abstractions for the operational logic that goes in these custom controllers, as well as some scaffolding and other stuff to help you get started with a new project. Now that you think operators are fascinating, come here. Ryan Jarvan and I talk less quickly about them for 45 minutes or so. Tomorrow afternoon at 4.50 and rooms 116 and 17. If you have any questions, I am Joshix at Red Hat and you can also find me at Twitter. My slides will be available afterwards. Thank you very much.