Getting Ready for Day 2 with Kubernetes Operators

Traditionally, organizations found it difficult to deploy stateful data services on Kubernetes since it required manual intervention. Operators are powerful design patterns that help deploy stateful data services on Kubernetes and manage application lifecycles, taking Kubernetes to the next level of orchestration. 

 

In order to create a production-level operator, developers often find themselves writing tens of thousands of lines of code. Writing, managing and implementing gobs of code is a cumbersome and often unforgiving exercise. Writing an operator requires deep understanding of the underlying service and Kubernetes. Although the data service operators for Kubernetes and the underlying service share commonalities, they must accommodate significant implementation differences due to different orchestration concerns. What organizations  need is a set of operators packaged for easy deployment and management on any Kubernetes cluster.

 

To Helm or not to Helm?

While Helm -- the first application package manager running atop Kubernetes -- excels at the installation of services on Kubernetes, it does not include full lifecycle management. Helm Charts only provide basic functionality for packaging workloads and deployment. Most developers find these are useful upon first use, but these charts are often difficult to manage at scale. Also, Helm Charts are difficult to deploy for stateful data services. Instead, Operators encompass the entire lifecycle of applications - from deployment to upgrades, but also recovery, scaling, and more.

 

Building Operators - Who and How?

Developers have needed to build operators, especially to deploy stateful data services on top of distributed computing. Deployment in the Day 0 era of Kubernetes was mostly around stateless applications. In fact, Kubernetes has been good at managing stateless apps. However, it’s challenging and manually intensive to deploy stateful applications and workflows such as databases or message queues on Kubernetes. Stateful apps are procedural, and require more hand-holding. Plus, it’s difficult managing their life cycles. In fact, operators are most helpful for deploying stateful data services and enabling efficient application lifecycle management.

 

Operators help independent software vendors (ISVs) automate the operations of their products on Kubernetes, without requiring deep expertise in Kubernetes. Early attempts by some ISVs at writing operators resulted in building mere scripts. There were several approaches to implement operators, but often yielded the same prior level of integration with Kubernetes. In addition to writing tens of thousands of lines of code, developers also need to be on top of their Kubernetes API game, know when those API changes occur and if they are breaking. You as a developer may need to keep up with all those challenges as well as bundle solutions for integration testing, RBAC configuration, documentation, etc.

 

Operator SDK Landscape

The Kubernetes Operator ecosystem is growing rapidly with Operator developers and users. Some prominent approaches in the operator ecosystem are: 

 

• Kubernetes Universal Declarative Operator (KUDO)
• Kubebuilder by Google Cloud Platform
• Operator SDK by CoreOS

 

With Operator SDK framework, developers create operators using Ansible, Helm Charts, or Go. Operator SDK requires the greatest level of understanding of Kubernetes API and requires the most code to write an operator. Kubebuilder provides boilerplate templates and solutions for common operator patterns. KUDO operators are written as templated YAML manifests and require the least amount of code to implement.

 

Operators can alleviate the challenges of deploying stateful data services on Kubernetes, helping stand up several data services and reduce the amount of manual touch required to support them. Different operator approaches provide varying levels of writing code and hence different levels of control.