Reconcile function will be called concurrent?

[lysShub]

What broke? What's expected?

Reconcile function will be call concurrent?

Reproducing this issue

No response

KubeBuilder (CLI) Version

Version: main.version{KubeBuilderVersion:"3.9.0", KubernetesVendor:"1.26.0", GitCommit:"26f605e889b2215120f73ea42b081efac99f5162", BuildDate:"2023-01-16T17:21:30Z", GoOs:"linux", GoArch:"amd64"}

PROJECT version

No response

Plugin versions

No response

Other versions

No response

Extra Labels

No response

[camilamacedo86]

Hi lysShub,

The reconciliation is like a loop that will run until performing all operations required to ensure a desired state. I would like to suggest you check the blog https://dev4devs.com/2020/08/16/how-to-getting-started-develop-go-operators-from-scratch-with-sdk-1-0/ since it has a small overview over how the things work and explain the reconciliation.

Because this are common questions, I think it would be great if we have a very similar content, tweaked a little for our documentation. We could add a new section under the QuickStart https://book.kubebuilder.io/quick-start.html, such as Overview, to add this code.

We could also recommend checking the documentation on how to develop Operator pattern solutions from Kubernetes to understand better the purpose of the standard solutions that are built with KubeBuilder.

We could also create another documentation under the references to clarify the "Common Suggestions", and "Best Practices" or provide the following content in this overview:

---

Develop idempotent reconciliation solutions

When developing operators, the controller’s reconciliation loop needs to be idempotent. By following the Operator pattern you will create Controllers which provide a reconcile function responsible for synchronizing resources until the desired state is reached on the cluster. Breaking this recommendation goes against the design principles of controller-runtime and may lead to unforeseen consequences, such as resources becoming stuck and requiring manual intervention.

Understanding Kubernetes APIs

Building your operator commonly involves extending the Kubernetes API itself. It is helpful to understand precisely how Custom Resource Definitions interact with the Kubernetes API. Also, the Kubebuilder documentation on Groups and Versions and Kinds may be helpful to understand these concepts better as they relate to operators.

Follow Kubernetes API conventions

By developing Operator pattern solutions, you will be extending the Kubernetes api. I highly recommend that you understand how Kubernetes API is designed and look for design solutions that follow the same standards and conventions. Please, ensure that you its guidelines

Avoid a design solution where the same controller reconciles more than one Kind

Having many Kinds (such as CRDs), which are all managed by the same controller, usually goes against the design proposed by controller-runtime. Furthermore, this might hurt concepts such as encapsulation, the Single Responsibility Principle, and Cohesion. Damaging these concepts may cause unexpected side effects and increase the difficulty of extending, reusing, or maintaining the operator.

Use Status Conditionals

It recommends you manage your solutions using Status Conditionals. You can check the scaffold provided via the [deploy-image][https://book.kubebuilder.io/plugins/deploy-image-plugin-v1-alpha.html] as an example over how can you implement it.

Your help is welcome; if you would like to contribute to the project, please push a pull request and feel free to ping me for reviews.

[Sajiyah-Salat]

Because this are common questions, I think it would be great if we have a very similar content, tweaked a little for our documentation. We could add a new section under the QuickStart https://book.kubebuilder.io/quick-start.html, such as Overview, to add this code.

Hey @camilamacedo86 from this code you are referring to the code block in suggested blog. right? if not please clarify, wdym by this code. Thank you.

[Sajiyah-Salat]

/assign