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 to watch (or  default  if not given) 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. Example 22-3. WATCH_NAMESPACE extracted from the current namespace Example 22-2. Controller script 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 env :  -  name : WATCH_NAMESPACE valueFrom : fieldRef : fieldPath : metadata.namespace 180  |  Chapter 22: Controller