Are Kubernetes updates an atomic transaction?

In Kubernetes you will need to communicate with kube-apiserver to view resources or make changes to them.

kube-apiserver is using etcd as a place to store data required by Kubernetes.

etcd is a consistent and highly-available key value store used as Kubernetes' backing store for all cluster data

Kubernetes.io: Operating etcd clusters for Kubernetes

You can read on the official site of etcd:

• Etcd.io: Docs: v3.3.12: Learning: API Guarantees

etcd specific definitions

Operation completed

An etcd operation is considered complete when it is committed through consensus, and therefore “executed” – permanently stored – by the etcd storage engine. The client knows an operation is completed when it receives a response from the etcd server. Note that the client may be uncertain about the status of an operation if it times out, or there is a network disruption between the client and the etcd member. etcd may also abort operations when there is a leader election. etcd does not send abort responses to clients’ outstanding requests in this event.

Guarantees provided

Atomicity

All API requests are atomic; an operation either completes entirely or not at all. For watch requests, all events generated by one operation will be in one watch response. Watch never observes partial events for a single operation.

As you can read above, etcd has a guarantee to be consistent.

More information about the operations on resources can be found in this blog post:

• Blog.atomist.com: Kubernetes apply replace patch

You can read there (blog post is quite lengthy but explanatory):

There may be certain instances when you want to be sure that no changes have been made to a resource between the time you read the resource and when you are updating it. Put another way, you need to make sure all changes to a resource are atomic. This is the use case for updating a resource using replace. For example, if you have a ConfigMap with a counter that is updated by multiple sources, you may want to make sure that two sources do not attempt to update the counter simultaneously, causing you to “lose” an update.

<-- SKIPPED -->

The spec supplied in the replace request should be the fully formed resource spec, not a partial spec and not just the parts required when using kubectl apply. In particular, you must include the current resourceVersion in the spec metadata. If you do not include the resourceVersion or the version you provide is not the current one, the replacement will be rejected.

Additional resources:

I found similar case on Stackoverflow which is also dealing with similar question:

• Stackoverflow.com: Are Kubernetes API calls secret update and configmap update atomic calls?