Extending Kubernetes

Chapter 3. Server-Side Extensions and Primitives

In Chapter 1, we explored the Kubernetes architecture and all of the daemons that are part of the system. To extend Kubernetes, you rely on the primitives that it exposes. The ones described in this chapter are what I classify as “server size”: Shared Informers, Work Queue, and Custom Resource Definitions. I call them “server size” because they are heavily used internally by Kubernetes itself.

We use the Shared Informer to watch and trigger actions based on internal state changes. We use Work Queues to design a resilient system capable of continually attempting to match the desired state you declared even if the first attempt didn’t work as expected. Custom Resource Definitions are one of the most powerful integration points, allowing you to embed your resources as part of the Kubernetes-native one, such as pods, Service, Ingress, and Job.

Informers

A Shared Informer is a powerful and easy-to-use primitive provided by Kubernetes. In Chapter 1, you learned that Kubernetes is an event-based system because almost everything that happens emits an event: when you create, delete, or modify a pod; a service; or when a node joins the cluster; and so on. Shared Informers are designed to watch and take action based on them. The following example demonstrates a Shared Informer boilerplate that watches and logs events that happen to pods:

package main import ( "fmt" "os" "time" "go.uber.org/zap" corev1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/util/runtime" ...