operator-sdk VS controller-runtime

operator-sdk: brew install operator-sdk

The operator that I've been working on is designed to manage the full lifecycle of a QuestDB database instance, including version and hardware upgrades, config changes, backups, and (eventually) recovery from node failure. I used the Operator SDK and kubebuilder frameworks to provide scaffolding and API support.

I've recently been working on an operator (built using the operator-sdk) that manages cluster node lifecycles. Kind allows you to spin up clusters with multiple nodes, using a Docker container per-node and joining them using a common Docker network. However, the kind executable does not allow you to modify an existing cluster by adding or removing a node.

To illustrate what we can do with an operator, I will create a proof of concept using operator-sdk. According to the official website::

Besides the frameworks TFA lists, you can also build Operators in Ansible or Helm.

https://sdk.operatorframework.io/

Operator SDK is basically just a thin wrapper for kube-builder

You mean the Operator SDK? https://sdk.operatorframework.io

yes I agree with youu, an issue has been opened on the operator-sdk github page regarding this topic https://github.com/operator-framework/operator-sdk/issues/6117

operatorpkg is a set of packages used to develop Kubernetes operators at AWS. It contains opinions on top of existing projects like https://github.com/kubernetes/apimachinery and https://github.com/kubernetes-sigs/controller-runtime. In many cases, we plan to mature packages in operatorpkg before commiting them upstream.

however, at least in envtest this returns

(rejected) kubernetes-sigs/controller-runtime #2266 🐛 Support get config inside snap with SNAP_REAL_HOME

Check out https://github.com/kubernetes-sigs/controller-runtime/blob/main/pkg/client/example_test.go. It really is that easy :-).

I am using Kubernetes controller-runtime envtest.