Best Practices for Building Kubernetes Operators

Overview

Kubernetes operators provide a way to extend Kubernetes functionality to handle automating tasks, application-specific logic, custom resources, and so on. With operators, we can borrow many good designs and built-in supports from Kubernetes, such as declarative APIs, state-driven reconciling logic, and event informers. We can have easy-to-use APIs in the form of CRDs, where we can still use kubectl to interact with Kubernetes.

In this lesson, we’ll go over some best practices for creating and maintaining operators. Kubernetes exposes REST HTTP APIs. This means that operators can actually be implemented in any programming language, such as Go, Java, etc. However, normally, we implement using Go, so we can use various Go libraries around the Kubernetes ecosystem. This is why most developers and SRE operators use Go to implement their operators.

Best practices for writing operators

Here are some best practices for writing a good, production-available operator. Some of the points we discuss in this part describe common rules, which can be applied independently from implementation details.

1. Use the Operator SDK like the kubebuilder

Writing an operator from scratch is never an easy task, even for a very experienced developer who knows Kubernetes well. There are lots of low-level details that have steep learning curves, such as how operators work, how an event gets queued and reconciled, how the libraries are implemented, and so on. Moreover, we’re not building and maintaining a single operator—therefore, it’s not recommended to have heterogeneous operator frameworks, which would definitely bring us trouble when trying to understand each framework or debug operator issues. That’s why we suggest using an SDK to help scaffold our operator projects in the first place.

There are also some other SDKs or frameworks to scaffold an operator ...