Yes.

 

Yes. OLM is a package manager for operators, and it specifies a packaging format. Operator Hub uses that same package format.

 

When we talk about Operators, we are referring to the concept originally described in this post from 2016: https://coreos.com/blog/introducing-operators.html

In sum, an operator has three parts:

1. One or more CRDs that represent the desired vs actual state of a specific application. Example: a "MySQL" CRD.

2. Controllers that reconcile those CRDs.

3. Operation knowledge; anything a human might do (install, upgrade, scale, backup, repair, refresh, rebalance, reshard, vacuum, failover, ...) gets automated as logic in a controller.

Kudo has a very different pattern. It runs a single set of controllers, as "cluster-admin", that own a set of kudo-specific CRDs. That is kudo's out-of-the-box "Universal Operator", before you've installed an application-specific operator. If you then made a mysql operator with kudo, there would not be a new CRD, and there would not be a new controller.

OLM can be the package manager for almost anything that has CRDs, controllers, and RBAC policy. It does not matter how you created those things. You could probably even use OLM to install kudo itself. If you use operator-sdk, it offers some features that may help you package up assets for use with OLM, but you're under no obligation to use it.

 

How they are built matters because you end up with very different APIs and lifecycle management features. Operators, helm charts, "kudo operators", and other similar things each have fundamental differences in what they are capable of and how they get used, based on which pattern they are following. The "app store" is merely the discovery mechanism; how many different tools will a cluster owner want to be involved in managing and upgrading the workloads on their cluster? Different cluster owners will have different tolerances, but many will want to standardize on one mechanism for controlling what versions of software are running in their cluster.