Kubernetes and Openshift Operators
Operators are the very good mechanism to extend the capabilities of Kubernetes or Openshift.
They are the software extensions which helps to encode any business logic or custom needs into any existing Kubernetes clusters. It increases the functionality of a Kubernetes Platform without modifying the code of Kubernetes itself. Basically Operators enables us to Create, Configure and Manage our application in Kubernetes Environments as per need of a specific domain.
There are many ways operators can help us automate in a Kubernetes Environment such as:
- Deploying and scaling applications on demand.
- Handling application upgrades along with relative changes such as Database Schema or some ConfigMaps
- Publishing a service to application to achieve the app discovery that even doesn’t support Kubernetes Api .
- Simulating any kind of failure scenario throughout the cluster to test the resilience.
- It also help us to eliminate manual intervention which required at operations part which means no personnel is required to perform backup, restore, upgrade or any other Day 2 Operation.
Below is the Overview Architecture which represents common components in an Operators no matter in which language they have been developed.
Operator
The Operator defines the extended functionality of application running on Kubernetes which consist of Operator Pattern. These pattern are used by Kubernetes for Custom Resource. Operators contains business logics and custom resource definitions to manage these resources. Operators are deployed as containers in Kubernetes Cluster.
For Production environments operators are deployed using Operator Life Cycle Management which handles and manages operators for versioning and upgrades and are packed in Cluster Service Version (CSV).
API
API refers to Custom Resource Definition which have schemas and multiple versions. This allows to manage resources as declarative form in Kubernetes Production Environment. CRD(s) are identified by their group, version and resource name. One operator can have multiple resource definitions.
Manager
The Manager contains main business logic to manage and deploy custom resources. Along with this it comes with generic built in functionality to manage HA leader election, export metrics for monitoring, manage Webhooks and its certs and sharing the events. It also provides a client to access Kubernetes and a cache to improve efficiency
Controller
The controllers are responsible for managing the sync between state of Kubernetes Clusters and state of Custom Resource Definitions. It includes update, create and delete of resources. The controller logic is implemented in its reconcile function. One controller can manage one custom resource definition and all of its versions. It uses caches and Kubernetes clients to get access to the events by filters applied to it.
Webhooks
Webhooks inhances the capabilities of resources as it can be used to change the values of resources and migrate to the versions to be used.
To learn more about operator patterns and best practices, check out the repo operator-sample-go.
