<p>Here is something I noticed in my <code>kubectl get events</code> output</p>

<pre><code>Warning   FailedToUpdateEndpoint   Endpoints                 Failed to update endpoint mynamespace/myservice: Operation cannot be fulfilled on endpoints "myservice": the object has been modified; please apply your changes to the latest version and try again
</code></pre>

<p>I am aware of <a href="https://stackoverflow.com/questions/51297136/kubectl-error-the-object-has-been-modified-please-apply-your-changes-to-the-la">this discussion</a>, but I do not think is applicable, given I am not explicitly creating an <code>Endpoint</code> resource via <code>yaml</code>.</p>

<p>I am noticing some minor service unavailability during image updates so I am trying to check if this is related.</p>

<p>Using GKE with version <code>v1.12.7-gke.25</code> on both masters and nodes, on top of <code>istio</code>.</p>

<p>It's common behaviour of <strong>k8s</strong> to let the k8s clients (Controllers) know to try again. </p>

<blockquote>
  <p>Kubernetes leverages the concept of resource versions to achieve <strong>optimistic concurrency.</strong> <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency" rel="noreferrer">concurrency-control-and-consistency</a></p>
</blockquote>

<p>It's populated by the system.</p>

<blockquote>
  <p>To enable clients to build a model of the current state of a cluster, all Kubernetes object resource types are required to support consistent lists and an incremental change notification feed called a watch. Every Kubernetes object has a resourceVersion field representing the version of that resource as stored in the underlying database. When retrieving a collection of resources (either namespace or cluster scoped), the response from the server will contain a resourceVersion value that can be used to initiate a watch against the server. The server will return all changes (creates, deletes, and updates) that occur after the supplied resourceVersion. This allows a client to fetch the current state and then watch for changes without missing any updates. If the client watch is disconnected they can restart a new watch from the last returned resourceVersion, or perform a new collection request and begin again <a href="https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes" rel="noreferrer">efficient-detection-of-changes</a></p>
</blockquote>
