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 specific definitions
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.
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:
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.
I found similar case on Stackoverflow which is also dealing with similar question: