tom controllers. It acts similarly to Kubernetes Controller Manager by running multi‐ ple controllers that are not hardcoded but defined dynamically through Metacontroller-specific CRDs. In other words, it’s a delegating controller that calls out to the service providing the actual  Controller  logic. Another way to describe Metacontroller would be as declarative behavior. While CRDs allow us to store new types in Kubernetes APIs, Metacontroller makes it easy to define the behavior for standard or custom resources declaratively. When we define a controller through Metacontroller, we have to provide a function that contains only the business logic specific to our controller. Metacontroller handles all interactions with the Kubernetes APIs, runs a reconciliation loop on our behalf, and calls our function through a webhook. The webhook gets called with a well- defined payload describing the CRD event. As the function returns the value, we return a definition of the Kubernetes resources that should be created (or deleted) on behalf of our controller function. This delegation allows us to write functions in any language that can understand HTTP and JSON, and that do not have any dependency on the Kubernetes API or its client libraries. The functions can be hosted on Kubernetes, or externally on a Functions-as-a-Service provider, or somewhere else. We cannot go into many details here, but if your use case involves extending and cus‐ tomizing Kubernetes with simple automation or orchestration, and you don’t need any extra functionality, you should have a look at Metacontroller, especially when you want to implement your business logic in a language other than Go. Some controller examples will demonstrate how to implement StatefulSet, Blue-Green Deployment, Indexed Job, and Service per Pod by using Metacontroller only. This ConfigWatcher custom resource looks like that in Example 23-5. kind : ConfigWatcher apiVersion : k8spatterns.io/v1 Example 23-5. Simple ConfigWatcher resource Let’s have a look at a concrete  Operator  example. We extend our example in Chap‐ ter 22,  Controller  and introduce a CRD of type ConfigWatcher. An instance of this CRD specifies then a reference to the ConfigMap to watch and which Pods to restart if this ConfigMap changes. With this approach, we remove the dependency of the ConfigMap on the Pods, as we don’t have to modify the ConfigMap itself to add trig‐ gering annotations. Also, with our simple annotation-based approach in the Control‐ ler example, we can connect only a ConfigMap to a single application, too. With a CRD, arbitrary combinations of ConfigMaps and Pods are possible. Example Solution  |  197