I'm diving into writing an operator for my company that will be deployed in our customers' Kubernetes environments to manage various workloads related to our products and services. I have some experience with Kubernetes and I'm currently exploring the best practices for writing an operator. I've read through various whitepapers and blogs about operators, and I've concluded that I might need what's called an 'operator of operators.'
Initially, I thought of using the Helm SDK within my operator since we already have a Helm chart available. However, after discussing with my team lead, he advised against using Helm as it might complicate later operations like scaling. He suggested instead that I should embed different operators, such as one for managing PostgreSQL, by finding existing operators like the one available at [cloudnative-pg](https://github.com/cloudnative-pg/cloudnative-pg). The idea is to develop one main operator that coordinates 3-4 different operators, each managing separate components, reusing existing solutions instead of developing everything from scratch.
I'm curious to know if embedding these different operators into a main operator is a reasonable approach. How challenging is this process, and are there any guiding materials you could recommend?
4 Answers
When creating an operator that triggers other operators, you need to set up a system where one operator can update a resource that the second operator oversees. This creates a dependency between the two. Your first operator can enter a 'retry' loop, requeuing its resource until the desired state of the second resource is achieved. It sounds complicated but it’s doable if you structure it right!
If you're looking for inspiration, check out Strimzi, which is considered a higher-order operator. It handles Kafka cluster resources by deploying specialized operators that manage topics and users. It might give you some useful ideas about your own operator design!
Thanks, I’ll definitely check it out!
Just to clarify, by 'operator of operators,' are you envisioning something similar to a higher-level operator like Kro or Yoke’s ATC? This would allow you to dynamically manage new resource definitions instead of just replicating Helm functions with Custom Resource Definitions (CRDs). It's totally fine to run multiple operators in your cluster to oversee databases, integrations, and more!
You might want to check out resources like the Operator Lifecycle Manager (OLM) on the Operator Framework website. It offers insights into managing operators within Kubernetes. You’ll find good documentation on how to embed and manage lifecycle events for your operators.
I have an operator doing a few tasks... I’m using operator-sdk, which integrates with OLM. But how do I embed other operators through this?
I get that concept, but are there any established best practices or resources that detail how to implement this?