An Operator is a software application written to run over Kubernetes, extending its functionalities to manage other applications and components also running on it. These applications might contain specific domain knowledge, that is, stuffs that you own and control to help your business.
By allowing the extension of its API, the creation of Custom Resource Definitions (CRD) that works in conjunction with Controllers (“pieces” of code), we can build a Kubernetes Operator.
So… Let’s do it!
The Controller it is the core (the heart) of the Operator, it’s the developed code that runs in a “looping pattern” mode, checking frequently if some desired state (defined/represented by our CRD Resources), it is reached. The Controller works to reach and maintain the desired target state of some resources that you want to manage.
In Kubernetes itself, we have available examples of native resources that are also actually Controllers, such as Deployments, Statefulsets, ReplicaSet, and Daemonsets. They are responsible to maintain/manage certain object’s states. These native resources work well for containerized applications, all of them, deal with Pods objects.
But, if we need something more… if we want something more… more control. We might need a finer and more specific domain knowledge operation, to correctly manage the state of our applications and components. Also, (why not?!) we could simply want to make some repetitive development/running process easier and transparent, to our developers/users in Kubernetes environments. That’s where Kubernetes Operators can be handy.
In summary… a Kubernetes Operator enables users to create, configure and manage Kubernetes applications in the same way Kubernetes does with its built-in resources, consequently giving them (us) more “power“.
Alright, enough talking! Let’s go through the parts of how to build an Operator.
#kubernetes