-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Possible race condition / inconsistency between CRUD operations #245
Comments
Adding a new interface `APIClient` to expose as part of the client a non caching reader interface. fixes kubernetes-sigs#180 fixes kubernetes-sigs#245
Adding a new interface `APIClient` to expose as part of the client a non caching reader interface. fixes kubernetes-sigs#180 fixes kubernetes-sigs#245
That's intentional -- it's how Kubernetes works. If you write your controller correctly (i.e you set up signals for everything you care about, and you always try reconciles as trying to be declarative), you'll get the right behavior, because you'll get notified of updates as changes get noticed. Kubernetes is eventually consistent. We could probably do a bit better in explaining this in the docs, but it's a bit of a core tenet of how Kubernetes controllers function. |
(feel free to continue commenting, but I'm going to close this for bookkeeping purposes. I can always re-open it) |
@DirectXMan12 is there a some sort of "best practices" doc for writing a
|
implement SelfSignedCertProvisioner
Create
/Update
/Delete
operations are performed using non-caching clients and return before any caches are likely to have seen the changes. This meansGet
/List
can return stale data for an undeterministic amount of time, could be milliseconds or could be longer based on latency/load on both client and apiserver.Example:
This is something that seems likely to catch quite a few operator developers off guard and could cause a lot of resources to be created when missing if the identifier for the resource is non-deterministic/random.
This relates a little to #180 because the behavior comes from implicit caching.
The text was updated successfully, but these errors were encountered: