Abstract: Operators have been an important part of the Kubernetes ecosystem for a number of years. By moving the administration surface into the Kubneretes API they facilitate a “single pane of glass” experience. For developers looking to streamline their Kuberentes-native applications, or devops practitioners looking to reduce complexity of existing systems, operators can be an attractive proposition. But how might you construct an operator from scratch?

Operators in Depth

What is an Operator?

Operators are everywhere today. Databases, cloud native projects, anything that has a complexity to deploy or maintain on Kubernetes is getting one. First introduced by CoreOS in 2016, they encapsulate the idea of moving operational concerns into software. Instead of runbooks and other documentation, the operator performs actions automatically. For example an operator can deploy instances of a database, or upgrade database versions, or perform backups. These systems can then be tested, and be relied on to react faster than a human engineer could.

Operators also move the configuration of tools into the Kubenretes API by extending it with Custom Resource Definitions. This means that Kubenretes itself becomes a “single pane of glass”. This lets devops practitioners take advantage of the rich ecosystem of tools built around Kubernetes API resources to administer and monitor their deployed applications:

• Change authorization and authentication with Kubernetes’ built-in role-based access control (RBAC).
• Reproducible deploys and code review for production changes with “git ops”.
• Policy enforcement over custom resources with security tools based on Open Policy Agent (OPA).
• Streamline describing deployments with tools like Helm, Kustomize, ksonnet, and Terraform.

This approach can also ensure parity between production, testing, and development environments. If each is a Kubernetes cluster, then an operator can be used to deploy the same configuration in each.

Why would you want to build one?

There’s lots of reasons to build an operator from scratch. Typically it’s either a development team who are creating a first-party operator for their product, or a devops team looking to automate the management of 3rd party software. Either way, the development process starts with identifying what cases the operator should manage.

At their most basic operators handle deployment. Creating a database in response to an API resource could be as simple as kubectl apply. But this is little better than the built-in Kubernetes resources such as StatefulSets or Deployments. Where operators begin to provide value is with more complex operations. What if you wanted to scale your database?

With a StatefulSet you could perform kubectl scale statefulset my-db --replicas 3, and you would get three instances. But what if those instances require different configuration? Do you need to specify one instance to be the primary, and the others replicas? What if there are setup steps needed before adding a new replica? In this case an operator can configure these settings with an understanding of the specific application.

More advanced operators can handle features like automatic scaling in response to load, backup and restore, integration with metric systems like Prometheus, and even failure detection and automatic tuning in response to usage patterns. Any operation that has a traditional “runbook” documentation can be automated, tested, and depended on to respond automatically.

The system to be managed doesn’t even need to be in Kubernetes to benefit from an operator. For example major cloud providers such as Amazon Web Services, Microsoft Azure, and Google Cloud provide Kubenretes operators to manage other cloud resources, such as object storage. This allows users to configure cloud resources in the same way they configure Kubernetes applications. An operations team may take the same approach with any other resources, using an operator to manage anything from 3rd party software services via an API, to hardware.

#kubernetes #cloud #kubernetes operator #architecture & design #development #devops #article