The future of the Red Hat OpenShift Operator SDK

With the launch of Red Hat OpenShift 4.16, we have issued a deprecation notice for the Operator software development kit command-line interface (SDK CLI) that ships with OpenShift. This will allow us to decouple the Operator SDK from the OpenShift lifecycle in a future release and focus on long-term maintenance of the CLI binary. If you are writing and certifying an Operator with the SDK, you may have questions about the supportability of the SDK or how future versions of your operator will run on newer OpenShift releases. This article aims to answer these questions, but the 3-year support lifecycle of OpenShift 4.16 and 4.18 also applies to the Operator SDK, there is no immediate need for action.

The Operator SDK - a success story

Let’s start with some background. The mission of the SDK has always been two-fold: broaden the knowledge and adoption of the powerful operator pattern in the Kubernetes ecosystem and make it easy to test and package operators. To this extent, the Operator SDK has been a resounding success—it has been shipping with OpenShift 4.7 since its graduation to version 1.0. But even before that, it has enabled the growth of an initial 25 operators in the OpenShift 4.0 catalog to over 450 operators across three different catalogs in OpenShift 4.16. It has also enabled the development of more than 360 operators targeting the larger Kubernetes ecosystem at OperatorHub.io. While not all controllers in these catalogs have been created with the code scaffolding provided by the SDK, many use the SDK to integrate with the Operator Framework to define the formatting of the bundle release artifact and publish it in a catalog that the Operator Lifecycle Manager can use.

Beyond OpenShift, Operator SDK provides easy ways to create a custom controller in the larger Kubernetes ecosystem. The SDK democratizes people's access to the powerful controller pattern with Helm-based and Ansible-based Operators.

What is next for the Operator SDK?

First, let’s look at the reasoning for decoupling the Operator SDK CLI from OpenShift. Three essential factors led to this:

First, the evolution of Kubernetes APIs has stabilized to the extent that you can run a controller written with a newer Kubernetes client library successfully on older versions of Kubernetes. So, shipping the SDK alongside every OpenShift version and backporting security fixes to older versions isn’t as impactful as it used to be in the earlier days of Kubernetes.

Second, the initial code scaffolding of controller projects is very helpful when starting with an operator. Over its lifetime, less SDK CLI code generation is needed to evolve the operator's capabilities. As a result, code scaffolding hasn’t significantly changed between OpenShift releases. For Ansible and Helm-based operator projects, the development happens entirely outside of the SDK CLI after the initial scaffolding of the project and APIs.

What remains is updating to newer versions of the controller-runtime libraries for Golang operators and packaging and testing an operator. Controller-runtime updates continue to be resolved by the user in the same way as before and allow the code base to use newer features from these libraries, which is to say that a newer version of the Operator SDK CLI binary is not required to consume a newer version of controller-runtime.

For the packaging, we pursue long-term plans to make the overall process easier with OLM v1, so no wrapping CLI is required anymore.

Third, the adoption and knowledge of the operator pattern have reached a point in the Kubernetes ecosystem where the problem space is now well understood, and many controller projects have matured based on a solid track record of evolution. Hence, most feature requests for the Operator SDK from customers and the community revolved around using newer images and libraries for Helm- and Ansible-based operators to address security vulnerabilities in installed packages rather than new functionality for the SDK CLI.

In the upstream project, we have started separating the Ansible operator type into its own repository. More work is required here, and we are looking for contributors to continue the effort for the Ansible Operator SDK to eventually become a standalone plugin for Kubebuilder and thus evolve more independently, lowering the barrier for adding new functionality and allowing fixes to ship more quickly.

The Helm Operator SDK will remain part of the Operator SDK and continue to be a viable option for writing operators for OpenShift and the larger Kubernetes ecosystem. In the long term, OLM v1 will be able to reconcile regular Helm charts (in addition to Helm-packaged operators) in a first-class way, offering an easier path for the declarative lifecycle of Helm-based software with continuous reconciliation of desired and actual state on the cluster.

Based on this, we don’t plan significant changes to the Operator SDK CLI in the future that would warrant shipping separately maintained version lines alongside various OpenShift releases. As of the writing of this article, the last release of OpenShift to ship the Operator SDK CLI is planned to be OpenShift 4.18. At present, we do not foresee any new functionality being added.

How does the Operator SDK deprecation in OpenShift impact you?

