You're likely to encounter some of these characters on your digital transformation journey. Here's who to be on the look out for, and how to work more productively with them.
Kubernetes Operators: 4 facts to know
Without real automation, you won’t realize the full potential of containers. That’s where Kubernetes Operators play a growing role. Here’s what IT leaders should know
3. Kubernetes Operators aren’t just for databases
A (very) brief history of Kubernetes Operators goes something like this: In its early days, Kubernetes was considered a great fit for managing stateless applications. For stateful applications like databases, not so much – at least not without significant operational burden. Operators to the rescue.
(Again, that’s the CliffsNotes version.)
So Operators in their early days were often focused on database applications and helping to extend Kubernetes’ capabilities to this critical category. Bromhead from Instaclustr led the development of an Operator for Apache Cassandra, for example.
“Back when Kubernetes Operators started, people would create Operators mostly for managing stateful database workloads,” says Yossi Jana, DevOps team leader at AllCloud. “Some of the examples were MongoDB, Cassandra, and Redis. Those databases are more difficult to set up and continuously manage on your own without the proper expertise.”
So, yes, if you scan the OperatorHub.io registry, you’ll see plenty of database-related Operators. But Operators aren’t for databases alone.
“As Operators are getting easier to develop and are becoming mainstream, more and more companies are offering their cloud-native solutions on the Operators Registry,” Jana says. Jana notes that you can find (and use) Operators for needs such as security (such as the Aqua Security Operator), networking (such as Istio-operator), and CI/CD (such as the Spinnaker Operator).
4. An Operator is not necessarily the tool for every job
To recap, Operators are a kind of a big deal. But being a big deal doesn’t mean you’re always the best choice. Nilesh Deo, director of product marketing at CloudBolt Software, lists the notion that “Kubernetes Operators will solve all my Kubernetes problems” as one of the top misunderstandings about Operators.
Other common misunderstandings, according to Deo: That Operators are set-it-and-forget-it propositions (as I mentioned above), and that Operators require a lot of heavy-duty development effort. For the latter, yes, someone has to write the Operator, but it doesn’t necessarily need to be you, thanks to repositories like OperatorHub.io. Moreover, toolkits and SDKs like Operator Framework and Kubebuilder can cut down development effort.
By design, Naor explains, Operators can provision, update, and delete Kubernetes resources - which means they are in-cluster privileged components. “This means that Operators represent a persistent in-cluster risk; therefore these are components that we must treat appropriately as far as our threat and risk modeling,” Naor says.
According to Naor, if a task can be appropriately handled with a cron job, that may be the better choice.
“This reduces the time a privileged component is running without compromising on the required functionality,” Naor explains. “The key questions before choosing an Operator are: Do we really need to implement certain workflows or functionality as an Operator? Can we achieve the same using a cron job, or use cluster external automation?”
Operators exist for good reasons, and when those reasons match your needs, you’ve got a powerful lever for expanding Kubernetes functionality without crushing your DevOps or SRE teams.
“Operators as a software pattern absolutely fulfill an important role in automating the entire applications and microservices lifecycle when running in Kubernetes – from installing, updating, and scaling to backup and restore,” Naor says.
[ Want to learn more about building and deploying Operators? Get the free eBook: O'Reilly: Kubernetes Operators: Automating the Container Orchestration Platform. ]