什么是多云 GitOps？

GitOps 是一套用于指导工作流，以及为云原生应用实施持续部署 （CD）的原则。GitOps 有助于对以前的手动流程引入自动化，从而帮助管理集群配置和应用部署。例如，借助 GitOps，您可以跨多集群 Kubernetes 环境管理红帽^® OpenShift^® 容器平台集群。无论是简单还是复杂的部署，GitOps 均可自动执行，从而提高了应用工作流的效率。

GitOps 可以帮助部署新应用或更新现有应用。更新存储库时，GitOps 工作流可以自动执行其他所有操作。 

具体来说，GitOps 可以实现：

• 跨公共云和私有云管理混合云和多云部署
• 跨集群治理和管理应用生命周期
• 在部署中安全管理机密

以上这些功能有助于缓解多云方法带来的挑战，例如，当工作负载要跨公共云、私有云甚至本地环境迁移时，需要确保一致性、安全性和相互协作。 

在 GitOps 中，Git 存储库是系统和应用配置的单一事实来源。它包含了您环境的基础架构的声明性描述，并与 GitOps 工具（如 Argo CD）处理的自动化流程协同工作。通过自动化处理，可使您的环境的实际状态与预先描述的预期状态保持一致。您还可以使用存储库查看系统状态更改列表，因为 Git 历史记录提供更改跟踪。 

此外，将基础架构和配置存储为代码有助于减少 IT 资源的无序蔓延。您可以将集群和应用的配置以代码形式存储在 Git 存储库中。 

企业或机构都需要以稳定、简单和安全的方式在开放混合云上开发、部署和运维应用。为此，他们需要采用包含多云部署的混合策略。 

不过，想采用多云方法，要经历许多重大挑战。例如，不同云供应商提供的工具也各不相同，相互之间可能无法良好配合。因此，工作负载迁移可能成本高昂且困难重重。缺乏可移植性也会导致更高的安全风险和数据隐私问题。 

所幸，Kubernetes 已经解决了许多挑战。借助 Kubernetes，多个集群可以在不同的云环境（包括本地环境）上运行。工作负载可以在环境中无缝迁移，而不会产生上述迁移和安全难题。 

采用 Kubernetes 部署中的工作负载可以在多个集群和多个云（私有云或公共云）上运行。这种策略可解决上述的挑战，但也需要采用基础架构即代码方法。换而言之，GitOps 对于现代多云策略具有重要意义。 

如上所述，GitOps 使用 Git 存储库作为单一事实来源来提供基础架构即代码。提交的代码首先会通过持续集成（CI）流程，而持续交付（CD）流程则负责检查并应用要求。所有对代码的更改都会被跟踪，就像团队熟悉的版本控制和修订功能。 

因此，GitOps 支持基础架构团队之间的协作，以加快开发过程。它通过自动化流程（而非手动流程）为多云方法提供一致性，这有助于避免手动流程可能带来的昂贵成本和人为错误的风险。 

综上所述，企业或机构要想实施多云方法，一定要确保跨环境的一致性和安全性。而 GitOps 解决方案就是理想对策，比如红帽 OpenShift GitOps。

红帽 OpenShift GitOps 是为您安装并配置 Argo CD 实例的 Operator。它可管理基础架构配置和应用部署，围绕这些配置存储库组织部署过程。该过程始终以至少两个存储库为核心：

• 包含源代码的应用存储库
• 定义应用期望状态的环境配置存储库

为了维护集群资源，红帽 OpenShift GitOps 使用开源工具 Argo CD，来处理应用的持续集成和持续部署（CI/CD）的持续部署部分。也就是说，在红帽 OpenShift GitOps 中，Argo CD 的角色类似于控制器，它会监视来自 Git 存储库中的应用状态描述和配置。它将定义的状态与实际状态进行比较，然后报告偏离指定描述的任何配置。 

管理员可以根据这些报告将配置重新同步到定义的状态，这一步可以通过手动或自动操作。在自动化流程中，配置本质上具有“自我修复”的能力，能够自动检测和纠正问题。

因此，借助红帽 OpenShift GitOps 及其自动化流程，您可以：

• 确保集群具有相似的配置、监控和存储状态
• 向多个集群应用或还原配置更改
• 将模板化配置与不同的环境相关联
• 从预演到生产，跨集群部署应用

Operator 是在 OpenShift 容器平台控制平面上打包、部署和管理服务的首选方法。例如，GitOps Primer 可导出 Kubernetes 对象，以供在集群、团队和环境之间共享。这可促进 GitOps 将一致性、安全性和协作引入多云方法。 

它们能与 Kubernetes API 和命令行界面（CLI）工具集成，以提供监控应用、执行健康检查、管理无线（OTA）更新以及确保应用保持指定状态的方法。

OpenShift 容器平台中有两种用途不同的系统管理 Operator：

• 集群 Operator：由集群版本 Operator（CVO）管理且默认安装的 Operator，用于执行集群功能。
• 可选附加 Operator：由 Operator 生命周期管理（OLM）管理的 Operator，可供用户访问以在其应用中运行。

您可借助 Operator 来创建应用，以监控集群中正在运行的服务。它们负责实施和自动执行安装和配置运维、自动扩缩容及创建备份。以上所有活动都发生在集群内运行的软件中。

Operator 可提供：

• 安装和升级的可重复性
• 每个系统组件的持续健康检查
• OpenShift 组件的无线（OTA）更新
• 将现场工程师的专业知识转化成自动化流程，共享给所有用户（而不只是一两人）

GitOps Primer 是在 OpenShift 集群中运行的 Operator，它使开发人员能够导出命名空间中的所有 Kubernetes 对象。它会生成可移植的 .zip 文件，以便您：

• 转移到另一个集群
• 与团队成员共享
• 使用 Argo CD 或红帽 Kubernetes 高级集群管理（RHACM）将其推送至 GitOps 工作流。 

GitOps Primer 有助于采用 GitOps 为多云环境带来的基础架构即代码方法。

Git 可充当基础架构和应用配置的单一事实来源。基础架构配置和应用配置都需要访问敏感资产，通常称为机密（例如身份验证令牌、私钥等），以便 GitOps 工具执行相应功能。

但是，在 Git 存储库中存储机密是一种安全漏洞，即使该存储库被视为私有并设置了访问控制，也不应该允许这样做。一旦某个机密以明文形式（或容易逆转的状态）推送给 Git，则必须将其视为泄密，并应立即撤销。

为了克服这一挑战，GitOps 中的机密管理有两种主要的架构方案：

• 加密机密
  • 存储在 Git 存储库内部
  • 通过自动化流程将其解密并呈现为 Kubernetes 机密
• 对机密的引用存储在 Git 存储库中
  • 通过自动化流程根据这些引用来检索机密
  • 检索到的机密呈现为 Kubernetes 机密

要深入了解这两种方法，请阅读 GitOps 和 Kubernetes 的机密管理指南。

现在，您已了解多云 GitOps 的概念，接下来可以学习如何使用 GitOps 进行开发，包括：

• Argo CD 和 OpenShift GitOps Operator 入门
• syncwave 和 hook 入门
• 利用红帽 Ansible^® 自动化平台 和 OpenShift 上的 Jenkins 落地 CI/CD

您还可以继续浏览关于 OpenShift GitOps 的文章，包括：

• 什么是有效验证模式？
• 什么是 Argo CD？
• 什么是 CI/CD？