20 Extending Kubernetes with custom resources and Operators

 

At the heart of Kubernetes is a highly available database and a REST API with a consistent way of working with objects. When you create a Pod through the API, the definition is stored in the database, and a controller is notified and knows that it needs to allocate the Pod to a node to get it running. It’s a generic pattern where different controllers work on different types of objects, and it’s extensible, so you can add your own resource definitions and your own custom controllers to act on those resources. This may sound like an obscure topic, but it’s very common for products to extend Kubernetes to make the product itself easier to use. It’s also a straightforward way to customize Kubernetes to make it work better in your organization.

Custom resources and controllers can hide a lot of the complexity in an application, and in this chapter, you’ll see how to define and work with them. The definition part is simple, but controllers need custom code. We won’t focus on the code, but we’ll have some examples of customizations so you can see what they can do. We’ll also cover the Operator pattern in this chapter, which is a way of using custom resources and controllers to automate the deployment and the ongoing operational tasks of an application.

20.1 How to extend Kubernetes with custom resources

20.2 Triggering workflows with custom controllers

20.3 Using Operators to manage third-party components

20.4 Building Operators for your own applications

20.5 Understanding when to extend Kubernetes

20.6 Lab