Introduction

In my previous post,  Working with kubernetes configmaps, part 1: volume mounts, I discussed the mechanisms for loading kubernetes configmaps from volume mounts within a container, and how the method used to create a configmap would translate into how the data would be presented.

In this post, I am going to discuss a specific strategy for handling configmaps, namely, using a watcher. Kubernetes API resources all support a  watch feed, which allows API clients to monitor resources in which they are interested, be informed of changes, and then act accordingly (in whatever manner they wish). The client code monitoring such a resource is thus the watcher here, and in the following discussion I am going to show some specific examples of using watchers to handle configmaps much more dynamically than is generally possible when consuming them via volume mounts.

Before we go any further, let me make clear that you absolutely can implement a watcher for a mounted configmap. The  kubelet keeps the mount updated (with some slight delay, up to two minutes in a default configuration), and you can certainly monitor files within the mount filesystem for changes just as you would any other file.

But one of the core patterns that using kubernetes (and even more so with knative in the mix) encourages is event-driven programming. Whereas monitoring a file for changes is more of a monitoring problem — the watching code has to know the state of the file, then essentially poll the file for any changes. Has it gotten bigger or smaller, or has a computed checksum changed, for example? In an event-driven model, the client takes more of a passive role — “I’d like to hear about any events, you just let me know when they occur.” This lets us write simpler, lighter code and focus on the problems that we really care about, not on how to detect e.g. changes to a resource of a given type.

Fortunately, kubernetes (as noted above) provides support for an event-driven model natively, and using this model for consuming configmaps lets us write code that is not only simpler than that for monitoring changes to a file, but also more robust and fault-tolerant. In this article and a subsequent one, I am going to demonstrate three examples of how to do this — the first, covered here, will be using the standard  kubernetes client library for golang, the second and third (to be discussed in the next article in the series) will be using different parts of the  knative configmap package I used in part 1.

#golang #configmap #kubernetes #go