A Pipelock instance running in a Kubernetes cluster watched its config file for hours while four edits to the underlying ConfigMap landed in etcd. The dashboards showed updates. The pod showed an old config. The tests that exercised the new config kept failing for reasons that made no sense.

The problem is not Pipelock. The problem is subPath . Mount a ConfigMap key as a single file with subPath , and kubelet stops propagating updates to that mount. The behavior is documented but easy to miss, and it is the load-bearing reason any service that runs hot-reload in Kubernetes needs to think about how its config volume is mounted.

The shape of the bug

A reasonable-looking ConfigMap mount in a Deployment spec:

spec : containers : - name : pipelock volumeMounts : - name : config mountPath : /etc/pipelock/pipelock.yaml subPath : pipelock.yaml volumes : - name : config configMap : name : pipelock-config

Enter fullscreen mode

Exit fullscreen mode

The pod gets /etc/pipelock/pipelock.yaml populated from the…