<p>I see there are two ways to move back to the older deployment version. One is using rollout undo command and another option is to deploy again to the older version. Is there any difference between the two or they both are interchangeable?</p>

Mohit Gupta
<p>As I understood, you're asking for a difference between doing <code>undo</code> and manually changing <code>pod</code> definitions to the exact previous state. If that's the case - read below.</p>
<p>When you do a new deployment and if in that deployment your pod definitions' hash has been modified - the <code>Deployment Controller</code> will create a new <code>ReplicaSet</code> (let's call it <code>A</code>) in order to roll out new version, but at the same time it will decrease replica count in the existing <code>ReplicaSet</code> (let's call it <code>B</code>) - so you have 2 <code>ReplicaSet</code>s (<code>A</code>, <code>B</code>). How it does this - depends on rollout strategy you choose (for example: <code>rolling updates</code>, <code>blue-green deployment</code> and so on).</p>
<p>When you do <code>kubectl rollout undo deploy &lt;your deployment&gt;</code> - the <code>Deployment Controller</code> will basically decrease the number of replicas in your newly created <code>ReplicaSet</code> (<code>A</code>) and increase the number of replicas in the old <code>ReplicaSet</code> (<code>B</code>).</p>
<p>But, when you do, as you said: <code>deploy again to the older version</code> - you basically do a new deployment, so new <code>ReplicaSet</code> (<code>C</code>) will be created in order to roll out your new version (even if it's not a new version), and your existing <code>ReplicaSet</code>s(<code>A</code>) replica count will be decreased.</p>
<p>So, basically the difference is the <code>ReplicaSet</code>s which gets created.</p>
<p>Read: <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" rel="nofollow noreferrer">Deployments</a> for more info</p>
<p>The whole flow is as following:</p>
<ul>
<li><code>Deployment Controller</code> manages <code>ReplicaSet</code>s</li>
<li><code>ReplicaSet</code> changes desired <code>pod</code> count in <code>etcd</code></li>
<li><code>Scheduler</code> schedules the <code>pod</code></li>
<li><code>Kubelet</code> creates/terminates actual pods</li>
</ul>
<p>And all of them talk to <code>API Server</code> and watch for changes in resource definitions via watch mechanism, again via <code>API Server</code></p>
