使用 GitOps 的 CI/CD 工作流（Flux v2）

新式 Kubernetes 部署包含多个应用程序、群集和环境。 借助 GitOps，可以更轻松地管理这些复杂的设置，使用 Git 以声明方式跟踪 Kubernetes 环境的所需状态。 使用常见的 Git 工具声明群集状态，可以增加责任，促进故障调查，并启用自动化来管理环境。

本文介绍 GitOps 如何与使用 Azure Arc、Azure Repos 和 Azure Pipelines 的完整应用程序变更生命周期相结合。 它还提供了对 GitOps 控制的 Kubernetes 环境进行单个应用程序更改的示例。

此图显示了部署到一个或多个 Kubernetes 环境的应用程序的 CI/CD 工作流。

显示 GitOps CI/CD 体系结构的

应用程序存储库包含开发人员在其内部循环中处理的应用程序代码。 应用程序的部署模板以通用形式在此存储库中实时，例如 Helm 或 Kustomize。 特定于环境的值不会存储在存储库中。

对此存储库进行更改会调用一个启动部署过程的 PR 或 CI 管道。

容器注册表包含 Kubernetes 环境中使用的所有第一方和第三方映像。 使用用户可读的标记以及用于生成映像的 Git 提交来标记第一方应用程序映像。 可以缓存第三方映像，以帮助实现安全性、速度和复原能力。 设置用于及时测试和集成安全更新的计划。

有关详细信息，请参阅 如何使用和维护 Azure 容器注册表任务的公共内容。

开发人员向应用程序存储库发出的拉取请求取决于 PR 管道是否能够成功运行。 此管道运行基本质量门，例如对应用程序代码运行 Lint 检查和单元测试。 该管道将测试应用程序，并通过 Lint 检查用于部署到 Kubernetes 环境的 Dockerfile 和 Helm 模板。 应生成和测试 Docker 映像，但不应推送。 保持管道持续时间相对较短，以允许快速迭代。

应用程序 CI 管道运行所有 PR 管道步骤，并扩展测试和部署检查。 可对主分支的每个提交运行管道，也可以按照固定的频率对一组提交运行管道。

在此阶段，可以执行对于 PR 管道消耗过高的应用程序测试，包括：

• 将映像推送到容器注册表
• 映像生成、Lint 分析和测试
• 原始 YAML 文件的模板生成

CI 生成结束时，会生成工件。 这些工件可由 CD 步骤使用，为部署做准备。

Flux 是作为群集扩展在每个群集中运行的代理。 此 Flux 群集扩展负责维护所需状态。 代理按用户定义的时间间隔轮询 GitOps 存储库，然后将群集状态与 Git 存储库中声明的状态进行协调。

有关详细信息，请参阅 教程：将 GitOps 与 Flux v2 配合使用来部署应用程序。

CI 生成成功时会自动触发 CD 管道。 在此管道环境中，特定于环境的值将替换先前发布的模板中的值，并使用这些值针对 GitOps 存储库提出新的拉取请求。 此拉取请求包含对一个或多个 Kubernetes 群集所需状态的建议更改。 群集管理员查看拉取请求并批准合并到 GitOps 存储库。 管道等待拉取请求合并，之后 Flux 会同步并应用状态更改。

GitOps 存储库表示群集中所有环境的当前所需状态。 每个群集中的 Flux 服务会选取对此存储库所做的任何更改并部署。 对群集所需状态的更改将呈现为拉取请求，这些请求随后会被审阅，最终在更改获批时合并。 这些拉取请求包含对部署模板以及生成的 Kubernetes 清单所做的更改。 低级别的呈现清单允许更仔细地检查模板级别通常看不到的更改。

GitOps 连接器 在 Flux 代理和 GitOps 存储库/CD 管道之间创建连接。 向群集应用更改时，Flux 会将每项阶段更改和执行的运行状况检查通知给 GitOps 连接器。 此组件充当适配器。 它了解如何与 Git 存储库通信，并更新 Git 提交状态，以便同步进度在 GitOps 存储库中可见。 部署完成后（无论是成功还是失败），连接器会通知 CD 管道继续，以便管道可以执行部署后活动，例如集成测试。

至少有一个已启用 Azure Arc 的 Kubernetes 或 Azure Kubernetes 服务 （AKS） 群集为应用程序所需的不同环境提供服务。 例如，单个群集可以通过不同的命名空间同时为开发和 QA 环境提供服务。 第二个群集可以更轻松地分离环境和更精细的控制。

作为应用程序开发人员，Alice：

• 编写应用程序代码。
• 确定如何在 Docker 容器中运行应用程序。
• 定义在 Kubernetes 群集中运行容器和依赖服务的模板。

Alice 希望确保应用程序能够在多个环境中运行，但她不知道每个环境的特定设置。

假设 Alice 想要进行应用程序更改，以更改应用程序部署模板中使用的 Docker 映像。

1. Alice 更改了部署模板，将其推送到了应用程序存储库中名为 alice 的远程分支，并创建了拉取请求以针对 main 分支进行评审。

2. Alice 要求她的团队审查更改。

   • PR 管道运行验证。
   • PR 管道成功运行并经过团队批准后，更改将会合并。

3. 然后，CI 管道启动并验证 Alice 的更改并成功完成。

   • 此更改可以安全地部署到群集，并且项目将保存到 CI 管道运行。

4. CI 管道运行成功会触发 CD 管道。

   • CD 管道拾取 Alice 的 CI 管道运行存储的项目。
   • CD 管道将模板替换为环境特定的值，并暂存针对 GitOps 存储库中现有群集状态的任何更改。
   • CD 管道使用群集状态的所需更改针对 GitOps 存储库的生产分支创建拉取请求。

5. Alice 的团队评审并批准她的拉取请求。

   • 更改将合并到与环境对应的目标分支中。

6. 在几分钟内，Flux 将会注意到 GitOps 存储库中发生了更改，并拉取 Alice 的更改。

   • 由于 Docker 映像更改，应用程序 Pod 需要更新。
   • Flux 将更改应用于群集。
   • Flux 通过 GitOps Connector将部署状态报告回 GitOps 存储库。

7. CD 管道运行自动测试，以验证新部署是否已成功完成并按预期工作。

   备注

   对于其他面向部署的环境，CD 管道将通过为下一个环境创建拉取请求并重复步骤 4-7 来不断迭代。 许多过程可能需要额外批准，以针对风险较高的部署或环境，例如与安全相关的更改或生产环境。

8. 所有环境收到成功的部署后，管道就完成了。

• 浏览我们的 教程，使用 GitOps实现 CI/CD。
• 了解如何 使用 Flux 配置在群集与 Git 存储库之间创建连接。