<p>I'm very new to Kubernetes and using k8s v1.4, Minikube v0.15.0 and Spotify maven Docker plugin.
<br>The build process of my project creates a Docker image and push it directly into the Docker engine of Minikube.</p>

<p>The pods are created by the Deployment I've created (using replica set), and the strategy was set to <code>type: RollingUpdate</code>.</p>

<p>I saw this in the documentation:</p>

<blockquote>
  <p><strong>Note</strong>: a Deployment’s rollout is triggered if and only if the Deployment’s pod template (i.e. .spec.template) is changed.</p>
</blockquote>

<p><br>I'm searching for an easy way/workaround to automate the flow:
Build triggered > a new Docker image is pushed (withoud version changing) > Deployment will update the pod > service will expose the new pod.
<br></p>

<p>when not changing the container image name or tag you would just scale your application to 0 and back to the original size with sth like:</p>

<pre><code>kubectl scale --replicas=0 deployment application
kubectl scale --replicas=1 deployment application
</code></pre>

<p>As mentioned in the comments already <code>ImagePullPolicy: Always</code> is then required in your configuration.</p>

<p>When changing the image I found this to be the most straight forward way to update the </p>

<pre><code>kubectl set image deployment/application app-container=$IMAGE
</code></pre>

<p>Not changing the image has the downsite that you'll have nothing to fall back to in case of problems. Therefore I'd not suggest to use this outside of a development environment.</p>

<hr>

<p>Edit: small bonus - keeping the scale in sync before and after could look sth. like:</p>

<pre><code>replica_spec=$(kubectl get deployment/applicatiom -o jsonpath='{.spec.replicas}')
kubectl scale --replicas=0 deployment application
kubectl scale --replicas=$replica_spec deployment application
</code></pre>

<hr>

<p>Cheers</p>
