Custom Controllers
Last updated
Was this helpful?
Last updated
Was this helpful?
If we say custom resources are the instances, and custom resources definitions are the objects, then custom controllers could be the implementations of the logic behind custom resources.
The following is from the official documentation:
"On their own, custom resources simply let you store and retrieve structured data. When you combine a custom resource with a custom controller, custom resources provide a true declarative API.
A allows you to declare or specify the desired state of your resource and tries to keep the current state of Kubernetes objects in sync with the desired state. The controller interprets the structured data as a record of the user’s desired state, and continually maintains this state.
You can deploy and update a custom controller on a running cluster, independently of the cluster’s own lifecycle. Custom controllers can work with any kind of resource, but they are especially effective when combined with custom resources. The combines custom resources and custom controllers. You can use custom controllers to encode domain knowledge for specific applications into an extension of the Kubernetes API."
A go client(lib) talks to the K8s cluster, it contains various mechanisms that you can use when developing your custom controllers.
Informer reference: This is the reference to the Informer instance that knows how to work with your custom resource objects. Your custom controller code needs to create the appropriate Informer.
Indexer reference: This is the reference to the Indexer instance that knows how to work with your custom resource objects. Your custom controller code needs to create this. You will be using this reference for retrieving objects for later processing.
Resource Event Handlers: These are the callback functions which will be called by the Informer when it wants to deliver an object to your controller. The typical pattern to write these functions is to obtain the dispatched object’s key and enqueue that key in a work queue for further processing.
Work queue: This is the queue that you create in your controller code to decouple delivery of an object from its processing. Resource event handler functions are written to extract the delivered object’s key and add that to the work queue.
References:
Reflector: A reflector, which is defined in , watches the Kubernetes API for the specified resource type (kind). The function in which this is done is ListAndWatch. The watch could be for an in-built resource or it could be for a custom resource. When the reflector receives notification about existence of new resource instance through the watch API, it gets the newly created object using the corresponding listing API and puts it in the Delta Fifo queue inside the watchHandler function.
Informer: An informer defined in the pops objects from the Delta Fifo queue. The function in which this is done is processLoop. The job of this base controller is to save the object for later retrieval, and to invoke our controller passing it the object.
Indexer: An indexer provides indexing functionality over objects. It is defined in . A typical indexing use-case is to create an index based on object labels. Indexer can maintain indexes based on several indexing functions. Indexer uses a thread-safe data store to store objects and their keys. There is a default function named MetaNamespaceKeyFunc defined in that generates an object’s key as <namespace>/<name> combination for that object.
The base controller in client-go provides the NewIndexerInformer function to create Informer and Indexer. In your code you can either or
Process Item: This is the function that you create in your code which processes items from the work queue. There can be one or more other functions that do the actual processing. These functions will typically use the , or a Listing wrapper to retrieve the object corresponding to the key.
