sample-controller VS kubebuilder

- Sample controller: https://github.com/kubernetes/sample-controller

The most low-level approach I have seen is using the client-go package. Both kubebuilder and controller-runtime are based on this package. You can see an official example here: https://github.com/kubernetes/sample-controller/blob/master/docs/controller-client-go.md But even that sample requires some code generation on top of it https://cloud.redhat.com/blog/kubernetes-deep-dive-code-generation-customresources

I would still recommend gitOps tools or if you want to create your own abstraction (CRD) that encapsulates whatever behaviour you want to watch/act upon, take a look into kubernetes sample controller (https://github.com/kubernetes/sample-controller) or the kubernetes operator pattern https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

Either should be fine. In case though you want something more basic then consider sample-controller: https://github.com/kubernetes/sample-controller

As far as Operator development goes, if you are comfortable with golang then I would recommend checking out sample-controller https://github.com/kubernetes/sample-controller It does not abstract the underlying client-go machinery and so provides a good way to understand how various parts of an Operator come together. On the other hand, if you don't want to get exposed to that much details then either Operator SDK or Kubebuilder will be good options. In case you are not into golang then there are SDKs for other languages as well (Python, Java, etc.).

Cool! Given that you mention you are a beginner in K8s operator development, here is a plan that I would like to suggest. 1. Get basic understanding of Kubernetes custom controllers first. The sample controller repo is a good place to start. https://github.com/kubernetes/sample-controller

the sample controller using client-go to learn about informers: https://github.com/kubernetes/sample-controller

The Spin operator uses the Kubebuilder framework and contains a Spin App Custom Resource Definition (CRD) and controller. It watches Spin App Custom Resources and realizes the desired state in the K8s cluster. Aside from the immediate benefits gained by running Wasm workloads in k8s, additional optimizations such as Horizontal Pod Scaling (HPA) and k8s Event-driven Autoscaling (KEDA) can be achieved in a pinch.

kubebuilder: brew install kubebuilder

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.

Recently, I've been spending a lot of time writing a Kubernetes operator using the go operator-sdk, which is built on top of the Kubebuilder framework. This is a list of a few tips and tricks that I've compiled over the past few months working with these frameworks.

Since we built our operator using the Kubebuilder framework, most standard monitoring tasks were handled for us out-of-the-box. Our operator automatically exposes a rich set of Prometheus metrics that measure reconciliation performance, the number of k8s API calls, workqueue statistics, and memory-related metrics. We we were able to ingest these metrics into pre-built dashboards by leveraging the grafana/v1-alpha plugin, which scaffolds two Grafana dashboards to monitor Operator resource usage and performance. All we had to do was add these to our existing Grafana manifests and we were good to go!

I wrote a CSI driver and some operators. I admire K8s, because you can find solution to almost any problem in the source code - API versioning, load balancing, request throttling, optimistic concurrency, security, and much much more. I recommend https://book.kubebuilder.io/ It is similar to Operator SDK, but without Openshift-specific stuff. It gradually introduces you to many k8s concepts, and follows design patterns that k8s uses internally.

Do you mean this: https://book.kubebuilder.io/ ?

https://book.kubebuilder.io/ all you need to know

A better way to write an operator these days is to use kubebuilder [1].

My complaint is that I have seen orgs write operators for random stuff, often reinventing the wheel. Lot of operators in orgs are result of resume driven development. Having said that it often comes handy for complex orchestration.

[1]https://github.com/kubernetes-sigs/kubebuilder