Kubernetes的.spec.revisionHistoryLimit用于跟踪部署定义的更改，由于这些定义是小的yaml文件，因此在必要时保留100个或更多的定义似乎并不太多（考虑到现代云服务器的典型条件）。根据文档，它将被设置为2（而不是无限）。为什么会这样？
.spec.revisionHistoryLimit
lb3vh1jj1#
保持无限制会最终堵塞etcd和iiuc etcd不是为大数据使用而设计的。而且Kubernetes控制平面是定期同步和下载的，这意味着会有很多不必要的数据需要处理。想象一下一个每天部署的服务，它运行了一年多。我觉得把它设置成一个像100这样的大数字是很随意的，为什么不是1000或者9001呢？除此之外，我无法想象会有人想要回滚100个版本。无论如何，我们只是讨论一个默认设置，所以如果您的用例需要，您可以将其设置为一个非常大的数字。
1条答案
按热度按时间lb3vh1jj1#
保持无限制会最终堵塞etcd和iiuc etcd不是为大数据使用而设计的。而且Kubernetes控制平面是定期同步和下载的，这意味着会有很多不必要的数据需要处理。想象一下一个每天部署的服务，它运行了一年多。
我觉得把它设置成一个像100这样的大数字是很随意的，为什么不是1000或者9001呢？除此之外，我无法想象会有人想要回滚100个版本。
无论如何，我们只是讨论一个默认设置，所以如果您的用例需要，您可以将其设置为一个非常大的数字。