如果kubernetes已经跟踪了kubernetes部署配置，为什么我要将其存储到源代码管理中？

Kubernetes的最佳实践之一是将配置存储在版本控制中。这是在中提到的，也是在堆栈溢出问题中总结的。原因是，如果有必要，这将加快回滚速度

我的问题是，如果Kubernetes已经存储了这个配置，并且我们可以很容易地使用一些方法，那么为什么我们需要存储这个配置？例如，命令如下：

kubectl rollout history deployment/nginx-deployment

存储配置不是对一条信息的不必要复制吗？我们必须保持同步

我问这个问题的原因是我们正在Kubernetes之上构建一个配置服务。用户将与it交互以配置多个部署，我想知道我们是否应该在数据库中保留Kubernetes配置和configMaps内容的历史记录，以备可能的回滚，或者我们是否应该仅仅依靠Kubernetes检索当前配置并回滚到配置的早期版本。

您可以使用Kubernetes作为配置存储，就你而言，只是你可能不想这么做。通过将配置存储为代码，您可以获得以下好处：

• 配置更改会得到定期的代码检查
• 它们被版本化、可扩散等
• 他们可以被测试，起毛，和任何你想要的
• 它们可以被重构、共享代码和文档化
• 所有这些都是在被推到库伯内特斯之前发生的

这可能看起来很糟糕（“但是我的配置已经过时了！”），但请记住，配置实际上从来没有过时过——仅仅因为您告诉Kubernetes您希望运行3个副本并不意味着有，或者如果有，1现在暂时没有停止，等等

配置表示意图。当你的意图改变或与现实不符时，你需要一个不同的过程来真正注意到，并做到这一点。对于Kubernetes来说，存储是etcd，由主控器在一个循环中永远确保存储的意图符合现实。对于您来说，存储是源代码控制，无论您想要什么过程，自动化还是非自动化，都可以永远处于循环中，确保您的代码最终反映在Kubernetes中

---

因此，rollback命令只是“请立即执行此操作！”的快捷方式。它适用于当您的配置意图错误且您没有时间修复它时。一旦您回滚，您应该跟踪您的配置并在那里更新它。从某种意义上说，这确实是重复，但与正常流程相比，这是一个罕见的事件，总体好处大于缺点。

Kubernetes群集不存储您的配置，而是在服务器运行应用程序代码时运行配置。

目标是将配置配置为代码。您希望能够查看、测试、筛选、跟踪、标记、发布等您的配置。您还需要一个单一的真实来源，即摆在您面前的一组文件，而不是Kubernetes存储的配置集合。但如果系统将自动适应负载、硬件故障等，那么实际配置可能与我们指定的配置不同，对吗？我想知道真相的唯一来源是Kubernetes本身还是存储在存储库中的配置文件。我的意思是，如果整个集群崩溃，会发生什么？或者，如果您想制作另一个完全相同的复制品，但环境不同？在代码中让它变得更容易。@ PrEnNialista：考虑这个工作流：有人想将一些配置参数更改为X。他们发送了一个代码审查来进行这种更改，在那里可以进行正常的审查，提交，所以现在存储意图，一些系统决定何时部署安全窗口（例如，在营业时间），当该窗口出现时，它将配置推送到Kubernetes，Kubernetes从那里获取配置。如果最初的改变是直接对库伯内特斯做出的，你如何获得同样的控制和可听性？我不是说你不能直接使用Kubernetes，我是问你为什么要这样做？@GManNickG：你是对的，你提供了一个用例，给出了更多的理由，说明为什么有人希望将配置保留在源代码控制中。我这样问是因为，正如我在问题末尾提到的，我们正在kubernetes之上构建一个“配置服务”，允许用户部署我们的系统，而无需处理kubernetes概念。这个讨论让我觉得我应该存储用户指定的配置。我只是担心，如果用户修改这个配置，他会修改一个不反映系统真实状态的配置。