在这个例子中，我们将把我们的应用程序部署到Kubernetes，并在最近的部署出现问题时回滚到任何特定的版本。
**重要提示：**当回滚到一个特定的版本时，docker镜像会被拉出，所以要确保每个镜像都有一个独特的标签，并在deployment.yaml ，以便每次部署都能引用。每次你部署一个代码，它的图像标签应该是一个新的。如果你使用latest ，你也将不得不先手动恢复代码，推送图像，这不是一个好的做法，也违背了回滚的目的。简而言之，给docker镜像打上唯一的标签（例如：git hash ），推送它并在deployment.yaml 文件中使用相同的标签。
修订历史的限制
一个部署的修订历史存储在其ReplicaSets中。
可选的.spec.revisionHistoryLimit 键控制应保留多少 ReplicaSets 以便回滚。保留的 ReplicaSets 越多，etcd 中消耗的资源就越多，所以不要把数字定得太高。默认情况下，10个旧的ReplicaSets将被保留。
例子
我们把revisionHistoryLimit ，所以我们永远不会有超过5次的修订。让我们看看我们目前在集群中的情况。
$ kubectl get deployments,replicasets,pods
如你所见，我们有3个ReplicaSets。鉴于部署/发布的修订是由ReplicaSets控制的，我们也应该有3个修订历史。让我们检查一下。
$ kubectl rollout history deployment address-finder-deployment
我们的Pod是一个Web服务器，所以它会打印一个假的字符串，如v1、v2、v3等等。目前它打印的是v3，但我们想回到v2的信息。你可以认为这个修订属于最新的ReplicaSet，也就是3，因为它是底部最新的一个。但是，情况并不总是这样，所以我们先确认一下。
$ kubectl describe replicaset address-finder-deployment-7f9fdc5f48 | grep revision
现在我们确定了我们所处的版本。让我们回到以前的版本，也就是2。
$ kubectl rollout undo deployment address-finder-deployment --to-revision=2
让我们再看看我们目前在集群中的情况。
$ kubectl get deployments,replicasets,pods
正如你所看到的，当前的ReplicaSet已经改变，Pod已经重新启动。让我们也来看看修订历史是什么样子的。
$ kubectl rollout history deployment address-finder-deployment
修订版2现在被提升为4，应该是活动的。让我们确认一下当前的ReplicaSet。
$ kubectl describe replicaset address-finder-deployment-56847c949b | grep revision
这就是了。它告诉我们当前的版本是什么以及它的回滚历史。我们的web服务器现在应该打印v2信息，而不是v3。
命令
// Run/restart rollout/deployment
