Operator, Operator: My Stateful App Is on the Kubernetes Line

Kubernetes, Google’s open source container management project, is a wonderful thing, and that’s why it lies at the heart of many container management systems, including Red Hat’s OpenShift and CoreOS’s Tectonic.

Using Kubernetes with stateless applications like web apps and mobile backends is generally straightforward because basic Kubernetes APIs can scale and recover from failures without additional knowledge, but using Kubernetes to manage stateful applications is a whole different kettle of fish, according to CoreOS’ Brandon Philips, the company’s chief technology officer.

That’s because applications like databases, caches and monitoring systems require application domain knowledge to correctly scale, upgrade, and reconfigure while protecting against data loss or unavailability.

To put it bluntly, you need some Johnny-on-the-spot who has the specialist knowledge that’s needed whenever a stateful application is being handled.

So here’s an idea: what if you could take all of that Johnny-on-the-spot’s specific knowledge and program it into a piece of software that would help create, configure and manage complex applications on top of Kubernetes?

And that is exactly what CoreOS has been up to. “We want this application-specific operational knowledge encoded into software that leverages the powerful Kubernetes abstractions to run and manage the application correctly,” says Philips. The result is what CoreOS calls an “operator.”

So What Exactly Is an Operator?

An Operator, as defined by CoreOS, is:

“Software that encodes this domain knowledge and extends the Kubernetes API through the third-party resources mechanism, enabling users to create, configure and manage applications. Like Kubernetes’ built-in resources, an Operator doesn’t manage just a single instance of the application, but multiple instances across the cluster.”

Or, more elegantly,

“An Operator represents human operational knowledge in software, to reliably manage an application.”

While “Operator” is certainly easier to say than to actually develop, to prove the concept CoreOS has already built two open-source Operators that are available now. These are:

• The etcd Operator, which creates, configures, and manages etcd clusters. etcd is a reliable, distributed key-value store introduced by CoreOS for sustaining the most critical data in a distributed system, and is the primary configuration datastore of Kubernetes itself.
• The Prometheus Operator, which creates, configures and manages Prometheus monitoring instances. Prometheus is a monitoring, metrics and alerting tool.

These two operators are, Philips hopes, just a start: he expects the open-source community to build more Operators — lots more. “We envision a future where users install Postgres Operators, Cassandra Operators, or Redis Operators on their Kubernetes clusters, and operate scalable instances of these programs as easily (as) they deploy replicas of their stateless web applications today.”

It’s a nice thought, but will this actually happen? It’s hard to say for sure, but given that there’s a need — or a demand — for a solution with more automated management of stateful applications, it’s certainly possible. The fact that Operators run with Kubernetes is certainly a plus point, and the fact that it’s all open source is key.

But the fact that CoreOS is behind Operators arguably isn’t.

Not that there’s anything wrong with CoreOS — far from it. It’s just that some of CoreOS’s clever innovations in the past haven’t seemed to have gained much traction. If Google or Docker comes up with something very similar, then you’d have to say that all bets on Operators would be off.

Paul Rubens is a technology journalist and contributor to ServerWatch, EnterpriseNetworkingPlanet and EnterpriseMobileToday. He has also covered technology for international newspapers and magazines including The Economist and The Financial Times since 1991.

Follow ServerWatch on Twitter and on Facebook