最佳实践

分离配置库和源代码库

使用单独的Git存储库来保存kubernetes清单，将配置与应用程序源代码分开，强烈推荐使用，原因如下:

• 清晰分离了应用程序代码与应用程序配置。有时您希望只修改清单，而不触发整个CI构建。 例如，如果您只是希望增加部署规范中的副本数量，那么您可能不希望触发构建（由于构建周期可能较长）
• 更清洁的审计日志。出于审计目的，只保存配置库历史更改记录，而不是掺有日常开发提交的日志记录。
• 微服务场景下，应用程序可能由多个Git库构建的服务组成，但是作为单个单元部署（比如同一pod内）。 通常，微服务应用由不同版本和不同发布周期的服务组成(如ELK, Kafka + Zookeeper)。 将配置清单存储在单个组件的一个源代码库中可能没有意义
• 访问的分离。开发应用程序的开发人员不一定是能够/应该推送到生产环境的同一个人，无论是有意的还是无意的。 通过使用单独的库，可以将提交访问权限授予源代码库，而不是应用程序配置库
• 自动化CI Pipeline场景下，将清单更改推送到同一个Git存储库可能会触发构建作业和Git提交触发器的无限循环。 使用一个单独的repo来推送配置更改，可以防止这种情况发生。

确保在Git版本中的清单是真正不可变的

当使用像helm或kustomize这样的模板工具时，清单的内容可能会随着时间的推移而改变。 这通常是由对上游helm库或kustomize库的更改引起的。

以下面kustomization.yaml为例

bases:
- github.com/argoproj/argo-cd//manifests/cluster-install

由于这不是一个稳定的目标，因此这个自定义应用程序的清单可能会突然改变内容，甚至不需要对自己的Git存储库进行任何更改。（比如git master分支）

更好的选择是使用Git标记或提交SHA的版本。例如:

bases:
- github.com/argoproj/argo-cd//manifests/cluster-install?ref=v0.11.1