<p>I've a new Docker image and I'd like ideally to perform a smooth upgrade to it and either forget the previous deployed version or keep only the previous version but not all previously deployed versions.</p>

<p>Kubernetes Pods will retrieve upon being restarted the latest image if it's tagged <code>:latest</code> or <code>imagePullPolicy: Always</code>.</p>

<p>However unless the image tag changed, doing a <code>kubectl apply</code> or <code>kubectl replace</code> will not restart Pods and hence will not trigger pulling the latest image. Tagging it means a complicated script to always remove old tagged images (useless someone has a trick here).</p>

<p>Doing a <code>kubectl rolling-update ... --image ...</code> is possible if there is a single container per pod only.</p>

<p>What works and is eventually clean and always gets the latest is deleting the namespace and re-creating all pods/rc/services...</p>

<p>How can I ask Kubernetes to use my new images nicely even if there is more than one container per Pod?</p>

<p>Dirty workaround (not tested): you can scale down rc to 0 and then up to original size => it'll be "pod" restart. Or you can use 2 active(non 0 size)/passive(size 0) rc, which will be included in the same service. And you will be scaling them up/down.</p>

<blockquote>
  <p>Tagging it means a complicated script to always remove old tagged
  images (useless someone has a trick here).</p>
</blockquote>

<p>Tagging is nice explicit process. <a href="http://kubernetes.io/v1.1/docs/admin/garbage-collection.html" rel="noreferrer">Kubernetes Garbage collection</a> will delete your old images automatically. Hopefully you know, that if you are using only latest tag, then rollback can be impossible. I recommend to set up tag system, for example <code>:latest_stable, :latest_dev, :2nd_latest_stable, ...</code>. </p>

<p>These tags will be only "pointers" and your CI will be moving them. Then you can define and script some smart registry delete tag policy, e.g. all tags older than <code>2nd_latest stable</code> can be deleted safely. You know your app, so you can set up policy, which will fits your needs and release policy.</p>

<p>Tag example - start point builds 1/2/3 (build id, git id, build time, ...) - build 1 is <code>:production</code> and <code>:canary</code>, all tags are pushed:</p>

<pre><code># docker images
REPOSITORY                                  TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
image                                       3                   a21348af4283        37 seconds ago      125.1 MB
image                                       2                   7dda7c549d2d        50 seconds ago      125.1 MB
image                                       production          e53856d910b8        58 seconds ago      125.1 MB
image                                       canary              e53856d910b8        58 seconds ago      125.1 MB
image                                       1                   e53856d910b8        58 seconds ago      125.1 MB
</code></pre>

<p>Build 2 is going to be <code>:canary</code>:</p>

<pre><code># docker tag -f image:2 image:canary
# docker push image:canary
# docker images
REPOSITORY                                  TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
image                                       3                   a21348af4283        6 minutes ago       125.1 MB
image                                       canary              7dda7c549d2d        6 minutes ago       125.1 MB
image                                       2                   7dda7c549d2d        6 minutes ago       125.1 MB
image                                       production          e53856d910b8        7 minutes ago       125.1 MB
image                                       1                   e53856d910b8        7 minutes ago       125.1 MB
</code></pre>

<p>Tests OK, build 2 is stable - it'll be <code>:production</code>:</p>

<pre><code># docker tag -f image:2 image:production
# docker push image:production
# docker images
REPOSITORY                                  TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
image                                       3                   a21348af4283        9 minutes ago       125.1 MB
image                                       2                   7dda7c549d2d        9 minutes ago       125.1 MB
image                                       canary              7dda7c549d2d        9 minutes ago       125.1 MB
image                                       production          7dda7c549d2d        9 minutes ago       125.1 MB
image                                       1                   e53856d910b8        10 minutes ago      125.1 MB
</code></pre>

<p>Homework: actually build 2 is not stable -> set <code>:production</code> to build 1 (rollback) and <code>:canary</code> to build 3 (test fix in build 3). If you are using only <code>:latest</code>, this rollback is impossible</p>

<p><code>kubectl</code> rolling update/rollback will use explicit <code>:id</code> and your cleaning script can use policy: all tags older than <code>:production</code> can be deleted.</p>

<p>Unfortunately I don't have experience with Kubernetes deployment.</p>
