共计 1984 个字符，预计需要花费 5 分钟才能阅读完成。
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 自身减少额定的累赘。
