Why is Kubernetes such a hot topic in IT?
To properly answer that question, you need to look at the advent of containers and microservices, which brought wonderful new capabilities – and new challenges – to software development and infrastructure.
“Containers are fantastic things: They allow for an even greater leap in resource efficiency over virtual machines than VMs claimed over hardware servers,” says Jeremy Thompson, CTO at Solodev.
That leap doesn’t come free of charge, however.
“The mandate that a container focus on a single service – your web app, a caching layer, the database, a logging system – means that a modern app can beget a small army of containers,” Thompson explains.
That “small” army might actually mean a massive number of containers that, Thompson notes, must communicate with one another, handle failures, and scale independently based on ever-changing needs. Managed in a manual fashion, these operational needs can overtax even the sharpest DevOps teams.
Enter container orchestration – and Kubernetes as the leader of the pack, in part because of its DNA: Kubernetes was originally an internal Google system used to manage billions of production containers a week. Today, Kubernetes is one of the liveliest open source projects around, another key reason for its popularity. (See also Kubernetes by the numbers: 10 compelling stats.)
“As an orchestration framework, Kubernetes eases the burden of configuring, deploying, managing, and monitoring even the largest-scale containerized applications,” Thompson says.
The problem that prompted Kubernetes Operators
That’s not where the story ends, however. The conventional wisdom of Kubernetes’ earlier days was that it was very good at managing stateless apps. But for stateful applications such as databases, it wasn’t such an open-and-shut case: These apps, as Thompson puts it, required more hand-holding.
“Adding or removing instances may require preparation and/or post-provisioning steps – for instance, changes to its internal configuration, communication with a clustering mechanism, interaction with external systems like DNS, and so forth,” Thompson explains. “Historically, this often required manual intervention, increasing the DevOps burden and increasing the likelihood of error. Perhaps most importantly, it obviates one of Kubernetes’ main selling points: automation.”
That’s a big problem. Fortunately, the solution emerged back in 2016, when coreOS introduced Operators to extend Kubernetes’ capabilities to stateful applications. (Red Hat acquired coreOS in January 2018, expanding the capabilities of the OpenShift container platform.) Operators became even more powerful with the launch of the Operator Framework for building and managing Kubernetes native applications (Operators by another name) in March 2018. Amidst the broader excitement about Kubernetes, the importance of Operators seems understated – when in fact it would be hard to overstate their importance.
[ How can automation free up more staff time for innovation? Get the free eBook: Managing IT with Automation. ]
So we’re here with a brief primer for IT leaders on Operators: What are Kubernetes Operators, and why are they so important? We asked a range of experts to help CIOs and their leadership teams get up to speed on Kubernetes fundamentals. Let’s start by getting grounded in some brief definitions.
What is a Kubernetes Operator?
“An operator is a way of building an application and driving an application on top of Kubernetes, behind Kubernetes APIs. The idea is that when you have an application, like a database like Postgres or Cassandra…any complex application needs a lot of domain-specific knowledge,” Sebastien Pahl, director of engineering, Red Hat OpenShift, explained in a Kubecon 2018 presentation. You can use Kubernetes tools to try and solve some of those problems, he notes.
“But in the end, when it comes to really fully automating an application, and by fully automating, I mean handling updates from one version to another without waking people up, handling failure recovery if it’s needed, scaling the application up and down depending on some scenarios – all of that should be handled automatically,” Pahl says. “Humans should not be involved in this kind of operation because it kind of breaks the promise that containers gave us. Containers’ promise was ‘Hey, you package it once, it runs everywhere.’ Well, that’s true for developers, but in production, there’s so much more that needs to be done.” (Watch Pahl's full talk on Kubernetes Operators in Depth.)
[ Read also: OpenShift and Kubernetes: What's the difference? ]
Here are some other definitions of Kubernetes Operators that you can use:
“A Kubernetes Operator helps extend the types of applications that can run on Kubernetes by allowing developers to provide additional knowledge to applications that need to maintain state.” –Jonathan S. Katz, director of customer success & communications at Crunchy Data
“A Kubernetes Operator is an abstraction for deploying non-trivial applications on Kubernetes. It wraps the logic for deploying and operating an application using Kubernetes constructs. As an example, the etcd operator provides an etcd cluster as a first-class object. Gone are the days of deploying an etcd cluster using a complicated collection of stateful sets, crds, services, and init containers to manage bootstrapping and lifecycle management, et cetera.” –Richard Laub, staff cloud engineer at Nebulaworks
“Operators are software written to encapsulate all of those operational considerations for a specific Kubernetes application and ensure that all aspects of its lifecycle, from configuration and deployment to upgrades, monitoring, and failure-handling, are integrated right into the Kubernetes framework and invoked when needed. The Operator Framework provides an SDK to handle calling the Kubernetes API, making it easier to focus on your own business logic. If it makes sense for your app, you can extend the Kubernetes API by adding domain-specific resource types – for example, ‘backup’ – which can then be used via the standard Kubernetes tooling such as kubectl.” –Jeremy Thompson, CTO at Solodev
Why are Kubernetes Operators so important?
Definitions are foundational knowledge, but a really useful high-level understanding of Operators requires connecting the “what” to the “why.” Why are Operators valuable? We break their value down into five overlapping categories, with additional insight and context from our experts:
1. Operators extend Kubernetes functionality
This is really the table-stakes significance of Operators: They extend the power of Kubernetes, especially to stateful apps, in a far more manageable and accessible fashion than before. As the coreOS announcement introducing the original etcd Operator and Prometheus Operator said, “stateless is easy, stateful is hard.” Operators bring the balance back toward easy for a wider range of applications.
“Kubernetes Operators allow developers to easily extend Kubernetes functionality for specific software [and] use cases,” says Ben Bromhead, CTO at Instaclustr. (Bromhead led the development of the Kubernetes operator for Apache Cassandra.) “A great example of this is database operators, which allow Kubernetes users to safely deploy and manage certain databases without needing to build their own workarounds.”