<p>Using <code>kubectl get with -o yaml</code> on a resouce , I see that every resource is versioned:</p>

<pre><code>kind: ConfigMap
metadata:
  creationTimestamp: 2018-10-16T21:44:10Z
  name: my-config
  namespace: default
  resourceVersion: "163"
</code></pre>

<p>I wonder what is the significance of these versioning and for what purpose these are used? ( use cases )</p>

<p>A more detailed explanation, that helped me to understand exactly how this works:</p>

<blockquote>
  <p>All the objects you’ve created throughout this book—Pods,
  <code>ReplicationControllers, Services, Secrets</code> and so on—need to be
  stored somewhere in a persistent manner so their manifests survive API
  server restarts and failures. For this, Kubernetes uses <code>etcd</code>, which
  is a fast, distributed, and consistent key-value store.  The only
  component that talks to <code>etcd</code> directly is the Kubernetes API server.
  All other components read and write data to etcd indirectly through
  the API server.</p>
  
  <p>This brings a few benefits, among them a more robust <em>optimistic
  locking</em> system as well as validation; and, by abstracting away the
  actual storage mechanism from all the other components, it’s much
  simpler to replace it in the future. It’s worth emphasizing that etcd
  is the only place Kubernetes stores cluster state and metadata.</p>
  
  <p><em>Optimistic concurrency control</em> (sometimes referred to as <em>optimistic
  locking</em>) is a method where instead of locking a piece of data and
  preventing it from being read or updated while the lock is in place,
  the piece of data includes a version number. Every time the data is
  updated, the version number increases. When updating the data, the
  version number is checked to see if it has increased between the time
  the client read the data and the time it submits the update. If this
  happens, the update is rejected and the client must re-read the new
  data and try to update it again. The result is that when two clients
  try to update the same data entry, only the first one succeeds.</p>
  
  <p>The result is that when two clients try to update the same data entry,
  only the first one succeeds</p>
</blockquote>

<p>Marko Luksa, "Kubernetes in Action"</p>

<p>So, all the Kubernetes resources include a <code>metadata.resourceVersion</code> field, which clients need to pass back to the API server when updating an object. If the version doesn’t match the one stored in <code>etcd</code>, the API server rejects the update</p>
