Last month, Red Hat launched the Operator Framework for managing Kubernetes applications.
The original idea of operators was introduced by CoreOS about a year and a half ago, said Reza Shafii, vice president of products at CoreOS, which was recently acquired by Red Hat. CoreOS had been working on the idea of automated operations, starting with its eponymous operating system. That idea was then applied to Kubernetes, with the notion that capabilities such as upgrades, backup, failure, recovery, insight, and autoscaling, among others, could be captured into program logic and then automated, said Shafii.
Operators are a way to natively integrate into the Kubernetes environment and help software vendors or application developers with the packaging, deployment, and management of Kubernetes applications, said Alois Reitbauer, chief technology strategist at Dynatrace. Another way to think of them is “operations as code,” he explained.
One of the benefits of operators are that they are a native part of the Kubernetes ecosystem, said Reitbauer. For example, if you have a distributed database and want to have five replica sets, this can be done externally, but it is much simpler to do with an operator. By using an operator in this scenario, you are using native tools within Kubernetes rather than trying to use external tools to do something within Kubernetes.
The biggest improvement to the technology, according to Reitbauer, was when Red Hat launched the Operator Framework. Prior to that, building operators was not as straightforward.
According to Shafii, one of the challenges with operators is that they require extensive knowledge to build. Not only does one need to have knowledge of Kubernetes, but they also need knowledge of the application they are trying to build an operator for.
According to Shafii, the operator framework consists of three things: an SDK, an operator lifecycle manager, and the operator meter. The SDK is an API that developers can use to build a skeleton operator, which can then be filled in with callbacks. The SDK was created to encapsulate and abstract the Kubernetes concerns, allowing people to instead focus on the operational programming for their service, said Shafii.
The operator lifecycle manager is a runtime component that can be deployed on any Kubernetes environment. It allows users to query what operators are in use, apply updates, and more.
The operator meter enables developers to look at services, manage operators, see what users they have, and then correlate that to the underlying cost of running applications in containers.
Even though the technology is still in its early days, Shafii said that the uptake has been excellent. He said there are already more than 75 ISVs working with Red Hat to build operators, and that number continues to grow.
In the future, Reitbauer sees operators evolving from their current use. Eventually, the hope is that they will one day be responsible for self-healing applications or autonomous cloud computing. For example, operators might one day be able to tell when an application update is causing more errors than it should be and then decide to roll it back to a previous, more stable version.
