From bb222901e539b2d436b61deaae73515ff4876b0d Mon Sep 17 00:00:00 2001 From: Sajiyah Salat <109643863+Sajiyah-Salat@users.noreply.github.com> Date: Mon, 8 May 2023 06:54:37 +0530 Subject: [PATCH] Space and link aliases updated --- docs/book/src/reference/good-practices.md | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/docs/book/src/reference/good-practices.md b/docs/book/src/reference/good-practices.md index 209b2aede71..d97fa697ca0 100644 --- a/docs/book/src/reference/good-practices.md +++ b/docs/book/src/reference/good-practices.md @@ -5,20 +5,29 @@ The reconciliation is a continuos loop that performs necessary actions on the current state to ensure that the Custom Resource reaches the desired state as specified by the user. ## Why should reconciliations be idempotent? -When developing operators, the controller’s reconciliation loop needs to be idempotent. By following the [Operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) we create [controllers](https://kubernetes.io/docs/concepts/architecture/controller/) that provide a reconcile function responsible for synchronizing resources until the desired state is reached on the cluster. Developing idempotent solutions will allow the reconciler to correctly respond to generic or unexpected events, easily deal with application startup or upgrade. More explanation on this is available [here](https://github.com/kubernetes-sigs/controller-runtime/blob/main/FAQ.md#q-how-do-i-have-different-logic-in-my-reconciler-for-different-types-of-events-eg-create-update-delete). -Writing reconciliation logic according to specific events, breaks the recommendation of operator pattern and goes against the design principles of [controller-runtime](https://github.com/kubernetes-sigs/controller-runtime). This may lead to unforeseen consequences, such as resources becoming stuck and requiring manual intervention. +When developing operators, the controller’s reconciliation loop needs to be idempotent. By following the [Operator pattern][operator-pattern] we create [controllers][controllers] that provide a reconcile function responsible for synchronizing resources until the desired state is reached on the cluster. Developing idempotent solutions will allow the reconciler to correctly respond to generic or unexpected events, easily deal with application startup or upgrade. More explanation on this is available [here][controller-runtime-topic]. + +Writing reconciliation logic according to specific events, breaks the recommendation of operator pattern and goes against the design principles of [controller-runtime][controller-runtime]. This may lead to unforeseen consequences, such as resources becoming stuck and requiring manual intervention. ## Understanding Kubernetes APIs and following API conventions -Building your operator commonly involves extending the Kubernetes API itself. It is helpful to understand precisely how Custom Resource Definitions (CRDs) interact with the Kubernetes API. Also, the [Kubebuilder documentation](https://book.kubebuilder.io/cronjob-tutorial/gvks.html) on Groups and Versions and Kinds may be helpful to understand these concepts better as they relate to operators. -By developing Operator pattern solutions, we extend the Kubernetes api. Understanding the [best practices](https://sdk.operatorframework.io/docs/best-practices/) and following the design patterns is important in the development process. +Building your operator commonly involves extending the Kubernetes API itself. It is helpful to understand precisely how Custom Resource Definitions (CRDs) interact with the Kubernetes API. Also, the [Kubebuilder documentation](./cronjob-tutorial/gvks.html) on Groups and Versions and Kinds may be helpful to understand these concepts better as they relate to operators. + +By developing Operator pattern solutions, we extend the Kubernetes api. Understanding the [best practices][sdk-bestpractices] and following the design patterns is important in the development process. ## Can my controller reconcile more than one GVK? Avoid a design solution where the same controller reconciles more than one Kind. Having many Kinds (such as CRDs), that 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. ## How to use Status Conditionals -We recommends you to 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 for its implementation. -Additionally, we recommend checking the documentation on [Operator patterns](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) from Kubernetes to better understand the purpose of the standard solutions that are built with KubeBuilder. +We recommends you to manage your solutions using Status Conditionals. You can check the scaffold provided via the [deploy-image][./plugins/deploy-image-plugin-v1-alpha.html] as an example for its implementation. + +Additionally, we recommend checking the documentation on [Operator patterns][operator-pattern] from Kubernetes to better understand the purpose of the standard solutions that are built with KubeBuilder. + +[operator-pattern]: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) +[controllers]: (https://kubernetes.io/docs/concepts/architecture/controller/ +[controller-runtime-topic]: https://github.com/kubernetes-sigs/controller-runtime/blob/main/FAQ.md#q-how-do-i-have-different-logic-in-my-reconciler-for-different-types-of-events-eg-create-update-delete +[controller-runtime]: https://github.com/kubernetes-sigs/controller-runtime +[sdk-bestpractices]: https://sdk.operatorframework.io/docs/best-practices/