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