-
Notifications
You must be signed in to change notification settings - Fork 198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace ApplyResourceWithRetry with ApplyResource #751
Comments
All the retries here have nothing to do with the leader election. For any failures, it is true that controller will retry again. But with retries, we make this method more resilient to any conflicts. And most of the time, these conflicts are easy to solve with a simple update or field convergence in a very short period. As you may know, the resources in the cluster may get varied all the time. It is very common to see conflicts when we create or update a resource. By using retries, it is definitely far more faster to deploy the resources successfully to clusters than letting controller resync in the next round, where we may have conflicts as well, especially when we have a large queue. What's more important here is that we may not apply back all the immutable value in a single Thus, I'd prefer this kind of resilient way. And it is more efficient.
It is hard to say "updates are more frequent than creations". That depends. Maybe you're right. For GET-First-Then-CREATE-UPDATE step, it takes 2 steps to finish a normal CREATE operation. While for CREATE-or-UPDATE step, it only takes 1 step to finishing the creation. No matter which way you choose, it is a preference. Furthermore, you could find this kind of CREATE-or-UPDATE preference eveywhere in Kubernetes repo.
Thanks for pointing out. You're right. It should be |
@dixudx Thank you for your patient explanation. about retryI understand that retry are more important for solving the problem of immutable values. For other errors during processing, I still believe that retries have limited effects. In the process of applying resources, I have encountered two types of failures: inability to connect to the member cluster and request throttling. However, these scenarios cannot be resolved through retries within the function. These failure cases can be better addressed through the controller's delay queue. For other failure cases, there may be issues such as processing timeouts, insufficient access permissions, and other problems that cannot be resolved through retries within the function. Therefore, retry only need for the problem of immutable values, and I have made some modifications, as shown here: retry for doApplyPatch. about the CREATE-or-UPDATE preferenceIn the Kubernetes repository, I have found some usage, such as in the kubeadm apiclient.CreateOrUpdateConfigMap function on Line284. However, there is little such processing in the pkg/controller directory, and I have located it by searching for IsAlreadyExists.
I have read part of the code above and found that most of the logic is still created when it does not exist, so I understand that CREATE-or-UPDATE is not a general method. I am not sure if you have any suitable examples, so I will do some more reading. |
What happened:
Carefully analyzing the ApplyResourceWithRetry method, it seems that there is no need for retry, so i wrote the ApplyResource function to replace ApplyResourceWithRetry.
Modifications:
What you expected to happen:
use ApplyResource instead of ApplyResourceWithRetry
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:
The text was updated successfully, but these errors were encountered: