3 years ago

Category: Software, Database, Data, Microsoft, Kubernetes, Infrastructure, automation, yaml

Operators made up of custom controllers and CRDs encode operational actions and take away the overhead of making sure you spin up the right resources and dependencies for that application or correctly resize an etcd cluster when it fails in the middle of the night. But operators have quickly become popular and the sheer proliferation means that ironically, Kubernetes ops teams are needing to gain that same deep knowledge about operators themselves, from choosing between operator frameworks to choosing the right operator from multiple options for many applications to managing the lifecycle of dependencies.

There are so many operators and so many ways to deploy operators (through Helm, KUDO, the Operator Framework OLM and raw Kubernetes manifest) that two of the handful of sample queries for Artifact Hub are specific categories of operators.

One reason there are more than ten and possibly as many as 20 different operators to choose from just for Cassandra is that open source encourages developers to scratch their own itch, and McFadin suggested that the best way for operators to improve in the short term would be for more Kubernetes users and admins getting involved in the projects, to get the features they need into a standard operator rather than writing their own.

In the long term, that might even lead to the idea of data and distributed storage services that are a first-class citizen in Kubernetes, McFadin speculated, because the alternative is “pick one of the dozens of potential operators and good luck getting it right.”