有各种各样的工具可以将软件部署到Kubernetes集群。在这些工具的上下文中，甚至出现了一个新的运营Ops术语：GitOps。
我们将描述GitOps工作流程的原理和模式，以及如何实现它们以在生产中和大规模运行Kubernetes。我们还将描述GitOps与基础架构代码（IAC）配置管理工具之间的区别，当然还会向您展示如何在自己的开发环境中采用GitOps最佳实践。
GitOps是一种进行Kubernetes集群管理和应用交付的方式。它通过将Git用作声明性基础结构和应用程序的单一事实来源来工作。借助GitOps，软件代理的使用可以提醒Git与集群中正在运行的集群之间的任何差异，如果存在差异，Kubernetes协调器会根据情况自动更新或回滚集群。通过将Git置于交付管道的中心，开发人员可以使用熟悉的工具发出拉取请求，以加速和简化Kubernetes的应用程序部署和操作任务。
用于构建云本机应用程序的操作模型
GitOps可以归纳为以下两点：
- Kubernetes和其他云原生技术的运行模型，提供了一组最佳实践，这些最佳实践统一了容器化集群和应用程序的部署，管理和监视。
- 通往开发人员管理应用程序体验的途径；将端到端CICD管道和Git工作流同时应用于操作和开发。
GitOps原理
要开始使用GitOps工作流程管理集群，必须具备以下条件：
＃1。整个系统以声明方式进行描述。
Kubernetes只是许多“声明性”的现代云原生工具的一个示例，可以将其视为代码。声明式意味着配置是由一组事实而不是一组指令来保证的。在Git中对应用程序的声明进行版本控制后，您就有了一个真实的来源。然后，您的应用程序可以轻松部署并在Kubernetes之间回滚。更重要的是，当灾难来袭时，集群的基础架构也可以可靠，快速地进行复制。
＃2。在Git中规范化了所需的规范系统状态。
将系统声明存储在版本控制系统中，并作为真理的规范来源，您可以在一个地方获取和驱动所有内容。这使回滚变得微不足道；您可以在其中使用“ Git还原”返回到之前的应用程序状态。借助Git出色的安全性保证，您还可以使用SSH密钥对提交进行签名，以对代码的作者和出处强制执行强有力的安全性保证。
＃3。批准的更改可以自动应用于系统。
一旦将声明的状态保存在Git中，下一步就是允许对该状态的任何更改自动应用于您的系统。这样做的重要意义在于，您不需要集群凭据即可对系统进行更改。使用GitOps，存在一个隔离的环境，状态定义位于外部。这使您可以将自己的工作和打算的方式分开。
＃4。软件代理可确保正确性并警告差异。
一旦声明了系统状态并受版本控制，只要现实不符合您的期望，软件代理就会通知您。使用代理还可以确保您的整个系统都能自我修复。通过自我修复，我们不仅意味着节点或容器发生故障（它们由Kubernetes处理），而且从更广泛的意义上讲，例如人为错误。在这种情况下，软件代理将充当您操作的反馈和控制回路。
GitOps的主要优点
当对Git进行更改时，自动化的交付管道将对您的基础结构进行更改。但是GitOps的想法远不止于此–它使用工具将整个应用程序的实际生产状态与源代码控制下的内容进行比较，然后告诉您何时集群与现实世界不符。
通过应用GitOps最佳实践，您的基础架构和应用程序代码都有“真理之源”，从而使开发团队可以提高速度并提高系统可靠性。
应用GitOps最佳实践的好处是深远的，并提供：
- 提高生产率 带有集成反馈控制回路的持续部署自动化可加快平均部署时间。您的团队每天可以发送30-100倍的更改，从而将整体开发输出提高2-3倍。
- 增强的开发人员体验 推送代码，而不是容器。开发人员可以使用熟悉的工具（如Git）更快地管理Kubernetes的更新和功能，而无需了解Kubernetes的内部。新入职的开发人员可以在几天（而不是几个月）内迅速掌握并提高生产力。
- 改进的稳定性当您使用Git工作流来管理集群时，您会自动获得一个方便的审核日志，以记录Kubernetes以外所有集群的变化。谁执行了什么操作以及何时对群集执行了审核跟踪可用于满足SOC 2合规性并确保稳定性。
- 更高的可靠性借助Git的还原/回滚和分叉功能，您可以获得稳定且可复制的回滚。因为整个系统都是在Git中描述的，所以您也只有一个真实的来源，崩溃后可以从中恢复，从而将恢复的平均时间（MTTR）从数小时缩短到了数分钟。
- 一致性和标准化由于GitOps提供了一种用于进行基础架构，应用程序和Kubernetes附加更改的模型，因此您在整个组织中拥有一致的端到端工作流。不仅持续的集成和持续的部署流水线都由请求请求驱动，而且您的操作任务也可以通过Git完全重现。
- 更高的安全性保证Git强大的正确性和安全性保证，以用于跟踪和管理更改的强大加密技术为后盾，以及对更改进行签名以证明作者和来源的能力，是安全定义集群所需状态的关键。
GitOps是持续交付与Cloud Native相遇
GitOps建立并迭代了从DevOps和Site Reliability Engineering汲取的思想，这些思想始于 2006年Martin Fowler的全面持续集成概述。
编织云中的持续交付和GitOps工作流程
在我们的产品 Weave Cloud中，GitOps核心机器位于其CI / CD工具中，关键部分是支持Git群集同步的持续部署（CD）
拉与推管道
当今大多数可用的CI / CD工具都使用基于推的模型。基于推式的管道意味着代码从CI系统开始，并且可以通过一系列编码脚本继续其路径，或者手动使用'kubectl'将任何更改推向Kubernetes集群。
您不想将CI系统用作部署动力或不想在命令行上手动执行此操作的原因是因为有可能在群集外部公开凭据。虽然可以同时保护CI / CD脚本和命令行，但您在群集的信任域之外工作。这通常不是一个好习惯，这就是为什么CI系统可以被称为生产的攻击媒介的原因。
可观察性是部署的催化剂
借助Kubernetes，GitOps可以通过请求请求管理基础架构和应用程序部署。但是GitOps工作流程和可观察性如何一起工作？
通过将GitOps工作流程与实时可观察性相结合，您的开发团队可以在部署任何新功能之前做出关键决策。因为在发布之前可以在正在运行的群集中实时观察即将发布的服务，所以这意味着您可以放心部署并更快地交付质量更高的功能。
可观察性可以被视为 Kubernetes 持续交付周期的主要驱动力之一， 因为它描述了在任何给定时间的系统实际运行状态。观察正在运行的系统是为了理解和控制它。新功能和修复程序被推送到git并触发部署管道，并且可以在运行中的集群上实时观察何时准备发布。此时，开发人员可以基于此反馈返回到管道的开头，或者将映像部署并发布到生产集群。
GitOps是一个既包含操作又包含功能的面向发布的模型。您向客户交付新功能的速度有多快，部分取决于您的团队在此周期中能走多快。
一起使用GitOps工作流程和可观察性的开发人员需要回答以下问题：
- 如果更改自动发布，我们如何知道它确实有效？
- 我们如何确定我们的变更实际上在推动改进？
- 在复杂的分布式系统中，我们如何理解问题，诊断问题并处理事件？