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自身减少额定的累赘。