content_image/850313.jpg
Our controller shell script now evaluates this ConfigMap. You can find the source in its full glory in our Git repository. In short, the Controller  starts a hanging GET  HTTP request for opening an endless HTTP response stream to observe the lifecycle events pushed by the API Server to us. These events are in the form of plain JSON objects, which we then analyze to detect whether a changed ConfigMap carries our annota‐ tion. As events arrive, we act by deleting all Pods matching the selector provided as the value of the annotation. Let’s have a closer look at how the controller works. 

The main part of this controller is the reconciliation loop, which listens on Config‐ Map lifecycle events, as shown in Example 22-2. 

namespace=${WATCH_NAMESPACE :- default} base=http://localhost:8001 ns=namespaces/$namespace curl -N -s $base/api/v1/${ns}/configmaps?watch =true | \ while  read -r event do # ... done 

Namespace to watch (or default  if not given) 

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

Access to the Kubernetes API via an Ambassador  proxy running in the same Pod 

Loop with watches for events on ConfigMaps 

The environment variable WATCH_NAMESPACE  specifies the namespace in which the controller should watch for ConfigMap updates. We can set this variable in the Deployment descriptor of the controller itself. In our example, we are using the Downward API described in Chapter 13, Self Awareness  to monitor the namespace in which we have deployed the controller as configured in Example 22-3 as part of the controller Deployment. 

env :  - name : WATCH_NAMESPACE valueFrom : fieldRef : fieldPath : metadata.namespace 

