给定具有两个名称空间的Kubernetes集群;在命名空间之间监视和同步configmap,部署,入口等方面的差异的推荐方法是什么?

#1 楼

我们目前正在调查https://github.com/roboll/helmfile,以便轻松跨命名空间同步Helm图表。

#2 楼

编辑:此答案中描述的部署脚本非常类似于Helmfile,我们现在正在升级到Helmfile,以便我们可以淘汰运行多个Helm版本的脚本,因为Helmfile做得很好。

这是一个替代性的间接答案。使用基础结构即代码的最佳做法来避免环境不同步。我相信人们会发现它是一个有用的替代建议,因此是有效的答案。

预防胜于治疗。不要通过将您的配置视为代码并通过git管理名称空间而使其不同步。 Helm是Kubernetes配置的软件包管理器。它可以处理任意配置对象,例如Openshift扩展。这使您可以设置部署管道和git工作流,以确保您的环境保持同步。 (更新:使用Helmfile管理多个Helm版本)。

通过我们设置中的一个示例,我们有一个Helm图表,它仅安装configmaps,另一个仅安装秘密。要安装的实际值作为参数传递,例如my-app-secret-values.yaml。因此,我们在git下都有不同的yaml值,并使用一个helm图表在其上进行迭代的部署脚本来加载值并更新相应的configmap或secret。 Helm读取,比较并仅在发生更改时写入。因此,部署脚本将仅导致更改git中已更改的密钥或配置映射。所有配置都在git下,并像代码一样进行管理。然后可以像升级代码一样管理环境之间的同步配置。作为奖励,舵手会为存储在Kubernetes中的每个对象更改的每个版本创建备份。如果让我们列出以前的版本并回滚到以前的配置。同样,由于从git部署了所有内容,因此可以在git中看到所有名称空间中所有设置的历史记录。

我们还将安装和运行主要应用程序,作为通过环境提升的传统Helm图表。这些头盔图表引用了我们想要在给定环境中调整设置时分别部署的配置映射和机密。

#3 楼

Heptio开放了一个名为Theusus的工具来帮助解决此问题。 Kubernetes并没有内置任何功能来执行此操作,但请查看Theusus实用程序,您应该能够编写脚本来执行此操作。