Initial version Unique kind of this CRD Labels of the resource as used in tools like  kubectl OpenAPI V3 schema specification for this CRD For our operator to be able to manage custom resources of this type, we need to attach a ServiceAccount with the proper permissions to our operator’s Deployment. For this task, we introduce a dedicated Role that is used later in a RoleBinding to attach it to the ServiceAccount in Example 23-7. With these CRDs in place, we can now define custom resources as in Example 23-5. To make sense of these resources, we have to implement a controller that evaluates these resources and triggers a Pod restart when the ConfigMap changes. We expand here on our  Controller  script in Example 22-2 and adapt the event loop in the controller script. In the case of a ConfigMap update, instead of checking for a specific annotation, we do a query on all resources of kind ConfigWatcher and check whether the modified ConfigMap is included as a  configMap:  value. Example 23-8 shows the reconciliation loop. Refer to our Git repository for the full example, which also includes detailed instructions for installing this operator. Example 23-8. WatchConfig controller reconciliation loop Example 23-7. Role definition allowing access to custom resource apiVersion : rbac.authorization.k8s.io/v1 kind : Role metadata : name : config-watcher-crd rules : -  apiGroups : - k8spatterns.io resources : - configwatchers - configwatchers/finalizers verbs : [ get, list, create, update, delete, deletecollection, watch ] curl -Ns $base/api/v1/${ns}/configmaps?watch=true |  \  while  read -r event do type= $( echo "$event" | jq -r '.type' ) Solution  |  199