content_image/728592.jpg
Initial version 

<img src='content_image/728592.jpg'>

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. 

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 ] 

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. 

curl -Ns $base/api/v1/${ns}/configmaps?watch=true | \ while  read -r event do type= $( echo "$event" | jq -r '.type' ) 

