<p>I was trying to find some alternative for docker-swarm <code>rollback</code> command, which allows you to specify rollback strategy in the deployment file.
In k8s ideally it should use <code>readinessProbe</code>, and if didn't pass <code>failureThreshold</code> it should rollback, before starting deployment of the next pod (to avoid downtime).</p>

<p>Currently, in my deployment script, I'm using hook <code>kubectl rollout status deployment $DEPLOYMENT_NAME || kubectl rollout undo deployment $DEPLOYMENT_NAME</code>, which works, but it's not ideal because first rollout command will trigger error way after unhealthy pod will be deployed and a healthy one will be destroyed which will cause downtime.</p>

<p>Ideally, it shouldn't even kill current pod before a new one will pass <code>readinessProbe</code></p>

Sarkis Arutiunian
<p>There is no specific rollback strategy in a Kubernetes deployment. You could try a combination of <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment" rel="nofollow noreferrer">RollingUpdate</a> with <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-unavailable" rel="nofollow noreferrer">max unavailable</a> (aka <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-unavailable" rel="nofollow noreferrer">Proportional Scaling</a>), then at some point <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-unavailable" rel="nofollow noreferrer">pause your deployment</a> resume if everything looks good and then rollback if something went wrong.</p>

<p>The recommended way is really to use another deployment as <a href="https://medium.com/google-cloud/kubernetes-canary-deployments-for-mere-mortals-13728ce032fe" rel="nofollow noreferrer">canary</a> split the traffic through a load balancer between canary and non-canary, then if everything goes well upgrade the non-canary and shut down the canary. If something goes wrong shutdown the canary and keep the non-canary until the issue is fixed.</p>

<p>Another strategy is to use something like <a href="https://istio.io/" rel="nofollow noreferrer">Istio</a> that facilitates <a href="https://istio.io/blog/2017/0.1-canary/" rel="nofollow noreferrer">canary deployments</a>.</p>