The deprecation of the Operator SDK CLI in OpenShift does not create an immediate need for action for those using the SDK to develop a controller. The deprecation statement is a notice that the SDK CLI binary will stop shipping in the OpenShift 4.18 release. As part of Red Hat's support policy, the SDK CLI will be supported for the lifetime of the last OpenShift version that it shipped with, which equates to more than three years as of writing this article. During this time, Red Hat fixes qualified bugs and security vulnerabilities in the SDK CLI binary.

If you are starting a new operator project, you may continue to use the Operator SDK CLI binary that last shipped with an OpenShift release. As explained above, developers may bump the controller-runtime version at their own pace.

More importantly, the base images for Ansible- and Helm-based operator projects are not deprecated. They continue to be released alongside newer OpenShift versions and will be rebased to newer base images (for example, UBI9) and newer versions of the Ansible runtime.

This will also address vulnerabilities present in packages and code inside those images, either in the base image layer or in any of the libraries on top of them.

With continued maintenance of the OpenShift-version-aligned SDK images, vendors and users continue to receive bug and vulnerability fixes for the execution environment these operators run in. Developers will be able to find these new images tagged with the OpenShift version number in the Red Hat Content catalog:

• Ansible Operator Base Image
• Helm Operator Base Image

To use these images, maintainers simply update the FROM reference in their operator’s Dockerfile.

What does this mean for certified ISV partners shipping operators to OpenShift?

Partners do not need to change. For those leveraging the SDK CLI, the current CLI binary can continue to be used for either code scaffolding, packaging, or both. ISVs should continue to update to the latest Operator SDK CLI binary available as part of OpenShift. The Operator Certification Guide remains the canonical source for guidelines regarding the certification of third-party operators on OpenShift.

What does this mean for the Operator SDK CNCF project?

It is essential to note that the deprecation statement in OpenShift does not mean that the upstream Operator SDK CNCF project is sunsetting. To evolve the upstream code base, we invite anyone interested in collaborating to contribute and help with reviews or triage bugs.

The Operator SDK  shipping with OpenShift 4.16 downstream is based on the upstream Operator SDK v1.31. While the Operator SDK in OpenShift 4.17 will remain on that version, the plan is to rebase the OpenShift SDK shipping with OpenShift 4.18 to the latest upstream version. Upstream, we plan to release a newer minor version to support newer Kubernetes releases.

In summary, developers using the Operator SDK can continue developing controllers, testing and bundling their artifacts or publishing for the Operator Lifecycle Manager.

Where do we go from here?

The future of operator development with the Operator Framework and OpenShift looks bright. OLM v1 aims to simplify operator running so that a packaged operator bundle can be run directly on OLM-enabled clusters without publishing into a catalog first. Here the SDK CLI was traditionally used for the inner loop of operator development.

Work is also underway in OLM v1 to natively support Helm as a packaging format for controllers shipping CRDs. That means running an Operator via OLM will no longer require creating an OLM bundle, and developers can use the templating and packaging they are familiar with from Kubernetes.

OLM v1 will enable developers and maintainers to have a simplified bundle and publishing experience that does not require using the SDK CLI.

The Operator SDK can continue to be used for packaging and shipping operators for the current version of OLM (v0.x) for a long time. Certified ISV partners continue to use the version that shipped with OpenShift 4.16 or newer. They can continue to do this for three more years (starting with the OpenShift 4.18 release) or switch Helm-packaged operators as soon as we support that in the certification process and OLM v1. Updated Helm and Ansible images ensure those operators keep a strong security posture.

What is the future of operators on OpenShift?

Red Hat continues to be a firm proponent of the Kubernetes operator pattern. It provides a unique and powerful way to increase the utility of Kubernetes clusters. OpenShift, as a Kubernetes platform, is entirely built around the concept of operators, which manage the platform's lifecycle. OpenShift’s value-add with onboard extensions for providing service meshes, declarative CI/CD, GitOps, serverless computing, observability, and more are all delivered via the operator pattern.

We continue to invest in the new version of the Operator Lifecycle Manager because we see strong adoption of custom controllers and CRDs in the clusters of our customers and the larger community. OLM v1 will help simplify the running of many operators on multi-tenant clusters with declarative install and lifecycle, easy updates, novel permission management, and improved CRD integrity checks. It will also meet operator authors where they are with existing package formats like Helm and meet cluster admins where they are with an easy-to-understand control surface.