这篇文章主要介绍“GitOps的工作原理是什么”，在日常操作中，相信很多人在GitOps的工作原理是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”GitOps的工作原理是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
工作原理
GitOps秉承了DevOps的核心理念--“构建它并交付它(you built it you ship it)”。它能够让开发人员在自己所选的Git工具中，提出拉式请求，触发Kubernetes集群的部署，从而使得Git成为唯一的来源。
显然，该思想是将基于推式的管道替换为基于拉式的管道，从而使得开发人员能够直接根据其拉式请求执行部署。而一旦开发人员执行合并或打开请求，该基础结构就会在部署过程中触发一系列的事件。GitOps运算符(operator)只要检测到此类变化，就会导致另一个运算符声明的更改，并将其部署到集群之中。例如，您可以使用如下工具栈来实现GitOps：
将Bitbucket作为您的Git VCS(译者注：Version Control System，版本控制系统)工具。
用Docker存储您的各种镜像。
用Amazon S3来存储各种Helm图表。
用AWS Lambda拉取图表，并提交给集群存储库。
用Weaveworks Flux检测集群存储库中的更改，并做相应的调整。
当然，在您的工具栈中，实现此类功能的实际基础架构可能会有所不同，但是其机制却是相似的。
如下是可以实现的GitOps工作流：
使用 Bitbucket管道之类的CI(持续集成)工具，将各种Docker镜像推送到 Quay之类的托管(hosting)工具处。
各种云功能函数从主存储bucket处，将不同的配置和 helm图表复制到主git存储库中。
诸如 Weaveworks Flux之类的GitOps运算符，会根据各种配置图表去更新集群，并通过Lambda函数提取不同的helm图表。
当然，上述技术栈中所描述的每个工具都有着对应的替代方案，开发团队可以选择最适合的工具，以实现DevOps的目标。例如，同属于Atlassian套件的Jira功能就能够轻松地与Bitbucket协同发挥作用。因此，如果一个拉式请求在Bitbucket中被创建，就会自动将Jira中的问题发送到自定义的“部署”上。这将大幅简化从设计到发布的DevOps实践过程。
类似地，当考虑到通过GitOps实现的持续交付机制可能出现失败时，我们可以添加其他的监控工具，以提供急需的可见性。例如，Thundra.io可被用于监控S3触发的AWS Lambda函数，以确保在将更改提交给集群存储库时，不会发生任何故障。
同理，我们也可以利用Thundra.io的集成功能，将警报发送给Opsgenie之类的报警工具，进而通知合适的值班人员，以快速解决那些由拉式请求触发的部署所引发的任何问题。
可见，我们完全可以通过向GitOps引擎添加更多的功能，以提高GitOps实践过程中的可靠性和便利性。
给带来的Kubernetes的便利性
总的说来，GitOps能够为Kubernetes的部署提供融合、幂等、确定性和自动化等方面的功能。根据Kubernetes强大的收敛机制，它将不断尝试去改变集群的状态，让各种收敛应用都具有相同的结果。而且这些都会自动而迅速地被触发。
Kubernetes的编排器(orchestrator)会持续将各种更改应用到集群中，直到集群收敛到配置更新所定义的状态为止，也就是要满足开发人员或SRE人员所期望的配置状态。这不但适用于所有的Kubernetes资源，还能够被用到自定义资源(Custom Resource Definitions，CRD)或Kubernetes的扩展。
整个GitOps的过程始于在Git存储库中定义某个所需的状态，然后Git被定位为唯一的来源。此外，我们需要保障提交过来的更改能够与群集相配，以便标记处群集是已经收敛到了所需的状态，还是已偏离了该状态。
当期望状态与实际状态不相同时，Kubernetes中的收敛运算符会主动尝试着补足这两个状态之间的差异，即：根据那些针对Git的提交，触发更改的“差异”警报，以标识处仍然需要进一步的收敛。因此，这就意味着，所有的提交都会产生对于集群的可验证的、且幂等的更改。当然，Kubernetes也可能按需产生回滚。就其机制而言，回滚可以被看作是进一步收敛到以前的状态。
最后，如果系统中不再存在“差异”警报、或仅存在“聚合”警报，那么该机制就认为实际状态已经达到了所需的状态。实际上，我们可以使用回调、或回写事件的方法，来设置此类聚合状态。
至此，我们可以认识到：GitOps依赖于IAC(译者注：基础架构即代码)的概念。即：以编程的方式定义了基础架构，而基础架构的实际状态也会随着发生相应的变化。这种就是我们在前文中提到的基于拉式的部署方式，它与传统的基于推式的部署有所不同。
相关工具
如您所知，DevOps是一个广阔的领域，它不仅仅限于软件行业。而GitOps则只是在软件行业朝着更加敏捷、可靠的方向发展过程中，一种新兴的开发实践。更准确地说，随着技术趋势的变化，开发实践必须适应可用的技术，而GitOps是团队和组织如何跟踪技术发展，持续推进开发实践的一种优秀示例。值得一提的是，诸如Weaveworks Flux之类的运算符，可以很好地帮助您在集群启用GitOps。当然，您也可以选用Spinnaker之类的其他代替方案。
此外，考虑到持续部署可能会给生成环境带来风险，我们可以通过添加诸如Thundra.io和Opsgenie之类的工具，来对系统进行全覆盖性的测试，以减少风险点，保证一定的可观察性和事件管理能力。
到此，关于“GitOps的工作原理是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联-成都网站建设公司网站，小编会继续努力为大家带来更多实用的文章！
