来继续讨论Pod的设计：既然它现在是可变的了，那么我接下来考虑的事情自然而然就是Pod回滚。为此，让我们保留Pod旧版本的定义，如此一来“回滚到特定旧版本”就轻而易举了。

现在，Pod更新流程如下：编写文件更新Pod定义，并进行更新以符合预期定义。更新出错?回滚上一个版本，流程结束。

上述流程的好处是：无需依赖所谓的GitOps，即可轻松了解到集群中应用的版本迭代。如无必要就不用引入GitOps，尽管它有不少优点。如果，你只希望解决一个很基本的“集群发生了什么变化?”的问题，仅仅使用集群中的数据就够了。

其中还涉及到更多设计细节。尤其是我想将外部更改(用户提交Pod的变更)与系统变更(Kubernetes内部触发的Pod定义变更)这两者区分开。我还没有考虑清楚如何对这两种变更的历史信息进行编码，并使得运维人员和其他系统组件都可以获取到这些变更。也许可以设计成完全通用的，“修改人”在提交新版本时会标识自己。然后用户可以指定特定修改人(或排除特定修改人)以查询某类变更(类似于标签查询的工作原理)。同样的，这里还需要更多的设计考量，我确定的是我想要一个具有版本管理特性的Pod对象，可以查询它的历史版本记录。

最后，还需要考虑垃圾回收。具体说就是，对每个Pod的更改应该可以很好地进行增量压缩。默认设置是保留所有变更内容，积累到一定数据量后，在此基础上进行一次压缩。保留所有变更内容也会对系统产生一定压力，但可避免“因频繁提交更改”而给系统的其它部分带来影响。这里用户要注意，为方便聚合，应该进行次数更少同时更有意义的变更，而不是每次改动一个字段进而产生一系列版本。

一旦有了历史版本这个功能后，我们还可以整一些其它的小功能。例如，节点可以将最近的若干个版本的容器镜像保留在节点上，从而使回滚更快。原来的垃圾回收超过一定期限就触发，有了历史版本记录，可以更精确地保留需要的版本数。概括而言，所有编排软件都将旧版本用作各种资源对象的GC roots，以加快回滚速度。回滚是避免服务中断的基本方式，这是非常有价值的事情。