Are Kubernetes API calls secret update and configmap update atomic calls?

Question

Is client.Secrets(namespace).Update(secret) an atomic call? If this call fails somehow, does the original secret stored in Kubernetes API server get corrupted?

https://github.com/kubernetes/client-go/blob/d1b30110f1abd3b2fb21c5c2daad4345ede8a9fc/kubernetes/typed/core/v1/secret.go#L41

Similarly, is core.ConfigMaps(namespace).Update(configmap) an atomic call? If this call fails, does the existing configmap get corrupted?

Pizor

Answer 1

client-go UPDATE is an HTTP PUT, so it will replace the object, and is an atomic operation. However there is circumstances to think about when doing this, e.g. if there is multiple clients operating on the same object... you should look in this linked client-go example with alternative solutions:

https://github.com/kubernetes/client-go/blob/master/examples/create-update-delete-deployment/main.go#L109-L123

Droshky

Answer 2

According to Kubernetes documentation in section about Server Side Apply you can find the following:

Changes to an object’s fields are tracked through a “field management“ mechanism. When a field’s value changes, ownership moves from its current manager to the manager making the change. When trying to apply an object, fields that have a different value and are owned by another manager will result in a conflict. This is done in order to signal that the operation might undo another collaborator’s changes. Conflicts can be forced, in which case the value will be overriden, and the ownership will be transfered.

---

And some information about merge strategy.

Merge strategy

The merging strategy, implemented with Server Side Apply, provides a generally more stable object lifecycle. Server Side Apply tries to merge fields based on the fact who manages them instead of overruling just based on values. This way it is intended to make it easier and more stable for multiple actors updating the same object by causing less unexpected interference.

When a user sends a “fully-specified intent” object to the Server Side Apply endpoint, the server merges it with the live object favoring the value in the applied config if it is specified in both places. If the set of items present in the applied config is not a superset of the items applied by the same user last time, each missing item not managed by any other appliers is removed. For more information about how an object’s schema is used to make decisions when merging, see sigs.k8s.io/structured-merge-diff.

Hope this helps.

---

Edit: Yes, apply and update use this features.

Apply and Update

The two operation types considered by this feature are Apply (PATCH with content type application/apply-patch+yaml) and Update (all other operations which modify the object). Both operations update the managedFields, but behave a little differently.

For instance, only the apply operation fails on conflicts while update does not. Also, apply operations are required to identify themselves by providing a fieldManager query parameter, while the query parameter is optional for update operations. Finally, when using the apply operation you cannot have managedFields in the object that is being applied.

Pollard

Thanks, Piotr. Does this imply that secret update and configmap update use merging strategy? If the merge fails, the new fields values are removed, and ownership is not transferred? – Pizor