CoreOS has unveiled a system called Operators for running applications on Kubernetes that aren’t normally suited for such deployments.
The system brings to mind Mesosphere’s DCOS project that allows admins to run complex applications on the Mesos framework through declarative configurations, simplifying an otherwise complex job. But an Operator must be created separately for each application, so it’s not a completely free ride.
A pure Kubernetes scaling play
CoreOS says Operators are written to “manage instances of complex stateful applications on behalf of a Kubernetes user.” They don’t merely manage any stateful app; they also handle those that don’t lend themselves to scaling across clusters — in other words, those not likely to be managed in Kubernetes to begin with.
Operators are a testament to the flexibility of Kubernetes’ underlying functionality: CoreOS claims that creating Operators didn’t require modifying Kubernetes or creating a new version of the framework. Instead, it used existing Kubernetes APIs for new functionality, similar to Docker commodifying existing behaviors in the Linux kernel to create the current generation of container software.
“With this,” Brandon Philips, CTO of CoreOS, in a phone call, “we’re trying to bring in a path well-trod by software reliability engineers, encoding their knowledge writing software to operate applications as they think is best.”
The DC/OS connection
Of all the technology out there, Operators hew closest to the application management system found in Mesosphere’s DC/OS. That datacenter management system allows multinode applications like Spark to be automatically deployed, maintained, and load-balanced across a cluster through simple declarative commands.
Philips agreed that the two systems shared many goals, with DC/OS focused on Mesos users and Operators making the most of Kubernetes. But he emphasized that Operators aren’t aimed at Kubernetes neophytes. Rather, they’re for users who have mastered the basics and want to find a consistent way to deploy complex software within Kubernetes.
To offer an idea of what’s possible with Operators, CoreOS is releasing open source Operator projects to drive its etcd key-value store (a vital part of the CoreOS platform) and the Prometheus project for monitoring and alerting Kubernetes resources.
Some assembly required
“Over time, we imagine there will be new Operators introduced,” said Philips. Operators for applications that are heavily stateful, such as Postgres or Redis, could be built using the same patterns as those for etcd and Prometheus, he stated.
These won’t happen by themselves since at this point it isn’t really possible to automate creating an Operator for a given app. The Operator code for etcd and Prometheus was written in-house by CoreOS’s own engineers.
“There are some common best practices for how to do it,” said Philips, “but the bulk of the work is understanding how the application needs to be managed, backed up, upgraded, secured…. As much as I wish this stuff could be automated, what we’re doing is taking human-made documentation on how to run these applications and putting it in software.”
