<p>What is the preferred way of updating a set of pods (e.g. after making code changes &amp; pushing underlying docker image to docker hub) controlled by a replication controller in kubernetes cluster?</p>

<p>I can see 2 ways:</p>

<ol>
<li>Deleting &amp; re-creating replication controller manually</li>
<li>Using <code>kubectl rolling-update</code></li>
</ol>

<p>With the <code>rolling-update</code> I have to change the replication controller name. Since I'm storing replication controller definition in YAML file and not generating it manually, having to change the file to push out a code update seems to bring about bad habits like alternating between 2 names for the replication controller (e.g. controllerA and controllerB) to avoid name conflict.</p>

<p>What is the better way?</p>

Madis Nõmme
<p>Update: <code>kubectl rolling-update</code> has been deprecated and the replacement command is <code>kubectl rollout</code>. Also note that since I wrote the original answer the Deployment resource has been added and is a better choice than ReplicaSets as the rolling update is performed server side instead of by the client. </p>

<hr>

<p>You should use <code>kubectl rolling-update</code>. We recently added a feature to do a "simple rolling update" which will update the image in a replication controller without renaming it. It's the last example shown in the <code>kubectl help rolling-update</code> output:</p>

<pre><code>// Update the pods of frontend by just changing the image, and keeping the old name
$ kubectl rolling-update frontend --image=image:v2
</code></pre>

<p>This command also supports recovery -- if you cancel your update and restart it later, it will resume from where it left off. Even though it creates a new replication controller behind the scenes, at the end of the update the new replication controller takes the name of the old replication controller so it appears as pure update rather than switching to an entirely new replication controller. </p>
