Kubernetes允许我们单纯地使用声明性的配置文件来管理我们的应用部署和其他基础设施组件（例如，我们现在都是YAML开发者）。这使我们能够把所有这些文件放到Git仓库中，然后把它挂到流水线上（Jenkins、GitLab等），流水线会把这些变化应用到集群上，然后就有了GitOps。如果你还不了解GitOps是什么，可以查看我们之前发布过的文章：GitOps初阶指南：将DevOps扩展至K8S
为了使工作正常进行，我们必须确保改变集群的唯一方法是在Git仓库上提交。GitOps并不是专门针对Kubernetes的，同样的原理也可以应用于任何其他声明式配置管理的环境。
可以说，很多企业已经开始采用GitOps了，但现在是业界开始充分认识到其潜力的时候。所以，让我们深入了解一下它如此出色的原因吧！
1、存储环境变更历史记录
只有通过更新相应Git仓库中的配置，才能改变应用环境。这将创建一个完整的状态变化的历史记录，包括谁做了更改和为什么更改的记录。你可以通过正在使用的Git用户界面来读取历史记录。
2、轻松回滚到之前的状态
一旦我们所有的变更都被存储为Git历史记录，就可以很容易地将一个环境回滚到之前的任何状态。通过还原一些commit，我们可以回到以前的工作状态。
3、保障部署安全
一旦对集群的所有更改都通过GitOps repo，用户和持续集成(CI)流程就不需要再访问集群了。这大大降低了攻击面，尤其是还可以减少对Kubernetes API的网络访问。
部署过程无论如何实现，都可以在集群内部运行，并从Git中拉取配置。其对API的访问使用基于角色的访问控制（RBAC）进行限制。这极大地提高了集群的安全性，防止任何恶意的远程更改在API服务器上。
4、轻量化审批程序
在修改生产环境时，开发人员总是不受信任。因此在许多公司中都建立了四眼审批流程（four-eyes approval processes），不论是出于什么原因建立的审批流程，GitOps都提供了一个简单的方法来实现它们。
具体实现方式取决于你使用的Git服务器，但重点是给开发人员在Git repo上创建拉取请求的权利，同时给另一组人审查和合并的权利。大多数Git服务器都有一个很好的UI来检查修改和批准拉取请求——所以这个解决方案不仅便宜，而且对用户也相当友好。
5、模块化架构
GitOps有3个部分：Git repo、部署流程以及一个在Git repo中自动更新版本的过程。这三者可以相互独立演化或替换。
一边是一个组件在Git repo写入，另一边是一个组件在读取。Git repo的结构成为这些组件之间的桥梁。由于这是一个相当松散的耦合，两边可以用不同的方式甚至不同的技术栈来实现。
6、独立于工具的架构
第5点中提到的模块化可以看出GitOps架构是一个可以灵活组装最佳工具的架构。当然，任何流行的Git服务器都可以完成Git部分的工作，FluxCD或ArgoCD可以负责将repo同步到集群。JenkinsX是一个处理这个过程所有部分的工具，包括创建Git repos，并在构建新的Docker镜像时用新版本更新它们。
7、复用现有知识
将 Git 置于部署流程的核心，可以充分利用大多数开发人员和运维人员已经掌握的 Git 知识。不需要新的工具来浏览部署历史或实施审批流程。所有的流程都是用大家都熟悉的工具来完成的。
8、比较不同的环境
当你有一个从开发到用户接受度测试（UAT）再到生产的环境链时，跟踪这些环境之间的差异是一件很麻烦的事情。多亏了存储在Git repos中的声明式配置，它使得处理环境间差异就像比较一组YAML文件一样简单。
我们有非常棒的工具来做这件事，所以这将不再是一个问题。更重要的是，从头开始创建一个新的环境，就像复制和粘贴这些文件到一个新的repo中一样简单。
9、开箱即用的备份
由于你的环境状态存储在Git中，如果Kubernetes上的etcd发生了什么事情，你也永远不会丢失数据。因为它是你集群状态的自然备份。
10、像应用程序代码一样测试你的更改
你可以用测试应用程序代码的方式来测试环境中可能出现的破坏性变化。将更改放在一个分支上，然后在其上运行 CI 流水线。你的 CI 工具将能够运行测试，并根据测试结果将 Git 中的 pull-request 状态设置为绿色或红色。一旦所有的东西都经过测试和审查，你就可以合并到master。
这听起来非常简单，但自动化测试是基础设施管理中经常被忽视的任务。虽然GitOps并没有让它变得更容易，但至少它为你提供了与你在其他地方使用的相同的熟悉工作流程。
11、高可用部署基础设施
部署基础设施保持一致很重要。Git repo服务器通常已经以复制、高可用的方式进行了设置。源代码是所有开发人员在大多数时间都需要访问的东西，所以使用Git作为部署的源码并不会给Git本身增加额外的负担。