Introducing Kubernetes Operator Maturity Model for Multi-Operator Platforms
Kubernetes Operators have now become mainstream. Operators enable running third-party softwares directly on Kubernetes. Various Operators are being built today for a variety of softwares such as MySQL, Postgres, Cassandra, Kafka, Prometheus, Moodle, Wordpress, etc.
Enterprises are increasingly using multiple Operators to build their diverse application workflows on Kubernetes. In this endeavor the typical challenges that enterprise teams face today include questions such as figuring out which Operators are appropriate for their needs, how to use various Operators together to build their workflows, ensuring that their multi-Operator stacks are portable across Kubernetes distributions, etc. As such, there is a need for enterprises to understand the enterprise readiness of various Operators and how to use them to build their particular workflows.
Kubernetes community is taking steps towards addressing some of these concerns. For instance, the Operator Framework project has defined Operator Capability levels that help in understanding capabilities of an individual Operator such as install, upgrade, full life cycle management for the underlying software that it is managing. While this is a good starting point, for enterprises, concerns related to using multiple Operators when building their diverse workflows on Kubernetes have not been addressed yet.
Today we are happy to share with the community an Operator Maturity Model to fill this gap. The Operator Maturity Model is designed to cover the range of scenarios in which Operators are being used by enterprises today. It focuses on calibrating an Operator’s maturity towards increasingly complex setups such as, multi-Operator, multi-tenant application stacks, multi-cloud, and Kubernetes vendor neutrality.
This model has emerged from our experience of working with Operator authors and enterprises. If you are an Operator author, use this model as a guiding framework in developing your Operator to fit in real-life multi-Operator stacks. If you are a Platform Engineer/DevOps Engineer adopting Kubernetes for your enterprise use case, use this model for evaluating Operators for your platform needs.
The Operator Maturity Model defines four maturity levels as shown below.
1) Consumability — Application developer’s ability to consume Custom Resources
The first maturity level defines the requirements related to usability of Custom Resources of an Operator focusing on the needs of the application developers. It includes things such as ensuring the declarative approach in Custom Resource definitions, using ‘kubectl’ as primary interaction mechanism for the Operator, and documenting Custom Resource usage and Operator implementation assumptions. Refer to the detailed guidelines corresponding to this level here.
2) Security —Authorization, multi-tenancy, Network Policies
The second maturity level focuses on requirements related to Operator support for multi-tenancy, authorization through Service Accounts, restricting traffic between Custom Resource Pods using NetworkPolicies, etc. Refer to the detailed guidelines corresponding to this level here.
3) Robustness — Workflow stability
Robustness guidelines focus on ensuring stability of workflows with respect to their resource needs, their interdependencies, input validations, and garbage collection. Refer to the detailed guidelines corresponding to this level here.
4) Portability — Kubernetes distribution and Cloud provider independence
The goal of the fourth maturity level is to define Operator packaging and installation requirements such that an Operator can be installed on any Kubernetes cluster independent of any Kubernetes distribution or Cloud provider. Refer to the detailed guidelines corresponding to this level here.
At CloudARK, we use this model for curating and certifying Operators that are part of multi-Operator stacks delivered to our customers. This model also forms the foundation for our Platform-as-Code approach towards building purpose-built platforms on Kubernetes. We have made detailed guidelines available here that support these maturity model levels. These are already being used by various software vendors developing Kubernetes Operators for their platform software.
Operator Certification Program
In addition to the Operator Maturity Model, we are introducing Operator Certification Program. Through this program our goal is to provide independent third party review of Operators for Operator authors and help Enterprises who are considering to use Operators with Operator evaluation.
Operator authors
If you are a software vendor building Operator for your software, work with us to get your Operator thoroughly evaluated for multi-Operator readiness against the maturity model guidelines. We certify your Operator for the maturity level that it currently satisfies and also provide recommendations on how to achieve a particular maturity level.
Enterprises
We work with Operator vendors on your behalf so that you don’t have to. Available Operator listings in the community leave lot of work for you to do. This includes things such as, finding the best Operator from amongst several for your needs, or figuring out whether multiple Operators will work together or not. You can trust us to get all your Kubernetes Operators and Platformization needs served.
Why CloudARK?
1. No Kubernetes distribution bias: We are an independent company focusing on Kubernetes extensibility to help enterprises build their custom platforms on Kubernetes. We don’t have our own Kubernetes distribution; so our Operator recommendations are not tied to any Kubernetes distribution or Cloud provider.
2. Competency: Our team has been one of the most active teams pushing the boundaries on Operators. We have analyzed over 100+ Operators. Checkout our blog for other Operator related content from our team.
3. Community engagement: We are active in upstream Kubernetes and continuously collaborate with Operator authors by filing Github issues, suggestions, and feedback.
4. Focus on consumability: We have been working on improving consumability of Operators and Kubernetes Custom Resources for application developers. Check out our KubePlus GitHub repository to get more insights on how it helps application developers in consuming Custom Resources from different Operators to build platform workflows as Code.
Conclusion
Today, Kubernetes adoption is at a stage where Kubernetes cluster provisioning is rapidly becoming a commodity. Now the challenge for enterprises is how to best use their Kubernetes clusters to create a platform for their specific workloads like AI, CI/CD, SaaS, ML, etc. Kubernetes Operators are a key building block in realizing this vision of bespoke workload specific platforms. Our Operator Maturity Model and the certification program is designed to accelerate this journey. We look forward to working with you in this space.
