LovePhy - stock.adobe.com
Red Hat's Operator Framework set to overhaul Kubernetes clusters
Operator Framework is designed to ease deployment and management of apps on top of Kubernetes clusters. We break it down with former CoreOS CEO Alex Polvi.
Red Hat plans to bring the new Operator Framework to its OpenShift Container Platform and Kubernetes cluster tools in general. This should give teams a consistent way to manage complex applications across Kubernetes clusters that may run on private clouds, Azure, AWS or other providers.
Red Hat released Operator Framework -- which acts like a Kubernetes cluster service -- recently, but now, the company intends to embrace it within its own ecosystem as part of its recent CoreOS acquisition.
Until now, there has not been an easy way to describe how a cluster can manage complex applications in programmers' terms. Docker and other container platforms made deployment simpler and easier to manage apps on a single container. That left developers, though, alone to manage the orchestration across Kubernetes clusters. Developers have typically done this outside of the cluster itself, which only adds more complexity and inconsistency.
CoreOS developed the core technology behind Operator Framework as part of its Tectonic platform. Red Hat is now integrating it into a coherent technology stack and market branding as part of the CoreOS acquisition. The work is preliminary, but more than 60 independent software vendors have signed on to add these capabilities into various tools that can already run on top of Kubernetes clusters.
Kubernetes cluster service management
Operator Framework provides tools for developers to create application management capabilities that can run inside of Kubernetes clusters, along with a collection of apps themselves. These management apps are called "Operators."
Operators have become a community movement. "We have seen people building cloud services using open source operators for a variety of as-a-service [use cases]," said Alex Polvi, former CEO of CoreOS and current VP of engineering at Red Hat. This flexibility lets developers update and patch a complex app, like a Couchbase database. It probably has components that run on multiple containers for scalability and redundancy, but developers won't have to bring it offline.
Operator Framework itself is written in Go, as are most of the early Operator applications, Polvi said. It makes sense, as developers often use Go in Kubernetes cluster deployments. But developers can create Operators in any preferred programming language, including Java.
How a Kubernetes cluster service matures
Operator Framework enables developers to think differently. Developers can add management capabilities along a continuum of functionality that Polvi characterized as a maturity model. The first generation of Operators do little more than make it easier to provision and install these complex applications, comparable to what tools like Helm do today.
The next level enables developers to update apps in production, which is where apps like Helm fail. "If you are doing databases and queues with no downtime, this can get complicated," Polvi said.
The next level supports operations around autoscaling, backup and recovery. Eventually, Polvi expects that Operators will use AI and machine learning to auto-tune applications on the fly. But he stressed this will not eliminate the people required to run distributed applications.
"We can automate backup, failure and recovery out of certain apps and might be able to do more and more out of human ingenuity," Polvi said. "I can see a ton of intellectual property development just for tuning databases. There is no way to automate all that. But advances in the technology will continue to make this stuff easier to use."
