 A major architecture change in OpenShift 4.x has to do with Kubernetes operators. Operators are not only used to deploy and manage stateful applications, but also to set up and manage OpenShift cluster itself. In this session, we will understand the use case for operators, how to extend Kubernetes, and then see how they are used in OpenShift 4.x cluster. Let us understand the use case first. Let us say an application deployer, mostly application operations person. Deploy is a complex or stateful application into a Kubernetes cluster. We may be able to use templates or health charts or some scripts to automate initial deployment. The application gets deployed for the first time, but how do we manage changes to it? So how do we update or patch for changes? How do we back up any data? How do we deal with lifecycle management, version changes, et cetera? All these are manual tasks that require application operations team to know how to manage the app moving forward. And when it is manual, we also know that it is all error prone. How about if we take all this operational knowledge of these applications and put them into code? This is exactly the use case for a Kubernetes operator. So an operator represents human operational knowledge about an application codified into software so that the application can be managed automatically with Kubernetes itself. And in order for Kubernetes to manage the app, operators are built upon the core Kubernetes concepts of resources and controllers. So what are these resources and controllers? Resources are objects like pods, config maps, in a Kubernetes cluster, or in case of OpenShift, additional object types such as route, build, et cetera. Resource controllers, on the other hand, are the ones that act upon and manage these resources. As an example, a deployment or a deployment configuration in OpenShift manages the pods to be created for an application and their configuration as well. A replication controller manages how many replicas should be run at any point of time. So if the number of instances go down, it will make sure that those many number of replicas are always running. A daemon set ensures one instance per node, et cetera. So these are different kinds of controllers. So resources are the objects and controllers encompass logic on how to manage these objects. Entire Kubernetes architecture and also OpenShift are built around these concepts. Commands like kubectl can access Kubernetes objects like you can get the list of parts or you can use short form notations like cm in this case for config map. In the same way, OpenShift CLI, which is OC, understands OpenShift objects like routes in addition to the other Kubernetes objects. But how about you want kubectl or OC to understand your own resources? Perhaps you want to create your own kind of database and you want kubectl or OC to understand it. So if you say kubectl get your own type of database, let's say fancy DBs or kubectl get geeky datastore or whatever you have. If you use kubectl commands on these, Kubernetes will say, I don't understand what you're talking about. So can we extend Kubernetes so that Kubernetes can understand these custom resources that we create? Welcome to custom resource definition or CRD. CRD defines a custom resource of your choice and let's Kubernetes know that you should now understand this new resource. You just create a CRD with this kind of a simple definition for fancy DB, let us say. Note that this definition includes singular plural and even the short names and we are also defined the kind and creating CRD is as simple as running a kubectl create with that YAML. Once you define a CRD, if you try to access that resource, Kubernetes will not complain anymore that I don't know this object, but instead it says, I don't have any resources with this name fancy DB. Remember, so far we only defined a CRD with that kind fancy DB, but we did not create any resources of that type. Now we create custom resources. Let us say we create a CR called silly app DB of kind fancy DB that we defined a CRD for earlier. You can create any number of resources of type fancy DB. Once you create a CR, if you inquire now it will list the CRs. So with custom resource definition, we just added a term to Kubernetes vocabulary, but we did not tell Kubernetes what to do when a resource of type fancy DB is created. Now that is our logic for fancy DB. So now if you go back to our discussion on Kubernetes resources and controllers, just like how Kubernetes resources are managed by Kubernetes controllers, we need these custom resources to be managed by custom controllers. This custom controller should know not just a crud operation for our fancy DB, but also how to handle failure recovery backup restore storage management and things like that. Operator is such a custom controller. It observes the current state creation of a CR and knows the logic of how to spin up pure application. So it observes the current state, analyzes the current state to the desired state that is defined by the CR and acts to meet the desired state by creating or updating the application. The logic of how to create or update the application is provided by whoever writes the operator. All the human operational knowledge to deploy or manage an app will be codified into this operator. Operator itself runs as a pod on a Kubernetes cluster and interacts with Kubernetes APIs to manage this application. Operators can handle any level of complexity. You could just have a basic operator that just deploys an application or a little bit better one that will manage upgrades or a full lifecycle operator that can handle backups, failure recovery, etc. Or you can even go for complex ones that can manage your application based on the metrics that are that it can collect. So there is a maturity model for operators itself. Operator SDK is a tool provided by Kubernetes operator framework. This is an open source project using which you can generate scaffolding code that deals with Kubernetes API interactions and the developer for these operators, the person who writes this operator can write their custom logic into that generated operator scaffolding code. Currently the operator developer will create a container image for an operator and make it available for others to use. Currently operator SDK supports three kinds of operators a helm operator for creating operators for Helm charts for those who are used to writing Ansible playbooks. There is an Ansible operator and for those who are who want to write complex operators with go code you can use a go operator vendors because the industry are all aligning behind operators. There are several operators created by software vendors. If you go to operator hub.io, we can see several such community operators from different vendors. We also have red hat certified operators. As I said at the beginning, OpenShift 4.x is completely rearchitected to work with operators. There are two kinds of operators that we can think of at a broad level. You have operators that are managed by an operator lifecycle manager or OLM for short to deploy applications that run on OpenShift. These include all vendor provided operators and the operators that we can write for our own applications and expose to others in the organization to consume them via OLM. The other kind of operators are the ones that are used to manage OpenShift as a platform. The OpenShift platform itself is managed by operators and these are called platform operators and they manage the cluster and the cluster upgrades. So back to a cluster that we created earlier, OpenShift integrates with operator hub by default. You can see a bunch of different kinds of operators and there are red hat certified operators too. So while vendors provide their operators, they can also get them certified by red hat. See how easy it is to install an application using an operator. We will install Eclipse J using its operator. I'll create a project, name it J. Go to operator hub, search for Eclipse J. This is a community operator. Let's install it. We are installing this operator into a namespace called J and click on subscribe. It shows that the operator installation has succeeded. Now let's go and check the workloads. We will see an operator pod running. This means that now we installed an operator and the custom resource definition CRD for J is also added when this operator got installed. Now that we have the operator installed, let's create an instance of Eclipse J and this is the custom resource. The kind is J cluster. This is the CRD that we are referring and we are passing a bunch of parameters to Eclipse J on this cluster. So I'll create the CR. It will take a few minutes for this application to be installed. If we look at the running pods now, it is spinning up a PostgreSQL database. The PostgreSQL database acts as a data store for key cloak that provides SSO functionality for Eclipse J. So even SSO is getting installed and once SSO is ready, the J operator will go ahead and install a DevFile registry, a plugin registry and the J server itself. So the J operator is smart enough to understand what to install first. So it's spun up a database first and then the SSO server and then the other dependencies that are required for the J to start running. Not just that, if any of these systems need to be upgraded, the J operator will automatically handle the upgrades as well. So this gives cloud data functionality for your applications running on the cluster. So you are just doing a click button install of the software that you want rather than going via a user manual to understand the dependencies and what to install first, how to make the resources available and all those whole nine yards. So the life of the operations person is significantly simplified due to operators. So right now Eclipse J is up and running along with all its needed components and it is managed by the J operator. Let us now look at the platform operators. If we go to administration and look at the cluster settings, there is a list of cluster operators here and everything that runs on the cluster by default, whether it is the web console or a registry or ingress or any of the Kubernetes and OpenShift components are all managed by these operators. Now, if we have to upgrade the cluster, these are these operators will manage those upgrades and the custom resources that are managed by these operators are all here in a different video. We'll look at how the cluster upgrades are done. So to summarize, we have looked at the use case for operators. We understood the architect. We understood what custom resource definitions are, what custom resources are and how operate manage the custom resources. We also looked at how OpenShift users operators, not just to deploy applications, but to manage itself. I hope you enjoyed this video. Thanks a lot for watching.