<p>I find that when I do scheduled <code>docker stack deploy</code>ments and they happen around the same time I may get an "update out of sequence" error in a deployment.</p>

<p>I've seen many bugs and issues on this</p>

<ul>
<li><a href="https://github.com/moby/moby/issues/39891" rel="nofollow noreferrer">https://github.com/moby/moby/issues/39891</a></li>
<li><a href="https://github.com/moby/moby/issues/30794" rel="nofollow noreferrer">https://github.com/moby/moby/issues/30794</a></li>
<li><a href="https://github.com/docker/swarmkit/issues/1379" rel="nofollow noreferrer">https://github.com/docker/swarmkit/issues/1379</a></li>
</ul>

<p>Some of them are closed, but the problem apparently still persists to this day for some people.  I was wondering if Kubernetes has solved this issue so it does not happen on K8S clusters.</p>

Archimedes Trajano
<p>I wouldn't say the general issue is "solved" in Kubernetes as any shared system updating data can have synchronisation issues. You won't run into the issue often with the kubernetes primitives though.</p>

<p>That is until you start using complex, external Kubernetes API clients. Another area might be <a href="https://kubernetes.io/docs/concepts/architecture/controller/" rel="nofollow noreferrer">controllers</a> competing with you to make updates (e.g the <a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/" rel="nofollow noreferrer">horizontal auto scaler</a> setting <code>replicas</code>).</p>

<h3>Update example</h3>

<p>All kubernetes resources have a "resource version" in their metadata and it's possible for that data to be updated out of band with another change. This generally happens when data needs to be retrieved and inspected for an update to be made:</p>

<ol>
<li>A retrieves <code>val</code></li>
<li>A increments <code>val</code></li>
<li>B retrieves <code>val</code></li>
<li>B increments <code>val</code></li>
<li>A applies <code>val</code>, <code>resourceVersion</code> increments</li>
<li>B applies <code>val</code>, <code>resourceVersion</code> mismatch, fails. </li>
</ol>

<p>You could also add "C" into the mix. "C" isn't a very responsible shared api client (Bad C!). When applying it's <code>val</code> change, C doesn't supply a <code>resourceVersion</code> on it's update and silently blats any updates that were made since it retrieved <code>val</code>.</p>

<p>You will find that most kubernetes resources can be managed <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/object-management/" rel="nofollow noreferrer">declaratively</a>. So by applying PATCHes to an existing resources atomically on the kube apiserver (that atomicity is for a single resource).</p>
