📖 Remove simplistic advice about multiple controllers reconciling same CR #4537
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This advice is simplyfing things and making an "It depends" situation look like there was a clear good and a clear bad way that is the same in all situations. Pretty much none of the issues stated will get better if each controller gets its own CR: * Race conditions: Conflict errors can always happen and all controllers need to be able to deal with them. If a full reconciliation is too expensive, they can use something like `retry.OnConflict` * Concurrency issues with different interpretations of state: This example sounds like just buggy software. Copying the state to a new CR doesn't eliminate this problem * Maintenance and support difficulties: This is definitely not going to get any better by adding more CRDs into the mix, if anything, it will get more complicated * Status tracking complications: This is why conditions exist and Kubernetes api guidelines explicitly state that controllers need to ignore unknown conditions: `Objects may report multiple conditions, and new types of conditions may be added in the future or by 3rd party controllers.`, [ref][0] * Performance issues: If multiple controllers do the same thing, that is a bug regardless of all other considerations and can easily lead to correctness and performance issues. The `workqueue` locks items while they are reconciled to avoid exactly that, but obviously it doesn't work cross-controller To illustrate the situation, think about the `Pod` object, in the lifecycle of a pod we usually have at least cluster-autoscaler, scheduler and kubelet. Making cluster-autoscaler act on a `PodScaleRequest` and scheduler on a `PodScheduleRequest` would be a complication, not a simplification. [0]: https://github.com/kubernetes/community/blob/322066e7dba7c5043071392fec427a57f8660734/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
the
size/S
|
👍 from my side |
camilamacedo86
approved these changes
Feb 3, 2025
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alvaroaleman, camilamacedo86 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
|
@camilamacedo86 thanks for the prompt review. Could you maybe restart the failed CI job? I don't think its related to the PR and I don't have perms to do that myself |
|
I am looking on that. |
It is solved, too. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This advice is simplyfing things and making an "It depends" situation look like there was a clear good and a clear bad way that is the same in all situations. Pretty much none of the issues stated will get better if each controller gets its own CR:
retry.OnConflictObjects may report multiple conditions, and new types of conditions may be added in the future or by 3rd party controllers., refworkqueuelocks items while they are reconciled to avoid exactly that, but obviously it doesn't work cross-controllerTo illustrate the situation, think about the
Podobject, in the lifecycle of a pod we usually have at least cluster-autoscaler, scheduler and kubelet. Making cluster-autoscaler act on aPodScaleRequestand scheduler on aPodScheduleRequestwould be a complication, not a simplification.