CoreOS’ CEO is on record as saying that Kubernetes has already taken its place at the center of what we had been calling the “container ecosystem.” Now, in a move to help further legitimize that claim and grow the emerging field of workload-centric orchestration around Kubernetes, CoreOS on Thursday released to the open source community a mechanism, called “operators,” designed to automate the deployment of specific containerized applications.
“Various types of applications are really easy to deploy on Kubernetes today — generally your stateless apps, where you have a web application and you can horizontally scale it,” explained Brandon Philips, CoreOS’ chief technology officer, in a conversation with InApps Technology. “Managing more complex apps — like a database, a monitoring system, or a cache — requires a bit of gel or glue to hold everything together.
“So an operator is a piece of software that essentially knows a lot of the operational best practices, for whatever piece of software the operator is built for and can deploy that piece of software in a good configuration on top of Kubernetes, and then keep it healthy over time.”
The Outfield
Because software in a containerized environment is itself containerized, naturally, an operator is a container in itself.
Philips offers an example with etcd, the distributed key/value store. Suppose in your environment, you have several load balancers that handle traffic in bulk, and that share an etcd database. First, you deploy the etcd operator container. Then using Kubernetes’ kubectl command line tool, you invoke a few lines of configuration code to create an etcd cluster. When you ask kubectl to get a list of clusters, etcd will show up in the list, and your load balancers are now capable of communicating with that cluster.
Now, if a new edition of etcd were to be released, you can edit the cluster definition to refer to the new version number. The etcd operator will take over the job of upgrading the cluster, migrating each member individually, and bringing the entire system up to a fully upgraded state.
Suppose there are three members in the etcd cluster, and you lose one. The operator recognizes this and deploys a new member, adding that member to the cluster, and restores the application state to where it was before. In the meantime, the etcd operator is making certain that all members of its cluster are in a healthy state.
“It just sits there like a thermostat,” said Philips. “Essentially, the user is writing, ‘I want these instances of etcd clusters, and I want them configured this way,’ and the operator is trying to make whatever state the user said, true — whether that’s the number of copies in a cluster or the version of the cluster. It’s just trying to drive the state of the application to the state that the user expressed.”
Philips reminded us that Kubernetes uses etcd as its primary data store provider. So having an etcd operator on hand should actually improve the efficiency of the etcd cluster that supports Kubernetes itself.
The Pitch
Theoretically, a good orchestrator could be made to manage an application lifecycle automatically. But why, in a distributed processing system, would one want to centralize the job of lifecycle management? Why not instead make use of the extensibility of the Kubernetes API and delegate the job to a new type of agent? That’s what Philips said operators will do: extend this API to enable specific applications to share an explicit type (what Kubernetes calls a third-party resource), and to manage the instances within that cluster uniquely. It becomes academic for a user to create a new cluster based on this type.
Operators will not be an exclusive CoreOS product; rather, the company is releasing the concept and the initial code into open source. It is also releasing the first two operators which the community may use as prototypes: one for etcd, and one for the Prometheus monitoring tool. Although these initial model operators are written in Go, Philips said they’re not language- or platform-specific. You can use any language capable of invoking a standard API call.
However, CoreOS does intend to leverage these new operators’ functionality in an upcoming version of Tectonic, the company’s commercial Kubernetes distribution. That’s one reason the company chose Prometheus as one of its two initial models, Philips told us.
Intel’s Jonathan Donaldson Discusses Kubernetes
Listen to all TNS podcasts on Simplecast.
“Inside of Tectonic today, we’re using Prometheus for monitoring the Kubernetes and Tectonic components. Then we surface these as graphs inside the Tectonic console. Over time, using these operators, we’ll expose user interfaces for people to configure directly from the console, the monitoring of their applications.”
Today’s release should be considered foundational, the CTO explained, for a structural enhancement under way for Tectonic.
“But this is very much focused on the Kubernetes community,” Philips added, “and enabling and taking advantage of a lot of the foundational work inside of Kubernetes.”
Any ecosystem with an interest in thriving, whether it be ecological or technological, will find a way to distribute the labor and subsequently distribute the blessings. If the container ecosystem is truly reorienting itself around Kubernetes, it must do more than exhibit brand leadership. CoreOS’ move today is an effort to prove its own claims with actions.
CoreOS is a sponsor of InApps Technology
Feature image: vintage coin-operated baseball game from the Musée Méchanique in San Francisco, taken by Scott Fulton.
