ConfD Startup and Supervision with Kubernetes App Note

Community

You’ve dipped your toes in the Kubernetes pool and have a good basic knowledge of how to leverage containers. Now is the time to dig a little deeper and understand some of the more advanced applications and use cases with Kubernetes. When it comes to network programmability, we can help expand your knowledge on the use of ConfD within Kubernetes.

I just wrote the “ConfD Startup and Supervision with Kubernetes” application note to help you better understand the tools Kubernetes provides for managing initialization, startup synchronization, and supervision of ConfD and the applications that rely on ConfD for configuration.

The first concept we look at is InitContainers which is used to initialize ConfD and to synchronize startup of client pods with the ConfD pod. InitContainers run once (to completion} before any other containers in a pod are started. If a pod has multiple initContainers, each container must complete before the next initContainer is run. When they are all done, any application containers can then run. In this application note’s example, there are two initContainers. The first initContainer is in the ConfD pod and copies the AAA initialization from a configMap to the CDB volume where ConfD will read it as usual during startup. The second initContainer is in the client pod and waits for ConfD to start at which point it returns allowing the application container to start.

We also show how Kubernetes’ readiness and liveness probes can be used to check that ConfD has started properly and is ready to accept client requests and is working properly respectively. Failed readiness probes make the service provided by a container unavailable (without restarting the pod) while a failed liveness test will cause the container to be restarted.

Finally, Kubernetes provides handlers associated with the creation and termination of containers. postStart handlers run immediately after a container has been created and preStop handlers are invoked before a pod is terminated. preStop handlers are most interesting for use with ConfD and allow us to make a controlled shutdown of ConfD using “confd –stop” rather than the default method of sending SIGTERM (or even SIGKILL) if ConfD doesn’t stop in time.

Off-loading cluster management tasks to initContainers, probes, and handlers like we do in this application note greatly simplifies the applications themselves since they only have to deal with the actual functions they are supposed to perform.

Download your copy today!

Leave a Reply

avatar
  Subscribe  
Notify of