Hybrid Cloud Apps with OpenShift and Kubernetes

Chapter 7. Multicluster Policy Configuration

A key aspect of Kubernetes that we’ve already seen is how it is a declarative, API-driven system. Initial support for orchestration focused purely on containers and their required support services, such as network services, PersistentVolumeClaims, and administrative policies. Now we will look at how we can generalize the underlying pattern that Kubernetes API controllers follow. It turns out, declarative management of applications is also a great way to operate the Kubernetes cluster itself. In this chapter, we will discuss the concept of an operator and how we can use operators to simplify the management of our clusters.

Configuring Your Cluster with Operators

Let’s talk a bit about how the Kubernetes system works and how you can extend the system to meet your needs.

Understanding Operators

Each API provider includes a balancing loop (pictured in Figure 7-1): observe actual system state, reconcile with desired system state, apply changes, and report status.

Such a powerful pattern led to more orchestration providers and ultimately was generalized to allow the creation of new CRDs and their responsible controllers in Kubernetes 1.16. Controllers react to the presence of new custom resources (that are instances of CRDs) or updates to existing custom resources. Controllers also interact with objects under management, traditionally containers or pods, but now the vocabulary exposed by CRDs allows for the management of stateful workloads ...