这辆自行车需要一些新的零件。

在我的第一篇关于GitOps的文章《Is GitOps Actually Useful》中，我认为GitOps并没有完全覆盖整个部署流程，也没有充分发挥其潜力。在LinkedIn上的后续讨论中，进一步探讨了一些细节。我认为可以进一步探讨一些缺失或需要改进的地方，并提出一个更完整的解决方案。

在 Kubernetes 用户中，去年 Continuous Delivery Foundation 进行的一项调查表明 GitOps 已经非常流行。用户希望达到更一致的部署策略、更好的配置管理和更快速的交付。

这并不奇怪，大多数 GitOps 用户并不期望直接获得这些功能，例如更快的审批流程或弥补管理 Kubernetes 的技能短板。不过，GitOps 工具在其他方面也一直在改进。

部署不仅仅是个“应用”的过程。在 GitOps 的早期阶段，部署工作流和编排大多是手工搭建的（可以参见这里）。随着像 ArgoCD 和 Flux 这样的热门项目的生态系统的发展，这些缺口已经得到了弥补。

• 自动部署新镜像：ArgoCD 和 Flux 都具有自动部署新镜像的机制。ArgoCD 和 Flux。

• 跨环境部署：一些用户尝试使用 Git 分支来建模环境（如 dev、staging、prod），而另一些则使用子目录。在 Argo 生态系统中，Kargo 现在解决了多阶段部署管道中的阶段间部署问题。据我所知，Flux 没有类似的工具——如果有，请告诉我。我知道可以通过使用 Github Actions 或自定义控制器构建解决方案。

• 金丝雀部署、蓝绿部署和渐进交付：Argo Rollouts 通过与大量路由器集成的流量切换支持这些部署策略。Flux 通过 Flagger 支持这些部署策略。

• 自动回滚：Argo Rollouts 和 Flux/Flagger 在不满足成功标准的情况下支持自动回滚。

• 来自监控系统的成功或失败信号：Argo Rollouts 和 Flux/Flagger 分析监控指标以评估部署的成功与否。

• 多集群部署：有许多手动编排多集群部署的方法，但当集群数量超过几个时，自动化变得必要。目前的指南仍然集中在如何使用中心辐射架构等方法进行多集群部署，而不是如何以与上述单集群部署机制同样复杂的方式管理部署。ArgoCD ApplicationSet 和 WeaveWorks GitOpsSets 可以跨集群生成不同的配置，但并没有解决部署问题。这似乎是一个需要进一步研究的领域。

ArgoCD 和 Flux 正在向成熟的部署工具发展，它们依靠持续的协同循环作为机制。不过，它们也受限于对 Git 的依赖，这限制了它们的发展。

GitOps 类工具如 ArgoCD 和 Flux 将更多的工作流交给 Git 和 Git 提供商处理。

变更控制的工作流、审查与批准，以及预部署策略的执行依赖于 git 提供商的变更请求，例如 GitHub PR 和 GitLab MR，以及它们支持的 钩子机制 用于控制合并过程。git 提供商通常可以配置为你需要的功能，但感觉更像是在搭建一个鲁布·戈德堡装置，而不是使用一个专为此而设计的产品。

也许是因为有人工审核变更的假设，自动更新git配置的情况相对较少。我不清楚自动更新镜像的工具或服务是否被广泛使用，更不用说其他种类的自动化更改了。

Git 中的内容决定了什么会被部署，因此更改可能被部署的资源的权限控制由 Git 权限决定。

因为这些控制通常是在仓库级别设置的，因此配置的组织方式（不仅包括单个仓库内部，还包括仓库之间）对用户的工作效率和安全性有很大影响。

还有一个问题是轮询Git仓库的可访问性、可靠性和可扩展性，这也是为什么一些人选择将配置推送到容器注册表中的原因，而不是从Git拉取配置（参见《在容器注册表中存储配置的优势》：https://medium.com/@bgrant0607/advantages-of-storing-configuration-in-container-registries-rather-than-git-b4266dc0c79f）。

其他批评包括缺乏可见性、缺乏结构化的状态信息、验证不足以及处理机密信息的可行方案不足。

用 git 来管理和部署 Kubernetes 配置是暂时的解决办法，但远非最佳选择。

GitOps 的关键见解在于持续地将特定的声明性配置与其真理源保持一致，相对于通过变更位于git仓库中的某个不确定位置的配置来触发一个有限且不透明的部署管道。

要充分发挥 GitOps 的潜力，它需要减少对 git 的依赖。虽然名字里有 Git，GitOps 原则 并没有说 git 是 GitOps 必不可少的部分，或者 GitOps 工具必须从 HEAD 进行部署，或者必须由在目标集群运行的控制器来操作 GitOps，或者发现漂移后必须消除它。

我们需要重新评估我们如何实现目标，并回到关键见解的核心原则。

你认为GitOps相对于其他部署方法有哪些优势？具体有哪些优势？你是否认为当前的自己动手部署方法已经足够好？你是否希望自动更新配置更简单一些？你是否希望可以直接授予或撤销修改特定资源或资源类型的权限？你如何处理或避免使用GitOps时的密钥信息？你对GitOps工具处理偏差的方式满意吗？你是否希望保留直接对实时状态所做的更改？

随时可以在这里回复，或者您可以在 LinkedIn 或 X/Twitter 上发私信给我，这些平台上都会发布这条消息。

如果你对这感兴趣，你可能会对《基础设施即代码和声明式配置系列》中的其他文章感兴趣。