边缘 GitOps
过去几年，我们看到越来越多的企业采用 GitOps，这是一种使用 Git 作为存储库的开发运维范式。
GitOps 是一种 开发运维 实践，使用 Git 作为存储期望配置状态的单一可信信息源。重点是由 Git 存储库驱动的操作自动化。尽管 Git 出现在名称中，但它并不是唯一可以使用的存储库。Git 提供的接口可以实现自动化操作。GitOps 最终使用从构建元数据中提取的信息来确定由特定代码更改触发要构建的包：
在其核心，GitOps 模型使用控制器模式。这进一步得到了 Kubernetes 或 OpenShift 视角中的操作符模式的帮助，其中操作符是使用 自定义资源 管理应用及其组件的软件扩展。
我们不能不提 Argo CD，这是一个有助于 GitOps 工作流的 GitOps 工具。Argo CD 是一款开源声明式工具，用于应用程序的 持续整合 和 持续部署 （CI/CD）。Argo CD 作为 Kubernetes 控制器实现，可持续监控正在运行的应用程序定义和配置，将集群上的当前实时状态与 Git 库中定义的所需状态进行比较。
但 GitOps 不是单一的产品、插件或平台。GitOps 工作流帮助团队通过他们在应用程序开发中已经使用的工作流来管理 IT 基础设施。借用 GitLab 博客的说法，GitOps 需要三个核心组件：GitOps = IaC + PR 或 MR + CI/CD
- IaC：基础结构即代码（IaC）是将所有基础设施配置以代码形式存储的实践。GitOps 使用 Git 存储库作为基础设施定义的单一可信信息源。Git 跟踪所有代码管理更改。
- PR 或 MR：GitOps 使用拉取请求（PR）或合并请求（MR）作为所有基础架构更新的变更机制。这是团队可以通过评论和审查进行协作的地方，也是进行正式批准的地方。
- CI/CD： GitOps 使用 Git 工作流，通过持续整合 (CI) 和持续交付 (CD) 自动更新基础设施。当新代码合并时，CI/CD 管道在环境中实施更改。任何配置偏差，例如手动更改或错误，都会被 GitOps 自动化覆盖，从而使环境收敛到 Git 中定义的所需状态，提供持续操作 (CO)：
Red Hat OpenShift 操作符简化了复杂工作负载的安装和自动化编排。它们有助于编码人类的操作逻辑，以管理作为 Kubernetes 原生应用运行的服务，使第二天的操作更加轻松。操作符是在集群上的一个 pod 中运行的软件，与 Kubernetes API 服务器交互。OpenShift 操作符本质上是一个自定义控制器，实际上可以是一个特定于应用的控制器。
Red Hat OpenShift 通过提供必要的操作符，使想要使用 GitOps 的开发人员变得容易。一旦部署完毕，就可以在 OpenShift 控制台的“已安装操作符”部分查看。Red Hat OpenShift GitOps 操作符是 ArgoCD 的上游操作符，同时部署的 Red Hat OpenShift Pipelines 操作符是 Tekton 的上游操作符。请参阅图 3：
然后可以使用操作符及相关 API 启动一个或多个 GitOps 管道，这些管道可以从 Git 中拉取期望的配置结果并部署到不同环境中。环境可以是通常的开发、测试和生产环境，也可以跨越地理环境，如企业云、电信网络或边缘计算节点。
部署资源分为三个领域：基础设施、服务和应用。这些领域使得相关资源的部署分离和管理变得容易：
- 基础设施 定义所需的命名空间和存储单元。
- 服务 描述了设置实例所需的各种操作符。
- 应用 列举了要部署的应用程序。
在之前的博客中，我们讨论了边缘计算领域的开发运维；在这里，我们来看看 GitOps 如何应用于边缘计算。我们提到了边缘计算中的三个边缘：
- 企业边缘
- 网络边缘
- 设备边缘（或远边缘）
还有云或企业数据中心。让我们深入了解一下这些领域。除了边缘环境之外，图 4 还描绘了三个 GitOps 领域：基础设施、服务和应用。
云/企业数据中心
边缘计算正在见证 OpenShift 或 Kubernetes 集群在大多数 IT 中心的普及。它有可能达到每个客户数百到数千次部署的大规模规模。结果是，企业 IT 部门必须管理在本地和/或公有云上运行的多个独立或协作的容器运行时集群。
确保集群具有相同的期望状态——在多个云上推出和回滚更改——是 GitOps 为基于边缘和物联网的企业提供的一项主要优点。
网络边缘
GitOps 范式适用于网络边缘，因为通信服务提供商 (CSP) 面临的主要挑战之一是寻求实现其网络的编排、自动化和管理。虽然 5G 对消费者来说是个福音，但软件定义网络（SDN）、不同带宽的网络切片和更快的部署为电信提供商带来了挑战。
自动化部署管道是 CSP 可以更快地向客户提供服务的一种方法。拥有中央存储库和声明式方法来配置容器基础设施，意味着新特性和变更请求更快地进入市场。这样的范式将有助于在网络边缘提供虚拟网络功能（VNF）和云原生网络功能（CNF）。网络组件的容器化使得管理这些功能成为可能。最后，由于所有配置活动都记录并存储在 Git 中，跟踪更改的能力对于合规和审计目的至关重要。参考资料中有几篇来自 WeaveWorks 的相关博客：
企业边缘
GitOps 允许组织同时部署到多个目标。它允许推出细粒度的部署。在部署应用到成百上千个边缘节点时，这将非常有用，这些边缘节点有不同的形状和外形规格，并使用不同的通信协议——尤其是如果边缘节点是使用Intel NUC或NVIDIA Jetson的小型边缘集群。
GitOps框架有助于部署应用，并将 Git 存储库作为单一可信信息源。 ITOps 团队寻求边缘节点的自主应用部署、管理和运维，这可以通过使用 Red Hat OpenShift 操作符来实现。
设备边缘（或远边缘）
GitOps 的优势在网络边缘和企业边缘非常明显。边缘设备带来了不同的挑战，因为其中一些设备的存储空间和计算能力不足以托管 GitOps 服务并运行应用程序。
轻量级 Kubernetes 发行版的发布，如 K3 和 K0，旨在用于 IoT 和边缘用例。能够在边缘设备上部署轻量级 Kubernetes 发行版，使我们能够运行像 Argo CD 之类的 GitOps 工具。然后，设备将能够采用拉取模型，轮询 Git 存储库以获取所需状态，并将其同步到集群的实时状态。
通过使用 GitOps，您可以解决基础设施和应用程序配置蔓延的问题。Red Hat OpenShift 中内置的 GitOps 操作符可轻松实施 Argo CD 驱动的管道。 IBM Cloud Paks的客户（包括 IBM Cloud Pak for Network Automation）可以利用 Red Hat 操作符来安装资源，并采用 GitOps 框架来自动化和控制部署过程。
IBM Cloud Native Toolkit是一个很好的起点。它是一个开源的资产集合，用于启用应用开发和运维部署。
特别感谢 Hollis Chui 和 Kavitha Bade 审阅本文。