Question

我有一个带有Kubernetes部署YAML的存储库。管道在每次生成时运行，这些生成将映像生成并推送到我们的存储库中，并对该提交进行版本控制（例如my_project:bm4a83）。然后我要更新部署映像

kubectl set image deployment/my_deployment my_deployment=my_project:bm4a83。

这可行，但我也想将其余的部署YAML规范保留在版本控制中。

我以为我可以将其保存在同一存储库中，但这意味着我的更改可能只是基础架构（例如更改replicas）会触发新的构建，而无需更改代码。

感觉最有意义的是将部署YAML保留在完全独立的存储库中。我认为我可以从那里管理所有值，而与实际的代码更改无关。唯一的问题是image键需要保持最新。解决此问题的唯一方法是使用某些浮动:latest类型的版本，但我并不认为这是理想的选择。

什么是明智的管理工作流？我是否完全想念东西？

Answer 1

什么是明智的管理工作流？我是否完全想念东西？

某些答案取决于您尝试采用现有任何流程来降低风险的类型。如果是“集群被飓风摧毁，我需要恢复我的描述符”，那么Heptio Ark是一个很好的解决方案。如果风险更加“以人为本”，那么恕我直言，您将必须在锁定所有事物与削弱kubernetes提供给团队的非常敏捷，授权的工具之间走一条非常谨慎的路线。该模型与您的模型相冲突的一个具体示例是：当开发人员编辑Deployment却不（记住）知道更新仓库中的描述符时会发生什么？那么您是否撤销了编辑权限？使用一些diff-esque逻辑来检测更改的集群内配置？

要对您所说的具体讲话：进行描述符更改只是为了调整(Deployment|ReplicationController|StatefulSet)的大小，这是一个次优的想法。另外，构建良好的CI管道还将了解是否没有任何 buildable 工件发生变化并纾困（如果CI工具那么聪明，则尽早完成，甚至不触发构建）。

最后，如果您确实希望继续当前的情况，那么我可以想到的最佳实践是在应用描述符之前立即进行文本替换：

$ grep "image: " the-deployment.yml
    image: example.com/something:#CI_PIPELINE_IID#
$ sed -i'' -e "s/#CI_PIPELINE_IID#/${CI_PIPELINE_IID}/" the-deployment.yml
$ kubectl apply -f the-deployment.yml

以使回购中的副本在文本上保持原始状态，并且也不会无意中实际应用，因为它实际上不会导致可运行的Deployment。

Answer 2

但是我也想将其余的部署YAML规范保留在版本控制中。

是的，您想要这样做。将所有内容置于版本控制之下是实现不可变基础结构的好习惯。

如果您希望部署具有单独的元数据片段（出于任何审核/更改跟踪原因），为什么不能仅利用Kubernetes metadata块？

metadata:
  name: my_deployment
  commit: bm4a83

然后您通过Jinja，Ruby ERB，Go模板等注入此类信息。

如何不依赖：latest来自动化Kubernetes部署YAML？

2 个答案: