metacontroller VS kubectl-operator

It worth adopt proper controller development with something like Metacontroller, Kopf or Java Operator SDK.

There are many frameworks, like the Operator Framework (https://operatorframework.io/) to the MetaController (https://github.com/metacontroller/metacontroller) to KubeBuilder(https://github.com/kubernetes-sigs/kubebuilder) to the Kubernetes Operator Framework (kopf, https://kopf.readthedocs.io/en/stable/), among others.

You might like a little alternative to writing your own in the first instance:) take a look at https://metacontroller.github.io/metacontroller/

Codegen is not magic, but if you want to make it simple stupid, supportable and prod-usable I'd go for metacontroller. There's not much magic to it - just common admission/validation webhooks propagated to your controller implementation, alongside the simplest possible reconciliation cycle. We had adopted Knative driven metacontrollers and it's a pretty solid approach.

https://github.com/metacontroller/metacontroller - Sounds cool! I will look into it.

When I need a quick mutating controller, I like to use MetaController, which makes rapid prototyping really easy: https://metacontroller.github.io/metacontroller/

If you are more into lightweight and common use cases, look at metacontroller or the shell-operator.

In case you've not heard of it, the metacontroller aims to do exactly this. It provides the controller-lifecycle (registering your types, watching the API for changes, etc), you just need to provide a HTTP webhook to receive the JSON object, and respond with the modifications\resources you want.

Kubernetes Operators simplify the management of complex applications on Kubernetes. In this guide, we'll walk through creating a simple Kubernetes Operator using the Operator Framework. We'll also cover setting up a local Kubernetes cluster with KIND (Kubernetes in Docker) and deploying the Operator to the KIND cluster.

There's a kubectl extension for it too. https://github.com/operator-framework/kubectl-operator

Since Go got generics, working with the Kubernetes API could become far more ergonomic. It's been pulling teeth until now. I'm eager to see how the upstream APIs change over time.

In the mean time, one of the creators of the Operator Framework[0] built a bunch of useful patterns using generics that we used to build the SpiceDB Operator[1] called controller-idioms[2].

Does anyone know of other efforts to improve the status quo?

[0]: https://operatorframework.io

[1]: https://github.com/authzed/spicedb-operator

[2]: https://github.com/authzed/controller-idioms

There are many frameworks, like the Operator Framework (https://operatorframework.io/) to the MetaController (https://github.com/metacontroller/metacontroller) to KubeBuilder(https://github.com/kubernetes-sigs/kubebuilder) to the Kubernetes Operator Framework (kopf, https://kopf.readthedocs.io/en/stable/), among others.

Operator lifecycle manager (OLM) is a Kubernetes feature & is part of Operator framework which provides tools that helps in the development and management of operators. OpenShift 4.x is build using different operators that manages cluster components like api-server, etcd, authentication, OAuth, ingress, etc. OpenShift makes use of OLM to install these operators as part of cluster build & OLM comes by default with OpenShift. OLM is an operator itself and understanding how it manages the operator lifecycle using different CRD’s & its flow is important, which I have explained in my article.

The documentation gives you all available options, but many of them are optional. If you know the package name of the operator (which you can get either via oc get packagemanifests or kubectl operator list-available from the kubectl plugin all you really need is: